DPI (SSL-inspeksjon) går på tvers av kryptografi, men selskaper implementerer det

Kjede av tillit. CC BY-SA 4.0 Yanpas

SSL trafikkinspeksjon (SSL/TLS-dekryptering, SSL- eller DPI-analyse) blir et stadig mer hett diskusjonstema i bedriftssektoren. Ideen om å dekryptere trafikk ser ut til å motsi selve konseptet med kryptografi. Faktum er imidlertid et faktum: flere og flere selskaper bruker DPI-teknologier, og forklarer dette med behovet for å sjekke innhold for skadelig programvare, datalekkasjer osv.

Vel, hvis vi aksepterer det faktum at slik teknologi må implementeres, så bør vi i det minste vurdere måter å gjøre det på den sikreste og mest velstyrte måten som mulig. Stol i det minste ikke på de sertifikatene, for eksempel som DPI-systemleverandøren gir deg.

Det er ett aspekt ved implementeringen som ikke alle vet om. Faktisk er mange mennesker virkelig overrasket når de hører om det. Dette er en privat sertifiseringsinstans (CA). Den genererer sertifikater for å dekryptere og omkryptere trafikk.

I stedet for å stole på selvsignerte sertifikater eller sertifikater fra DPI-enheter, kan du bruke en dedikert CA fra en tredjeparts sertifiseringsinstans som GlobalSign. Men først, la oss gjøre en liten oversikt over selve problemet.

Hva er SSL-inspeksjon og hvorfor brukes det?

Flere og flere offentlige nettsteder flytter til HTTPS. For eksempel ifølge Chrome-statistikk, i begynnelsen av september 2019 nådde andelen kryptert trafikk i Russland 83 %.

Dessverre blir trafikkkryptering i økende grad brukt av angripere, spesielt siden Let's Encrypt distribuerer tusenvis av gratis SSL-sertifikater på en automatisert måte. Dermed brukes HTTPS overalt – og hengelåsen i nettleserens adresselinje har sluttet å tjene som en pålitelig indikator på sikkerhet.

Produsenter av DPI-løsninger markedsfører produktene sine fra disse posisjonene. De er innebygd mellom sluttbrukere (dvs. dine ansatte som surfer på nettet) og Internett, og filtrerer ut ondsinnet trafikk. Det finnes en rekke slike produkter på markedet i dag, men prosessene er i hovedsak de samme. HTTPS-trafikk går gjennom en inspeksjonsenhet hvor den dekrypteres og sjekkes for skadelig programvare.

Når verifiseringen er fullført, oppretter enheten en ny SSL-sesjon med sluttklienten for å dekryptere og kryptere innholdet på nytt.

Hvordan dekrypterings-/omkrypteringsprosessen fungerer

For at SSL-inspeksjonsenheten skal dekryptere og omkryptere pakker før de sendes til sluttbrukere, må den kunne utstede SSL-sertifikater på farten. Dette betyr at den må ha et CA-sertifikat installert.

Det er viktig for selskapet (eller hvem som helst i midten) at disse SSL-sertifikatene er klarert av nettlesere (dvs. ikke utløser skumle advarsler som den nedenfor). Derfor må CA-kjeden (eller hierarkiet) være i nettleserens tillitsbutikk. Fordi disse sertifikatene ikke er utstedt fra offentlig klarerte sertifikatmyndigheter, må du manuelt distribuere CA-hierarkiet til alle sluttklienter.

Advarsel for selvsignert sertifikat i Chrome. Kilde: BadSSL.com

På Windows-datamaskiner kan du bruke Active Directory og gruppepolicyer, men for mobile enheter er prosedyren mer komplisert.

Situasjonen blir enda mer komplisert hvis du trenger å støtte andre rotsertifikater i et bedriftsmiljø, for eksempel fra Microsoft, eller basert på OpenSSL. Pluss beskyttelse og administrasjon av private nøkler slik at noen av nøklene ikke utløper uventet.

Beste alternativ: privat, dedikert rotsertifikat fra en tredjeparts CA

Hvis det ikke er attraktivt å administrere flere røtter eller selvsignerte sertifikater, er det et annet alternativ: å stole på en tredjeparts CA. I dette tilfellet utstedes sertifikater fra privat en CA som er knyttet i en tillitskjede til en dedikert, privat rot-CA som er laget spesielt for selskapet.

Forenklet arkitektur for dedikerte klientrotsertifikater

Dette oppsettet eliminerer noen av problemene nevnt tidligere: det reduserer i det minste antallet røtter som må administreres. Her kan du bruke bare én privat rotautorisasjon for alle interne PKI-behov, med et hvilket som helst antall mellomliggende CA-er. For eksempel viser diagrammet ovenfor et flernivåhierarki der en av de mellomliggende CA-ene brukes til SSL-verifisering/dekryptering og den andre brukes til interne datamaskiner (bærbare datamaskiner, servere, stasjonære datamaskiner, etc.).

I denne utformingen er det ikke nødvendig å være vert for en CA på alle klienter fordi CA på toppnivå er vert for GlobalSign, som løser problemer med beskyttelse av privat nøkkel og utløp.

En annen fordel med denne tilnærmingen er muligheten til å tilbakekalle SSL-inspeksjonsmyndigheten uansett grunn. I stedet opprettes ganske enkelt en ny, som er knyttet til din opprinnelige private rot, og du kan bruke den umiddelbart.

Til tross for all kontrovers, implementerer bedrifter i økende grad SSL-trafikkinspeksjon som en del av deres interne eller private PKI-infrastruktur. Andre bruksområder for privat PKI inkluderer utstedelse av sertifikater for enhets- eller brukerautentisering, SSL for interne servere og ulike konfigurasjoner som ikke er tillatt i offentlige klarerte sertifikater som kreves av CA/nettleserforum.

Nettlesere slår tilbake

Det skal bemerkes at nettleserutviklere prøver å motvirke denne trenden og beskytte sluttbrukere mot MiTM. For eksempel for noen dager siden Mozilla tok en avgjørelse Aktiver DoH (DNS-over-HTTPS)-protokollen som standard i en av de neste nettleserversjonene i Firefox. DoH-protokollen skjuler DNS-spørringer fra DPI-systemet, noe som gjør SSL-inspeksjon vanskelig.

Om lignende planer 10. september 2019 kunngjort Google for Chrome-nettleseren.

Kun registrerte brukere kan delta i undersøkelsen. Logg inn, vær så snill.

Tror du et selskap har rett til å inspisere SSL-trafikken til sine ansatte?

• Ja, med deres samtykke

• Nei, å be om slikt samtykke er ulovlig og/eller uetisk

122 brukere stemte. 15 brukere avsto.

Kilde: www.habr.com