DPI (SSL-inspektion) står i konflikt med meningen med kryptering, men företag implementerar det

Trovärdekedja. CC BY-SA 4.0 Yanpas

Inspektion av SSL-trafik (avkodning av SSL/TLS, analys av SSL eller DPI) blir allt mer aktuellt inom företagssektorn. Idén om avkodning av trafik verkar faktiskt motsäga själva konceptet av kryptografi. Men faktum kvarstår: allt fler företag använder DPI-teknologier och förklarar detta med behovet av att kontrollera innehåll för skadlig programvara, dataläckor osv.

Om vi accepterar att sådan teknik behöver implementeras, bör vi åtminstone överväga sätt att göra det på det mest säkra och välhanterade sättet. Åtminstone bör man inte förlita sig på de certifikat som t.ex. din DPI-leverantör tillhandahåller.

Det finns en aspekt av implementeringen som inte alla känner till. Faktum är att många verkligen blir förvånade när de hör talas om det. Det handlar om en privat certifikatutfärdare (CA). Den genererar certifikat för avkodning och återskencoding av trafik.

Istället för att förlita sig på självsignerade certifikat eller certifikat från DPI-enheter kan du använda en dedikerad CA från en extern certifikatutfärdare som GlobalSign. Men låt oss först göra en liten översikt av själva problemet.

Vad är SSL-inspektion och varför används det?

Fler och fler offentliga webbplatser går över till HTTPS. Till exempel, enligt Chrome-statistik, i början av september 2019 nådde andelen krypterad trafik i Ryssland 83%.

Tyvärr används kryptering av trafik allt oftare av brottslingar, särskilt eftersom Let’s Encrypt delar ut gratis SSL-certifikat i tusental i automatiserat läge. På så sätt används HTTPS överallt — och låset i webbläsarens adressfält har slutat vara en tillförlitlig indikator på säkerhet.

Utifrån dessa synpunkter marknadsför DPI-lösningsproducenter sina produkter. De placeras mellan slutkonsumenter (d.v.s. dina anställda som surfar på webbplatser) och Internet, där de filtrerar bort skadlig trafik. Idag finns det flera sådana produkter på marknaden, men processerna är i stort sett desamma. HTTPS-trafik passerar genom en inspektionsenhet, där den avkodas och kontrolleras för skadlig programvara.

Efter att kontrollen är slutförd skapar enheten en ny SSL-session med den slutliga kunden för dekryptering och omkryptering av innehållet.

Hur fungerar processen för dekryptering/omkryptering

För att SSL-inspektionsenheten ska kunna dekryptera och omkryptera paket innan de skickas till slutanvändare, måste den kunna utfärda SSL-certifikat i realtid. Detta innebär att enheten måste ha en CS-certifikat installerat.

För företaget (eller en annan mellanhand) är det viktigt att dessa SSL-certifikat är betrodda i webbläsare (d.v.s. inte orsakar skrämmande varningsmeddelanden som det nedan). Därför måste CS-kedjan (eller hierarkin) finnas i webbläsarens förtroendeförråd. Eftersom dessa certifikat inte utfärdas av offentligt betrodda certifikatmyndigheter, måste hierarkierna överföras manuellt till alla slutkunder.

Varningsmeddelande för ett självsignerat certifikat i Chrome. Källa: BadSSL.com

På datorer med Windows kan Active Directory och grupprinciper användas, men för mobila enheter är processen mer komplicerad.

Situationen blir ännu mer komplicerad om det behövs stödja andra rotcertifikat i företagsmiljön, som från Microsoft eller baserat på OpenSSL. Plus skydd av hemliga nycklar och deras hantering, så att ingen av nycklarna oväntat går ut.

Bästa alternativet: ett privat, dedikerat rotcertifikat från en extern CS.

Om administrationen av flera rötter eller självsignerade certifikat inte tilltalar, finns det ett annat alternativ: man kan förlita sig på en extern CS. I så fall utfärdas certifikaten från en privat certifikatmyndighet, som är kopplad i kedjan av förtroende med ett dedikerat, privat rotcertifikat som skapats speciellt för företaget.

Förenklad arkitektur för dedikerade klientrotcertifikat

Denna konfiguration minskar vissa av de problem som nämndes tidigare: åtminstone minskar den antalet rotmyndigheter som måste hanteras. Här kan endast ett privat rotcentrum användas för alla interna PKI-behov med valfritt antal mellanliggande certifikatcentra. Till exempel visar den ovanstående diagrammet en flerledshierarki där ett av de mellanliggande certifikatcentra används för verifiering/avkodning av SSL, medan ett annat används för interna datorer (bärbara datorer, servrar, stationära datorer etc.).

I detta schema behöver CS inte placeras på alla klienter, eftersom toppnivå CS placeras hos GlobalSign, vilket löser problemen med skydd av den privata nyckeln och giltighetstiden.

En annan fördel med detta tillvägagångssätt är möjligheten att återkalla certifikatcentrum för SSL-inspektion av vilken anledning som helst. Istället skapas helt enkelt ett nytt, som kopplas till din ursprungliga privata rot, och kan användas omedelbart.

Trots alla kontroverser implementerar företag allt oftare SSL-inspektion av trafik som en del av intern eller privat PKI-infrastruktur. Andra användningsområden för privat PKI är utfärdande av certifikat för autentisering av enheter eller användare, SSL för interna servrar samt olika konfigurationer som inte är tillåtna i offentligt betrodda certifikat enligt CA/Browser Forum-kraven.

Webbläsare motsätter sig

Det bör noteras att webbläsarutvecklare försöker motverka denna trend och skydda slutkonsumenterna från MiTM. Till exempel, för några dagar sedan, Mozilla har fattat beslut planerar att aktivera DoH (DNS-over-HTTPS) som standard i en av de kommande versionerna av Firefox. DoH-protokollet döljer DNS-frågor från DPI-system, vilket gör SSL-inspektion mer komplicerad.

Om liknande planer den 10 september 2019 tillkännagav företaget Google för webbläsaren Chrome.

Endast registrerade användare kan delta i omröstningen. Logga in, tack.

Tycker du att företaget har rätt att inspektera SSL-trafiken för sina anställda?

• Ja, med deras samtycke

• Nej, att be om sådant samtycke är olagligt och/eller oetiskt

122 användare har röstat. 15 användare har avstått.

Källa: habr.com