Ü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?
- 555 megtekintés
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Mit szóltok a következőkhöz:
NGINX-hez modul:
https://github.com/tiandrey/nginx-sslkeylog
Egy Apache megoldás:
https://security.stackexchange.com/questions/215358/extracting-openssl-…
Vélemény, tapasztalat?
- A hozzászóláshoz be kell jelentkezni
En regebben ezt szoktam ilyen celra hasznalni:
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!
- A hozzászóláshoz be kell jelentkezni
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.”
- A hozzászóláshoz be kell jelentkezni
Hát mikor én erről a SSLKEYLOGFILE-feauture-ról olvastam, komolyan azt hittem, hogy valamiféle tréfa. Elég egy környezeti változót beinjektálni az áldozat shelljébe, és attól kezdve elbúcsúzhat az adataitól/pénzétől.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
Pontosan. Ha nincs SSLKEYLOGFILE, akkor van mondjuk LD_PRELOAD, es azzal egy tamado ugyanugy megoldhatja maganak, hogy egy sajat "felinstrumentalt" openssl fusson a kliens alkalmazasban.
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni