DPI (SSL-i inspektsioon) on vastuolus krüptograafia põhimõttega, kuid ettevõtted rakendavad seda

Usaldusedik. Yanpas

SSL-i liikluse inspekteerimine (SSL/TLS-i dekodeerimine, SSL-i analüüs või DPI) on muutumas üha kuumemaks arutelu teemaks ettevõttesektoris. Idee dekodeerida liiklust näib olevat vastuolus krüptograafia enda kontseptsiooniga. Kuid fakt on see, et üha rohkem ettevõtteid kasutab DPI tehnoloogiaid, selgitades seda vajadusega kontrollida sisu pahavara, andmeleket jne suhtes.

Noh, kui võtta arvesse, et sellist tehnoloogiat on tõepoolest vajalik rakendada, siis tuleb vähemalt kaaluda, kuidas seda kõige turvalisemal ja paremini hallatav viisil teha. Alustuseks ei tohiks toetuda näiteks neile sertifikaatidele, mida annab teile DPI süsteemi pakkuja.

On üks rakenduse aspekt, millest kõik ei tea. Tõepoolest, paljud inimesed on üllatunud, kui kuulevad sellest. See on privaatne sertifitseerimiskeskus (CS). See genereerib sertifikaate liikluse dekodeerimiseks ja uuesti krüptimiseks.

Selle asemel, et toetuda iseesinevate sertifikaatide või DPI seadmete sertifikaatide kasutamisele, saate kasutada pühendatud CS-d kolmandatest osapooltest sertifitseerimiskeskusest, nagu GlobalSign. Kuid kõigepealt teeme väikese ülevaate probleemist endast.

Mis on SSL-i inspekteerimine ja miks seda kasutatakse?

Üha rohkem avalikke veebisaite liigub HTTPS-i peale. Näiteks, vastavalt Chrome'i statistikale, septembri alguses 2019 jõudis Venemaa krüpteeritud liikluse osakaal 83%-ni.

Kahjuks kasutavad häkkerid üha enam liikluse krüpteerimist, eriti kuna Let’s Encrypt jagab automatiseeritud režiimis tasuta SSL-sertifikaate tuhandete kaupa. Seega kasutatakse HTTPS-i laialdaselt – ja lukustusikoon brauseri aadressiribal ei ole enam usaldusväärne turvalisuse indikaator.

Sellest vaatenurgast edendavad oma toodet DPI lahenduste tootjad. Nad paigaldatakse lõppkasutajate (st teie töötajate, kes sirvivad veebilehti) ja Interneti vahele, filtreerides pahatahtlikku liiklust. Praeguseks on turul mitmeid selliseid tooteid, kuid protsessid on põhimõtteliselt sarnased. HTTPS-i liiklus läbib kontrollseadet, kus see dekodeeritakse ja kontrollitakse pahavara olemasolu suhtes.

Pärast kontrolli lõpetamist loob seade lõppkliendiga uue SSL-seansi sisu määrimiseks ja uuesti krüpteerimiseks.

Kuidas töötab dekrüpteerimise/uue krüpteerimise protsess

SSL-inspektsiooni seade peab enne lõppkasutajatele saatmist pakettide dekrüpteerimiseks ja uuesti krüpteerimiseks olema võimeline väljastama SSL-sertifikaate reaalajas. See tähendab, et seadmel peab olema installitud CA-sertifikaat.

Et ettevõttele (või muule vahendajale) oleks oluline, et need SSL-sertifikaadid oleksid brauserites usaldusväärsed (st ei põhjustaks hirmutavaid hoiatusteateid, nagu allpool näidatud). Seetõttu peab CA ahel (või hierarhia) olema brauseri usaldus- jaotuses. Kuna neid sertifikaate ei väljastata avalikest usaldusväärsetest sertifitseerimiskeskustest, tuleb CA hierarhiad käsiüle anda kõikidele lõppkliendile.

