A bizalom lánca. CC BY-SA 4.0
Az SSL forgalom ellenőrzés (SSL/TLS dekódolás, SSL elemzés vagy DPI) egyre nagyobb érdeklődést vált ki a vállalati szektorban. Az ötlet, hogy dekódolják a forgalmat, ellentmond a kriptográfia alapelveinek. Azonban a tény az tény: egyre több cég alkalmaz DPI technológiát, magyarázva ezt azzal, hogy szükség van a tartalom ellenőrzésére rosszindulatú programok és adatlopások miatt.
Nos, ha elfogadjuk, hogy szükséges egy ilyen technológia bevezetésére, akkor legalább meg kell fontolni, hogyan lehet ezt a legbiztonságosabb és legjobban menedzselhető módon végrehajtani. Legalább ne támaszkodjunk az olyan tanúsítványokra, amelyeket például a DPI rendszer szállítója ad.
Van egy olyan megvalósítási aspektus, amiről nem mindenki tud. Valójában sokan meglepődnek, amikor hallanak róla. Ez a privát tanúsítványkibocsátó központ (CA). Ez generál tanúsítványokat a forgalom dekódolásához és újra titkosításához.
Ahelyett, hogy önaláírt tanúsítványokra vagy DPI eszközök tanúsítványaira támaszkodna, használhat egy dedikált CA-t egy harmadik fél tanúsító központtól, mint például a GlobalSign. De először nézzük át röviden magát a problémát.
Mi az SSL ellenőrzés és miért használják?
Egyre több nyilvános weboldal vált HTTPS-re. Például a , 2019 szeptemberének elején az Oroszországban használt titkosított forgalom aránya elérte a 83%-ot.
Sajnos a forgalom titkosítását a rosszindulatú támadók is egyre gyakrabban alkalmazzák, különösen azzal, hogy a Let’s Encrypt ezreket oszt ki ingyenes SSL-tanúsítványokból automatizált módon. Így a HTTPS általános használatúvá vált — és a böngésző címsorában lévő lakat már nem megbízható biztonsági jelző.
Ezekből a nézőpontokból támogatták terméküket a DPI megoldások gyártói. Közvetlenül a végfelhasználók (azaz az oldalt böngésző alkalmazottak) és az Internet között helyezkednek el, kiszűrve a rosszindulatú forgalmat. Jelenleg számos ilyen termék érhető el a piacon, de a folyamatok lényegében hasonlóak. A HTTPS forgalom áthalad egy ellenőrző eszközön, ahol dekódolják és ellenőrzik a rosszindulatú programok jelenlétét.
A vizsgálat befejezése után az eszköz új SSL-munkamenetet hoz létre a végfelhasználóval annak érdekében, hogy dekódolja és újra titkosítsa a tartalmat.
Hogyan működik a dekódolás / újra titkosítás folyamata
Ahhoz, hogy az SSL-ellenőrző eszköz dekódolja és újra titkosítsa a csomagokat a végfelhasználóknak történő elküldés előtt, képesnek kell lennie SSL-tanúsítványokat kiadni élőben. Ez azt jelenti, hogy fel kell telepíteni rá egy CA-tanúsítványt.
Fontos, hogy ezek a SSL-tanúsítványok megbízhatók legyenek a böngészőkben (azaz ne okozzanak rémisztő figyelmeztető üzeneteket, hasonlóan az alábbihoz). Ezért a CA-láncnak (vagy hierarchiának) a böngésző bizalmi tárolójában kell lennie. Mivel ezek a tanúsítványok nem a nyilvános, megbízható tanúsító központokból származnak, manuálisan kell átadni a CA-hierarchiát minden végfelhasználónak.
Figyelmeztető üzenet az önaláírt tanúsítványról a Chrome-ban. Forrás:
Windows gépeken az Active Directory és a csoportházirendek alkalmazhatók, de mobil eszközök esetén a folyamat bonyolultabb.
A helyzet még bonyolultabbá válik, ha a vállalati környezetben más gyökér-tanúsítványok támogatására is szükség van, például a Microsoft-tól, vagy OpenSSL alapúakkal. Plusz a titkos kulcsok védelme és kezelése, hogy ne évüljön el váratlanul egyik kulcs sem.
A legjobb megoldás: magán, dedikált gyökér-tanúsítvány egy külső CA-tól.
Ha a több gyökér kezelése vagy az önaláírt tanúsítványok nem vonzóak, létezik egy másik megoldás: megbízhatunk egy külső CA-ban. Ebben az esetben a tanúsítványokat a következő helyről állítják ki: privát tanúsítványozási központ, amely a bizalmi láncban kapcsolódik egy dedikált, privát gyökér tanúsító központhoz, amelyet kifejezetten a cég számára hoztak létre.
Egyszerűsített architektúra dedikált ügyfél gyökér-tanúsítványokhoz.
Ez a beállítás csökkenti a korábban említett problémák egy részét: legalábbis csökkenti a kezelendő gyökerek számát. Itt csak egy privát gyökér központ használható minden belső PKI igényhez, bármennyi köztes tanúsítványkezelő központtal. Például a fent említett diagramon egy többrétegű hierarchia látható, ahol az egyik köztes tanúsítványkezelő központ az SSL érvényesítésére/dekripciójára szolgál, míg a másik a belső számítógépekhez (laptopok, szerverek, asztali számítógépek stb.)
Ebben a rendszerben nem szükséges a CA-kat minden ügyfélnél elhelyezni, mert a legfelsőbb szintű CA a GlobalSign-nál van, ami megoldja a privát kulcs védelmének és a lejárati idő problémáit.
E megközelítés egy másik előnye a köztes SSL tanúsítványok visszavonásának lehetősége bármilyen okból. Csak létrehozunk egy újat, amely a meglévő privát gyökerünkhöz kapcsolódik, és azonnal használható.
A viták ellenére a vállalatok egyre inkább integrálják az SSL forgalom ellenőrzését a belső vagy privát PKI infrastruktúrájuk részeként. A privát PKI más felhasználási lehetőségei közé tartozik a tanúsítványok kiadása eszközök vagy felhasználók hitelesítésére, SSL belső szerverek számára, valamint olyan különböző konfigurációk, amelyek nem megengedettek nyilvános megbízható tanúsítványok esetén a CA/Browser Forum követelményeivel összhangban.
A böngészők ellenállnak
Érdemes megjegyezni, hogy a böngészőfejlesztők próbálnak ellenállni ennek a tendenciának és megvédeni a végfelhasználókat a MiTM-től. Például néhány nappal ezelőtt a Mozilla alapértelmezés szerint be kívánja építeni a DoH (DNS-over-HTTPS) protokollt a Firefox következő verziójába. A DoH protokoll elrejti a DNS-lekérdezéseket a DPI-rendszerek elől, megnehezítve az SSL ellenőrzést.
Hasonló tervekről 2019. szeptember 10-én a Google a Chrome böngésző számára.
Csak a regisztrált felhasználók vehetnek részt a szavazáson. , kérem.
Mit gondol, van joga a cégnek ellenőrizni az alkalmazottai SSL-forgalmát?
Igen, az ő beleegyezésükkel
Nem, az ilyen beleegyezés kérése jogellenes és/vagy etikátlan
122 felhasználó szavazott. 15 felhasználó tartózkodott.
Forrás: habr.com
