SSL/TLS kapcsolat analizálása

Üdv Mindenkinek!

Van 2 szerverem, egy Apache reverse proxy webbel, publikus ipvel és egy mail szerver nginx proxyval, helyi ipvel. A kettő között HTTPS kapcsolat van, ebbe szeretnék belenézni Wireshark-kal.

Sajnos a HTTPS forgalmat nem tudom decodolni. Illetve érdekelne, hogy tudok további helyi SSL/TLS kapcsolatokba belenézni.

Van erre módszer, eszköz, ötlet?

Hozzászólások

Ha jol van konfiguralva, akkor kizarolag vmelyik vegponton levo alkalmazat debugolva lehet. Manapsag a TLS-nel a PFS kovetelmeny (TLS 1.2-ig ehhez konfiguralni kellett a megfelelo ciphersuite-olat, 1.3-tol mar csak ilyenek vannak). Ebben az eseteben minden egyes session egyszer hasznalatos (ephemeral) aszimmetrikus kulcsokat hasznal a generalt session key halozaton atvitelere, nem pedig a ket fel statikus kulcsparjat (ezek csak authentikaciot adnak, nem a titkositashoz hasznaltak). Szoval a ket fel privat kulcsanak ismereteben sem lehet utolag dekodolni a session-t. A session dekodolasahoz ezert szukseged lenne a session key-re, amit vagy leir az alkalmazas pl. fileba (ha van ilyen debug lehetoseg, a bongeszok konfiguralhatoak igy), vagy felejtos a dolog.

Apache httpd oldalon a

LogLevel warn ssl:trace8

config-gal tudod legrészletesebbre állítani a TLS loggolást, de ez is csak encrypted adatot fog loggolni.

Ha tényleg bele kell mászni a TLS-be akkor az ssldump tud segíteni.

En regebben ezt szoktam ilyen celra hasznalni:

https://mitmproxy.org/

A openssl-lel sajat cacert krealasban el kell melyedned, utana magat a toolt hasznalni egyszeru.

Régóta vágyok én, az androidok mezonkincsére már!

Most megint én nem értek valami alap dolgot, vagy ti éltetek eddig kövek alatt, de az SSL/TLS-nek nem pont az a lényege, hogy a két pont között ülő Wireshark Matyik ne lássanak bele a forgalomba?

Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Rosszul közelíted meg a problémát. Az SSLKEYLOGFILE nagyon hasznos tud lenni adott esetben, ha hibát kell keresni. Az egy másik kérdéskör, hogyha környezeti változót tud valaki beinjektálni, akkor már bejutottak a gépre, és akkor már nem feltétlenül az SSKEYLOGFILE lesz a legnagyobb probléma.

A Whireshark Matyik "soha" nem is fognak egy SSL/TLS-be belenézni, csak ha full kontrolljuk van a két beszélgető gép legalább egyikén.

Bár van ahol már a certificate pinning is játszik, hogy ne lehessen "bármilyen" certtel elérni az applikációt még ha a CA ugyanaz is és "bízunk" benne.

Ez secu szempontból jó irány, de az SSL inspection, mint monitoring megoldás használatát eltöri. Szóval pont a secu szakma erőltet olyan megoldásokat, amivel saját ellenőrzési lehetőségeit csökkenti. Adatszivárgás és malware védelem miatt fontos ezen forgalmak kibontása, mert már évek óta 60% felett van az SSL/TLS titkosított weboldalak forgalma. Enélkül vakrepülés a secu. Természetesen van whitelist-elt kategória (banki, kormányzati, egészségügyi,...)

Nagyvállalati környezetről beszélek, nem a "Whireshark Matyik" privát forgalmáról, mert az nem sok mindenkit érdekel, nincs információ értéke, még ha ők gyakran azt is hiszik.

Regebben a wireshark matyik bele tudtak latni a forgalomba, ha a szerver certhez tartozo private key megvolt.

Ennek voltak legitim hasznalati esetei, leginkabb debuggolasnal. Nyilvan a szerver oldali privat kulcshoz hozzaferesed kell legyen, ez szukseges feltetel, es normalis esetben kizarja, hogy 3-adik fel bele tudjon nezni a forgalmazasba.

A baj az, hogy ez utolag is megteheto. Vagyis ha egy sessiont valaki most rogzit, de nincs meg a kulcsa hozza, megteheti, hogy elrakja talonba es mikor egy kesobbi szerver-feltores kapcsan hozzajut a privat kulcshoz, akkor a felvett sessionoket utolag decryptalhatja.

Elvileg ez ellen ved a Perfect Forward Secrecy, viszont ezzel bukik a passziv debuggolasi lehetoseg.

Régóta vágyok én, az androidok mezonkincsére már!