DPI (SSL-inspectie) druist in tegen de kern van cryptografie, maar bedrijven implementeren het

Keten van vertrouwen. CC BY-SA 4.0 Yanpas

SSL-verkeersinspectie (SSL/TLS-decodering, SSL- of DPI-analyse) wordt een steeds populairder discussieonderwerp in het bedrijfsleven. Het idee van het decoderen van verkeer lijkt in tegenspraak te zijn met het concept van cryptografie. Feit is echter een feit: steeds meer bedrijven gebruiken DPI-technologieën, wat wordt verklaard door de noodzaak om de inhoud te controleren op malware, datalekken, enz.

Welnu, als we het feit accepteren dat dergelijke technologie geïmplementeerd moet worden, dan moeten we op zijn minst manieren overwegen om dit op de veiligst en best beheerde manier mogelijk te doen. Vertrouw in ieder geval niet op die certificaten die bijvoorbeeld de DPI-systeemleverancier je geeft.

Er is één aspect van de implementatie dat niet iedereen kent. Sterker nog, veel mensen zijn echt verrast als ze erover horen. Dit is een particuliere certificeringsinstantie (CA). Het genereert certificaten om verkeer te decoderen en opnieuw te coderen.

In plaats van te vertrouwen op zelfondertekende certificaten of certificaten van DPI-apparaten, kunt u een speciale CA van een externe certificeringsinstantie zoals GlobalSign gebruiken. Maar laten we eerst een klein overzicht geven van het probleem zelf.

Wat is SSL-inspectie en waarom wordt het gebruikt?

Steeds meer publieke websites stappen over op HTTPS. Volgens bijvoorbeeld Chrome-statistiekenBegin september 2019 bereikte het aandeel gecodeerd verkeer in Rusland 83%.

Helaas wordt verkeersversleuteling steeds vaker gebruikt door aanvallers, vooral omdat Let’s Encrypt duizenden gratis SSL-certificaten op geautomatiseerde wijze distribueert. HTTPS wordt dus overal gebruikt - en het hangslot in de adresbalk van de browser fungeert niet langer als een betrouwbare indicator voor de veiligheid.

Fabrikanten van DPI-oplossingen promoten vanuit deze posities hun producten. Ze zijn ingebed tussen eindgebruikers (dat wil zeggen uw werknemers die op internet surfen) en het internet, waardoor kwaadaardig verkeer wordt gefilterd. Er zijn tegenwoordig een aantal van dergelijke producten op de markt, maar de processen zijn in wezen hetzelfde. HTTPS-verkeer passeert een inspectieapparaat waar het wordt gedecodeerd en gecontroleerd op malware.

Zodra de verificatie is voltooid, maakt het apparaat een nieuwe SSL-sessie met de eindclient om de inhoud te decoderen en opnieuw te coderen.

Hoe het decoderings-/hercoderingsproces werkt

Om ervoor te zorgen dat het SSL-inspectieapparaat pakketten kan ontsleutelen en opnieuw versleutelen voordat ze naar eindgebruikers worden verzonden, moet het in staat zijn om SSL-certificaten direct uit te geven. Dit betekent dat er een CA-certificaat geïnstalleerd moet zijn.

Het is belangrijk voor het bedrijf (of wie dan ook in het midden) dat deze SSL-certificaten worden vertrouwd door browsers (dat wil zeggen dat ze geen enge waarschuwingsberichten zoals hieronder activeren). Daarom moet de CA-keten (of hiërarchie) zich in de vertrouwensopslag van de browser bevinden. Omdat deze certificaten niet zijn uitgegeven door openbaar vertrouwde certificeringsinstanties, moet u de CA-hiërarchie handmatig naar alle eindclients distribueren.

Waarschuwingsbericht voor zelfondertekend certificaat in Chrome. Bron: BadSSL.com

Op Windows-computers kunt u Active Directory en Groepsbeleid gebruiken, maar voor mobiele apparaten is de procedure ingewikkelder.

De situatie wordt nog ingewikkelder als u in een bedrijfsomgeving andere rootcertificaten moet ondersteunen, bijvoorbeeld van Microsoft of op basis van OpenSSL. Plus de bescherming en het beheer van privésleutels, zodat geen van de sleutels onverwacht verloopt.

Beste optie: privé, speciaal rootcertificaat van een externe CA

Als het beheren van meerdere rootcertificaten of zelfondertekende certificaten niet aantrekkelijk is, is er nog een andere optie: vertrouwen op een CA van derden. In dit geval worden certificaten uitgegeven van castnogo een CA die in een vertrouwensketen is gekoppeld aan een speciale, private root-CA die speciaal voor het bedrijf is gemaakt.

Vereenvoudigde architectuur voor speciale clientrootcertificaten

Deze opstelling elimineert een aantal van de eerder genoemde problemen: het vermindert in ieder geval het aantal wortels dat moet worden beheerd. Hier kunt u slechts één privé-rootautoriteit gebruiken voor alle interne PKI-behoeften, met een willekeurig aantal tussenliggende CA's. Het bovenstaande diagram toont bijvoorbeeld een hiërarchie met meerdere niveaus, waarbij een van de tussenliggende CA's wordt gebruikt voor SSL-verificatie/decodering en de andere wordt gebruikt voor interne computers (laptops, servers, desktops, enz.).

In dit ontwerp is het niet nodig om op alle clients een CA te hosten, omdat de CA op het hoogste niveau wordt gehost door GlobalSign, dat problemen met de bescherming van privésleutels en het verlopen ervan oplost.

Een ander voordeel van deze aanpak is de mogelijkheid om de SSL-inspectiebevoegdheid om welke reden dan ook in te trekken. In plaats daarvan wordt eenvoudigweg een nieuwe aangemaakt, die is gekoppeld aan uw oorspronkelijke privéroot, en u kunt deze onmiddellijk gebruiken.

Ondanks alle controverses implementeren bedrijven steeds vaker SSL-verkeersinspectie als onderdeel van hun interne of private PKI-infrastructuur. Andere toepassingen voor privé-PKI zijn onder meer het uitgeven van certificaten voor apparaat- of gebruikersauthenticatie, SSL voor interne servers en verschillende configuraties die niet zijn toegestaan ​​in openbare vertrouwde certificaten, zoals vereist door het CA/Browser Forum.

Browsers vechten terug

Opgemerkt moet worden dat browserontwikkelaars deze trend proberen tegen te gaan en eindgebruikers tegen MiTM te beschermen. Een paar dagen geleden bijvoorbeeld Mozilla een beslissing gemaakt Schakel het DoH-protocol (DNS-over-HTTPS) standaard in in een van de volgende browserversies in Firefox. Het DoH-protocol verbergt DNS-query's voor het DPI-systeem, waardoor SSL-inspectie moeilijk wordt.

Over soortgelijke plannen 10 september 2019 kondigde het Google voor de Chrome-browser.

Alleen geregistreerde gebruikers kunnen deelnemen aan het onderzoek. Inloggen, Alsjeblieft.

Vindt u dat een bedrijf het recht heeft om het SSL-verkeer van zijn medewerkers te inspecteren?

• Ja, met hun toestemming

• Nee, het vragen om dergelijke toestemming is illegaal en/of onethisch

122 gebruikers hebben gestemd. 15 gebruikers onthielden zich van stemming.

Bron: www.habr.com