{"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\/et\/blog\/administrirovanie\/dpi-inspektsiya-ssl-protivorechit-smyslu-kriptografii-no-kompanii-eyo-vnedryayut","title":{"rendered":"DPI (SSL-i inspektsioon) on vastuolus kr\u00fcptograafia p\u00f5him\u00f5ttega, kuid ettev\u00f5tted rakendavad seda","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"DPI
\nUsaldusedik. Yanpas<\/a><\/noindex><\/i><\/p>\n

SSL-i liikluse inspekteerimine (SSL\/TLS-i dekodeerimine, SSL-i anal\u00fc\u00fcs v\u00f5i DPI) on muutumas \u00fcha kuumemaks arutelu teemaks ettev\u00f5ttesektoris. Idee dekodeerida liiklust n\u00e4ib olevat vastuolus kr\u00fcptograafia enda kontseptsiooniga. Kuid fakt on see, et \u00fcha rohkem ettev\u00f5tteid kasutab DPI tehnoloogiaid, selgitades seda vajadusega kontrollida sisu pahavara, andmeleket jne suhtes.<\/p>\n

Noh, kui v\u00f5tta arvesse, et sellist tehnoloogiat on t\u00f5epoolest vajalik rakendada, siis tuleb v\u00e4hemalt kaaluda, kuidas seda k\u00f5ige turvalisemal ja paremini hallatav viisil teha. Alustuseks ei tohiks toetuda n\u00e4iteks neile sertifikaatidele, mida annab teile DPI s\u00fcsteemi pakkuja.<\/p>\n

On \u00fcks rakenduse aspekt, millest k\u00f5ik ei tea. T\u00f5epoolest, paljud inimesed on \u00fcllatunud, kui kuulevad sellest. See on privaatne sertifitseerimiskeskus (CS). See genereerib sertifikaate liikluse dekodeerimiseks ja uuesti kr\u00fcptimiseks.
\n<\/a><\/noindex>
\nSelle asemel, et toetuda iseesinevate sertifikaatide v\u00f5i DPI seadmete sertifikaatide kasutamisele, saate kasutada p\u00fchendatud CS-d kolmandatest osapooltest sertifitseerimiskeskusest, nagu GlobalSign. Kuid k\u00f5igepealt teeme v\u00e4ikese \u00fclevaate probleemist endast.<\/p>\n

Mis on SSL-i inspekteerimine ja miks seda kasutatakse?<\/h2>\n

\n\u00dcha rohkem avalikke veebisaite liigub HTTPS-i peale. N\u00e4iteks, vastavalt Chrome'i statistikale<\/a><\/noindex>, septembri alguses 2019 j\u00f5udis Venemaa kr\u00fcpteeritud liikluse osakaal 83%-ni.<\/p>\n

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

Kahjuks kasutavad kurjategijad \u00fcha enam liikluse kr\u00fcpteerimist, eriti kuna Let’s Encrypt jagab tuhandeid tasuta SSL-sertifikaate automatiseeritud viisil. Seega kasutatakse HTTPS-i laialdaselt \u2014 ja aadressiribal olev lukuke on l\u00f5petanud usaldusv\u00e4\u00e4rse turvalisuse indikaatorina toimimise.<\/p>\n

Sellest vaatenurgast edendavad oma toodet DPI lahenduste tootjad. Nad paigaldatakse l\u00f5ppkasutajate (st teie t\u00f6\u00f6tajate, kes sirvivad veebilehti) ja Interneti vahele, filtreerides pahatahtlikku liiklust. Praeguseks on turul mitmeid selliseid tooteid, kuid protsessid on p\u00f5him\u00f5tteliselt sarnased. HTTPS-i liiklus l\u00e4bib kontrollseadet, kus see dekodeeritakse ja kontrollitakse pahavara olemasolu suhtes.<\/p>\n

P\u00e4rast kontrolli l\u00f5petamist loob seade l\u00f5ppkliendiga uue SSL-seansi sisu m\u00e4\u00e4rimiseks ja uuesti kr\u00fcpteerimiseks.<\/p>\n

Kuidas t\u00f6\u00f6tab dekr\u00fcpteerimise\/uue kr\u00fcpteerimise protsess<\/h2>\n

\nSSL-inspektsiooni seade peab enne l\u00f5ppkasutajatele saatmist pakettide dekr\u00fcpteerimiseks ja uuesti kr\u00fcpteerimiseks olema v\u00f5imeline v\u00e4ljastama SSL-sertifikaate reaalajas. See t\u00e4hendab, et seadmel peab olema installitud CA-sertifikaat.<\/p>\n

Et ettev\u00f5ttele (v\u00f5i muule vahendajale) oleks oluline, et need SSL-sertifikaadid oleksid brauserites usaldusv\u00e4\u00e4rsed (st ei p\u00f5hjustaks hirmutavaid hoiatusteateid, nagu allpool n\u00e4idatud). Seet\u00f5ttu peab CA ahel (v\u00f5i hierarhia) olema brauseri usaldus- jaotuses. Kuna neid sertifikaate ei v\u00e4ljastata avalikest usaldusv\u00e4\u00e4rsetest sertifitseerimiskeskustest, tuleb CA hierarhiad k\u00e4si\u00fcle anda k\u00f5ikidele l\u00f5ppkliendile.<\/p>\n

\"DPI
\nEnesekirjutatud sertifikaadi hoiatusteade Chromes. Allikas: BadSSL.com<\/a><\/noindex><\/i><\/p>\n

Windowsi arvutites saab kasutada Active Directoryt ja grupipoliitikaid, kuid mobiilseadmete puhul on protsess keerulisem.<\/p>\n

Situatsioon muutub veel keerukamaks, kui tuleb s\u00e4ilitada ettev\u00f5tte keskkonnas ka teised juurerakenteerijad, n\u00e4iteks Microsofti v\u00f5i OpenSSL-i baasil. Pluss on salajaste v\u00f5tmete kaitse ja haldamine, et m\u00f5ni v\u00f5tmetest ei aeguks \u00fcllataval hetkel.<\/p>\n

Parim variant: privaatne, eraldatud juurerakenteerija kolmandalt CA-lt<\/h2>\n

\nKui mitme juure haldamine v\u00f5i enesekirjutatud sertifikaadid ei tundu ahvatlevad, on ka teine variant: toetuda kolmandale CA-le. Sel juhul v\u00e4ljastatakse sertifikaadid privaatse<\/b> sertifitseerimiskeskusest, mis on seotud ahela usaldusv\u00e4\u00e4rsuse tasemega eraldatud, privaatse juurerakenteerijaga, mis on loodud spetsiaalselt ettev\u00f5ttele.<\/p>\n

\"DPI<\/a><\/noindex>
\nLihtsustatud arhitektuur eraldatud kliendi juurerakenteerijate jaoks<\/i><\/p>\n

See seadistus v\u00e4hendab osaliselt varem mainitud probleeme: see v\u00e4hendab juurte arvu, millega tuleb tegeleda. Siin saab kasutada ainult \u00fchte erakorralist juuret\u00f6\u00f6d k\u00f5igi PKI sisevajaduste jaoks mistahes arvu vahe-sertifitseerimiskeskustega. N\u00e4iteks \u00fclaltoodud diagrammil on n\u00e4idatud mitme tasandi hieraarhia, kus \u00fcks vahe-sertifitseerimiskeskus on h\u00e4\u00e4lestatud SSL-i kontrollimiseks\/dekr\u00fcpteerimiseks, ja teine sisearvutite (nohikute, serverite, lauaarvutite jne) jaoks.<\/p>\n

Selles skeemis ei ole vaja paigutada CS-i k\u00f5igile klientidele, sest k\u00f5rgema taseme CS on paigutatud GlobalSigni juures, mis lahendab sulgemise v\u00f5tme kaitse ja kehtivusaja probleemid.<\/p>\n

Veel \u00fcks selle l\u00e4henemise eelis on v\u00f5imalus t\u00fchistada SSL-i auditeerimise sertifikaat mis tahes p\u00f5hjusel. Selle asemel luuakse lihtsalt uus, mis on seotud teie algse erakorralise juurega, ja seda saab kohe kasutada.<\/p>\n

Vaatamata k\u00f5ikidele vastuoludele, rakendavad ettev\u00f5tted \u00fcha enam SSL-i liiklust\u00e4iendust kui osa sisemisest v\u00f5i erasisest PKI infrastruktuurist. Teised erasisese PKI kasutusalad h\u00f5lmavad sertifikaatide v\u00e4ljastamist seadmete v\u00f5i kasutajate autentimiseks, SSL-i sise-serveritele ning erinevaid konfiguratsioone, mis ei ole lubatud avalikes usaldusv\u00e4\u00e4rsetes sertifikaatides vastavalt CA\/Browser foorumi n\u00f5uetele.<\/p>\n

Brauserid vastanduvad<\/h2>\n

\nTuleb m\u00e4rkida, et brauserite arendajad p\u00fc\u00fcavad sellele suundumusele vastu seista ja kaitsta l\u00f5ppkasutajaid MiTM-i eest. N\u00e4iteks paar p\u00e4eva tagasi teatas Mozilla otsustas<\/a><\/noindex> et kavatseb vaikimisi aktiveerida DoH (DNS-over-HTTPS) protokolli \u00fches j\u00e4rgnevates Firefoxi brauseri versioonides. DoH protokoll peidab DNS-p\u00e4ringud DPI s\u00fcsteemilt, muutes SSL-i auditeerimise keeruliseks.<\/p>\n

Kuid sarnaste plaanide kohta teatas 10. septembril 2019 teatas<\/a><\/noindex> ettev\u00f5te Google Chrome'i brauseri jaoks.<\/p>\n

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

Ainult registreeritud kasutajad saavad k\u00fcsitluses osaleda. Logige sisse<\/a><\/noindex>, palun.<\/p>\n

Kuidas te arvate, kas ettev\u00f5ttel on \u00f5igust inspekteerida oma t\u00f6\u00f6tajate SSL-i liiklust?<\/h2>\n