{"id":38110,"date":"2019-10-31T22:21:42","date_gmt":"2019-10-31T19:21:42","guid":{"rendered":"https:\/\/prohoster.info\/blog\/dpi-inspektsiya-ssl-protivorechit-smyslu-kriptografii-no-kompanii-eyo-vnedryayut\/"},"modified":"2019-10-31T22:21:42","modified_gmt":"2019-10-31T19:21:42","slug":"dpi-inspektsiya-ssl-protivorechit-smyslu-kriptografii-no-kompanii-eyo-vnedryayut","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/dpi-inspektsiya-ssl-protivorechit-smyslu-kriptografii-no-kompanii-eyo-vnedryayut","title":{"rendered":"DPI (SSL-inspectie) staat in strijd met de essentie van cryptografie, maar bedrijven implementeren het","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"DPI
\nVertrouwensketen. CC BY-SA 4.0 Yanpas<\/a><\/noindex><\/i><\/p>\n

SSL-verkeerinspectie (decryptering van SSL\/TLS, SSL-analyse of DPI) wordt steeds meer een heet onderwerp in de bedrijfssector. Het idee om verkeer te ontsleutelen lijkt in tegenspraak met het concept van cryptografie zelf. Toch is de realiteit dat steeds meer bedrijven DPI-technologie\u00ebn gebruiken, met de verklaring dat het noodzakelijk is om inhoud te controleren op malware, datalekken, enzovoort.<\/p>\n

Als we aannemen dat het noodzakelijk is om deze technologie in te voeren, zouden we tenminste moeten kijken naar manieren om dit op de veiligste en best beheerde manier te doen. We moeten bijvoorbeeld niet vertrouwen op de certificaten die u krijgt van de DPI-systeemleverancier.<\/p>\n

Er is \u00e9\u00e9n aspect van de implementatie waar niet iedereen van op de hoogte is. Veel mensen zijn echt verbaasd wanneer ze erover horen. Dit is een private certificeringsinstantie (CA). Deze genereert certificaten voor het decrypteren en opnieuw versleutelen van verkeer.
\n<\/a><\/noindex>
\nIn plaats van te vertrouwen op zelfondertekende certificaten of certificaten van DPI-apparaten, kunt u gebruik maken van een speciale CA van een externe certificeringsinstantie, zoals GlobalSign. Maar laten we eerst een kort overzicht van het probleem zelf maken.<\/p>\n

Wat is SSL-inspectie en waarom wordt het gebruikt?<\/h2>\n

\nSteeds meer openbare websites schakelen over op HTTPS. Bijvoorbeeld volgens Chrome-statistieken<\/a><\/noindex>, bereikte het aandeel versleuteld verkeer in Rusland begin september 2019 83%.<\/p>\n

\"DPI<\/a><\/noindex><\/p>\n

Helaas maken kwaadwillenden steeds vaker gebruik van versleuteling van verkeer, vooral omdat Let’s Encrypt duizenden gratis SSL-certificaten automatisch uitdeelt. Hierdoor wordt HTTPS overal gebruikt \u2014 en is het slotje in de adresbalk van de browser geen betrouwbaar indicatie van veiligheid meer.<\/p>\n

Vanuit deze posities promoten DPI-oplossingsleveranciers hun producten. Ze worden geplaatst tussen eindgebruikers (d.w.z. uw medewerkers die webpagina's bekijken) en het internet, waarbij ze schadelijk verkeer filteren. Tegenwoordig zijn er verschillende van zulke producten op de markt, maar de processen zijn in wezen hetzelfde. HTTPS-verkeer gaat door een controle-apparaat, waar het wordt ontcijferd en gecontroleerd op malware.<\/p>\n

Na afloop van de controle maakt het apparaat een nieuwe SSL-sessie met de eindklant aan om de inhoud te ontsleutelen en opnieuw te versleutelen.<\/p>\n

Hoe werkt het proces van ontsleuteling\/het opnieuw versleutelen<\/h2>\n

\nOm SSL-inspectie het mogelijk te maken om pakketten te ontsleutelen en opnieuw te versleutelen voordat ze naar eindgebruikers worden verzonden, moet het apparaat in staat zijn om SSL-certificaten on-the-fly uit te vaardigen. Dit betekent dat het een certificaat van de CA moet hebben ge\u00efnstalleerd.<\/p>\n

Het is voor een bedrijf (of een andere tussenpersoon) belangrijk dat deze SSL-certificaten vertrouwd zijn in browsers (d.w.z. dat ze geen vervelende waarschuwingsberichten oproepen, zoals hieronder afgebeeld). Daarom moet de CA-keten (of hi\u00ebrarchie) in de vertrouwensopslag van de browser aanwezig zijn. Aangezien deze certificaten niet worden uitgegeven door openbare vertrouwde certificeringsinstanties, is het nodig om handmatig de CA-hi\u00ebrarchie naar alle eindklanten te sturen.<\/p>\n

\"DPI
\nWaarschuwingsbericht voor een zelfondertekend certificaat in Chrome. Bron: BadSSL.com<\/a><\/noindex><\/i><\/p>\n

Op Windows-computers kan Active Directory en groepsbeleid worden ingeschakeld, maar voor mobiele apparaten is de procedure complexer.<\/p>\n

De situatie wordt nog moeilijker als er in de bedrijfsomgeving ook andere rootcertificaten moeten worden ondersteund, bijvoorbeeld van Microsoft of op basis van OpenSSL. Plus, de bescherming van en het beheer van de priv\u00e9sleutels, zodat geen enkele sleutel onverwacht verloopt.<\/p>\n

De beste optie: een priv\u00e9, gewijd rootcertificaat van een externe CA<\/h2>\n

\nAls het beheer van meerdere roots of zelfondertekende certificaten niet aantrekkelijk is, is er een andere optie: men kan rekenen op een externe CA. In dat geval worden de certificaten uitgegeven door een priv\u00e9<\/b> certificeringsinstantie die in de vertrouwensketen is verbonden met een gewijd, priv\u00e9 rootcertificaat dat speciaal voor het bedrijf is aangemaakt.<\/p>\n

\"DPI<\/a><\/noindex>
\nEenvoudige architectuur voor gespecialiseerde klant rootcertificaten<\/i><\/p>\n

Deze configuratie lost enkele van de eerder genoemde problemen op: het vermindert in ieder geval het aantal rootcertificaten dat beheerd moet worden. Er kan slechts \u00e9\u00e9n private root centrum worden gebruikt voor alle interne PKI-behoeften met een onbeperkt aantal tussenliggende certificeringsinstanties. Het bovenstaande diagram toont een gelaagde hi\u00ebrarchie waarin een van de tussenliggende certificeringsinstanties wordt gebruikt voor de verificatie\/decodering van SSL, terwijl een andere wordt gebruikt voor interne computerapparatuur (laptops, servers, desktopcomputers, enz.).<\/p>\n

In dit schema is het niet nodig om de CA op alle clients te hosten, omdat de bovenste CA wordt gehost door GlobalSign, wat problemen met de bescherming van de priv\u00e9sleutel en de geldigheidsduur oplost.<\/p>\n

Een ander voordeel van deze benadering is de mogelijkheid om de SSL-inspectiecertificeringsautoriteit om welke reden dan ook in te trekken. In plaats daarvan wordt gewoon een nieuwe aangemaakt die aan uw oorspronkelijke private root is gekoppeld en die direct kan worden gebruikt.<\/p>\n

Ondanks alle controverses implementeren bedrijven steeds vaker SSL-verkeersinspectie als onderdeel van de interne of private PKI-infrastructuur. Andere toepassingen van private PKI zijn het uitgeven van certificaten voor apparaat- of gebruikersauthenticatie, SSL voor interne servers en verschillende configuraties die niet zijn toegestaan in openbare vertrouwde certificaten volgens de CA\/Browser Forum-vereisten.<\/p>\n

Browsers verzetten zich<\/h2>\n

\nHet is belangrijk op te merken dat browserontwikkelaars proberen deze trend tegen te gaan en eindgebruikers te beschermen tegen MiTM. Bijvoorbeeld, enkele dagen geleden heeft Mozilla te besluiten<\/a><\/noindex> besloten om het DoH-protocol (DNS-over-HTTPS) standaard in te schakelen in een van de komende versies van de Firefox-browser. Het DoH-protocol verbergt DNS-verzoeken voor DPI-systemen, waardoor SSL-inspectie moeilijker wordt.<\/p>\n

Over soortgelijke plannen werd op 10 september 2019 gesproken heeft aangekondigd<\/a><\/noindex> door Google voor de Chrome-browser.<\/p>\n

\"DPI<\/a><\/noindex><\/p>\n

Alleen geregistreerde gebruikers kunnen deelnemen aan de enqu\u00eate. Log in<\/a><\/noindex>, alstublieft.<\/p>\n

Denkt u dat het bedrijf het recht heeft om SSL-verkeer van zijn werknemers te inspecteren?<\/h2>\n