Enesekirjutatud sertifikaadi hoiatusteade Chromes. Allikas: BadSSL.com

Windowsi arvutites saab kasutada Active Directoryt ja grupipoliitikaid, kuid mobiilseadmete puhul on protsess keerulisem.

Situatsioon muutub veel keerukamaks, kui tuleb säilitada ettevõtte keskkonnas ka teised juurerakenteerijad, näiteks Microsofti või OpenSSL-i baasil. Pluss on salajaste võtmete kaitse ja haldamine, et mõni võtmetest ei aeguks üllataval hetkel.

Parim variant: privaatne, eraldatud juurerakenteerija kolmandalt CA-lt

Kui mitme juure haldamine või enesekirjutatud sertifikaadid ei tundu ahvatlevad, on ka teine variant: toetuda kolmandale CA-le. Sel juhul väljastatakse sertifikaadid privaatse sertifitseerimiskeskusest, mis on seotud ahela usaldusväärsuse tasemega eraldatud, privaatse juurerakenteerijaga, mis on loodud spetsiaalselt ettevõttele.

Lihtsustatud arhitektuur eraldatud kliendi juurerakenteerijate jaoks

See seadistus vähendab osaliselt varem mainitud probleeme: see vähendab juurte arvu, millega tuleb tegeleda. Siin saab kasutada ainult ühte erakorralist juuretööd kõigi PKI sisevajaduste jaoks mistahes arvu vahe-sertifitseerimiskeskustega. Näiteks ülaltoodud diagrammil on näidatud mitme tasandi hieraarhia, kus üks vahe-sertifitseerimiskeskus on häälestatud SSL-i kontrollimiseks/dekrüpteerimiseks, ja teine sisearvutite (nohikute, serverite, lauaarvutite jne) jaoks.

Selles skeemis ei ole vaja paigutada CS-i kõigile klientidele, sest kõrgema taseme CS on paigutatud GlobalSigni juures, mis lahendab sulgemise võtme kaitse ja kehtivusaja probleemid.

Veel üks selle lähenemise eelis on võimalus tühistada SSL-i auditeerimise sertifikaat mis tahes põhjusel. Selle asemel luuakse lihtsalt uus, mis on seotud teie algse erakorralise juurega, ja seda saab kohe kasutada.

Vaatamata kõikidele vastuoludele, rakendavad ettevõtted üha enam SSL-i liiklustäiendust kui osa sisemisest või erasisest PKI infrastruktuurist. Teised erasisese PKI kasutusalad hõlmavad sertifikaatide väljastamist seadmete või kasutajate autentimiseks, SSL-i sise-serveritele ning erinevaid konfiguratsioone, mis ei ole lubatud avalikes usaldusväärsetes sertifikaatides vastavalt CA/Browser foorumi nõuetele.

Brauserid vastanduvad

Tuleb märkida, et brauserite arendajad püüavad sellele suundumusele vastu seista ja kaitsta lõppkasutajaid MiTM-i eest. Näiteks paar päeva tagasi teatas Mozilla otsustas et kavatseb vaikimisi aktiveerida DoH (DNS-over-HTTPS) protokolli ühes järgnevates Firefoxi brauseri versioonides. DoH protokoll peidab DNS-päringud DPI süsteemilt, muutes SSL-i auditeerimise keeruliseks.

Kuid sarnaste plaanide kohta teatas 10. septembril 2019 teatas ettevõte Google Chrome'i brauseri jaoks.

Ainult registreeritud kasutajad saavad küsitluses osaleda. Logige sisse, palun.

Kuidas te arvate, kas ettevõttel on õigust inspekteerida oma töötajate SSL-i liiklust?

• Jah, nende nõusolekul

• Ei, sellise nõusoleku küsimine on ebaseaduslik ja/või ebaeetiline

Hääletas 122 kasutajat. Erakodud 15 kasutajat.

Allikas: habr.com