(nem hivatalos e-kormányzati témájú oldal)
| Mottó: Ne add fel! A kulcstartón is általában a legutolsó kulcs az, amelyik kinyitja az ajtót. /Paulo Coelho: Az accrai kézirat/ | ||
| 2021. május 31. | ||
| SSL/TLS: az SSLKEYLOGFILE is egyfajta keylogger | ||
| Az SSL/TLS protokollról megtanultuk az iskolában, hogy a "client" (pl. browser) és "server" (pl. web server) között hoz létre rejtjelezett kommunikációs csatornát. Azt is tudjuk, hogy a rejtjelezéshez használ aszimmetrikus algoritmusokat és szimmetrikus algoritmusokat egyaránt ("hybrid"). A rejtjelezésen túlmenően pedig – beállítástól függően – felhasználó-hitelesítést is végre tud hajtani, ami miatt MitM (Man-in-the-Middle) támadás ellen védett VPN (Virtual Private Network) megoldásként is használják. Az SSL/TLS története 1994-ig nyúlik vissza és az azóta eltelt évek alatt sok tapasztalat gyűlt össze, hogy mire kell figyelni egy protokoll tervezésénél (pl. renegotiation attack) vagy megvalósításánál (pl. padding hibák), illetve az alkalmazott transzformációknál (pl. tömörítések, kriptográfiai algoritmusok). Ezekről már írtam pár sort az SSL/TLS korábbi verziói kapcsán (ld. HTTP/HTTPS Authentication és Harci díszben az Apache). Az SSL/TLS jelenlegi változata, a TLS v1.3 2018-ban jelent meg szabványként (IETF RFC 8446) és a "formal verification" elemzésen kívül is komoly változásokat hozott. Ezek a változások pedig befolyásolják a forgalomelemzésekre vonatkozó lehetőségeket is, legyen szó akár támadásról, akár hibakeresésről (debug). A TLS v1.3 (IETF RFC 8446) talán legfontosabb újításai "privacy" és "security" szempontból
A TLS v1.3 előtt az SSL/TLS mutual/client authentication esetén a "client" által beküldött tanúsítvány ("Certificate") még nyíltan került elküldésre, így a pl. VPN hálózati forgalmat figyelő esetleges támadók láthatták, hogy kik, mikor csatlakoztak a "server" oldalhoz. Magukhoz az átküldött adatokhoz, a kommunikációhoz nem fértek hozzá, de a kapcsolatfelépítésből ("handshake") kinyert adatok is fontos információként szolgálhattak, amit pl. GDPR (2016/679/EU) miatt is bizalmasan kell már kezelni. A TLS v1.3 jelentősen módosította a kapcsolatfelépítés ("handshake") folyamatát: nem csak egyszerűbbé és rövidebbé vált, de logikailag is megváltozott, így felelve meg napjaink "privacy" követelményeinek. All handshake messages after the ServerHello are now encrypted.
A TLS v1.3 előtt két lehetőség volt a "client" (pl. browser) és "server" (pl. web server) által – az adatok rejtjelezésére – használandó szimmetrikus kulcs (pl. AES) beállítására:
The keyEncipherment bit is asserted when the subject public key is used for enciphering private or secret keys, i.e., for key transport. For example, this bit shall be set when an RSA public key is to be used for encrypting a symmetric content-decryption key or an asymmetric private key.A TLS v1.3 jelentősen módosította az aszimmetrikus aláíró algoritmusok paramétereit, illetve a szimmetrikus rejtjelező kulcsok beállítására használható algoritmusok körét ("Cipher Suites") azzal, hogy az RSA eltűnt a készletből és csak a Diffie-Hellman maradt, amivel biztosítani lehet a "forward secrecy" követelményt:
A "forward secrecy" követelmény alapján nem lehet hosszú távú titkos adatra alapozni a védelmet (mint egy RSA titkos kulcsnál, vagy statikus Diffie-Hellman paraméternél), helyette rövidebb lejáratú, akár csak adott SSL/TLS handshake tranzakcióra ("ephemeral") alkalmazott titkos adatokat lehet használni (mint egy mindig új paramétereket használó Diffie-Hellman kulcsegyeztetés során). Ez védelmet nyújthat azon támadások ellen, amelyeknél csak megfigyelik és eltárolják a hálózati forgalmakat, hogy aztán idővel a megfejtett – vagy a megszerzett "server" RSA – titkos kulcsok révén utólag visszaalakítsák a rejtjelezett adatokat (és ezáltal pl. WikiLeaks-szerűen feltárják napjaink történelmét). Fontos azonban megjegyezni, hogy a Shor algoritmust futtató kvantumszámítógép ellen a hagyományos Diffie-Hellman sem nyújt elegendő védelmet (esetleg a Supersingular Isogeny Diffie-Hellman lehet "quantum-safe"). A hálózati forgalom megfigyelésére és eltárolására a (portable) WireShark egy megfelelő segédalkalmazás (Cain & Abel mellett). A WireShark az RSA révén történő kulcsátvitelt meg tudja fejteni, ha a "server" RSA titkos kulcsát megkapja (pl. *.p12), de a TLS v1.3 által kizárólagosan engedélyezett Diffie-Hellman révén történő kulcsegyeztetés eredménye alapján is vissza tudja alakítani a rejtjelezett hálózati forgalmat, ha az SSLKEYLOGFILE állományba kiírja a "client" (pl. browser) a titkos adatokat. Az SSLKEYLOGFILE környezeti változó támogatott a Google Chrome és Mozilla Firefox 48 (2016-08-02 – NSS 3.24, 2016-05-17) böngészőben. Az SSLKEYLOGFILE használatához a "server" és a "client" oldalán egyaránt vannak előfeltételek:
Kapcsolódó anyagok: | ||
| vissza | ||
info@ugyfelkapu.info
