Názory k článku Dešifrujeme HTTPS pomocí nástroje Wireshark
-
Podobně se dá monitorovat např. i komunikace šifrovaná pomocí ESP (IPsec), když máte klíče (dají se zobrazit pomocí
ip xfrm state show).On má vůbec wireshark netušené možnosti. Před lety jsem ho třeba používal k nouzovému nahrávání hovorů přes SIP (nenašel jsem klienta, který by tuto funkci nabízel přímo): wireshark totiž umí z RTP streamu extrahovat zvuk a uložit do souboru; sice v ne úplně obvyklém formátu, ale to už se pak snadno překonvertuje.
-
Stanislav SchattkeStříbrný podporovatelVýborný článek. Ve Wireshark už jsem dešifroval IPsec, ale proměná SSLKEYLOGFILE je pro mě novinkou. Skvělá práce.
-
Wireshark umi data nacitat ze STDIN, takze fazi zachytavani na vzdalenem serveru/routeru a analyzy na desktopu lze spojit napriklad takto:
plink.exe -ssh -pw "abc123" root@192.168.2.1 "tcpdump -ni eth0 -s 0 -w - not port 22" | "C:\Program Files\Wireshark\Wireshark.exe" -k -i - -f "host 10.11.12.13"
Pokud by se k tomu doscriptoval jeste popsany handling TLS klicu, tak by se to dalo pouzivat i na tyto ucely.
-
Filip JirsákStříbrný podporovatelJenom bych doplnil, že kromě NSS (TLS knihovna Firefoxu), OpenSSL a derivátů (takže aplikace Chrome, cUrl, wget a další) umí klíče vyexportovat také Java pomocí Java Agenta jSSLKeyLog, který se připojí při startu JVM (takže je to nezávislé na aplikaci, pokud používá TLS knihovny dodávané s Javou). node.js podporuje navíc parametr příkazové řádky -
-tls-keylog(proměnná prostředíSSLKEYLOGFILEby také měla fungovat). deno používá RustTLS, takžeSSLKEYLOGFILEtaké podporuje. Zdá se, že Go také tuto proměnnou prostředí podporuje.Nebo-li těch prostředí, která umí klíče TLS komunikace pro Wireshark (obecně v NSS formátu) vyexportovat, je hodně – nejen na klientovi, ale i na serveru.
Už jsem se setkal s tím, že k chybě docházelo jenom při TLS komunikaci (nešifrovaná varianta byla v pořádku), a nebo prostě nešifrovaná varianta komunikace nebyla k dispozici. Takže někdy je tohle opravdu jediná reálná možnost, jak vystopovat problém.
-
Dekuji za hezky clanek, nicmene polemizoval bych s poznamkou ze: “….postup funguje vzdycky”
Mozna se mylim, nicmene jsem si skoro jisty ze pro openssl, jeho knihovny a tim padem i sw ktery je na nich zavisly to fungovat bez nejakych hacku typu ld_preload, systemtap apod. nebude. Alespon tomu donedavna tak bylo a jedinou cestou bylo vynuceni tls 1.2, ponizeni key echange na rsa a desifrovani pomoci klice (tusim ze to je jedine encryption schema, ktere tls 1.2 umi, v tls 1.3 uz jsme nahrani).
Cokoliv je zkompilovano s libnss tak je to v pohode.
-
…a dale bych mel jeste 2 doplneni
1) Pokud uz chytame provoz tcpdumpem, hodi se prepinac -s 0 kdy zajistime zachytavani celych paketu. Defaultne se bere jen nejakych 96 bytu coz nam nemusi vzdy stacit. Jasne zalezi na tom jaky je provoz, kolik mame mista atd apod, nicmene u tracovani treba ruznych rest api se to docela hodi. Wireshark umi i parsovani jsonu takze cely provoz mame jak na taliri :)
2) V pripade ze nam https (nebo jiny protokol bezici pres tls treba ldaps apod) bezi na nejakem nestandartnim portu, pak to wiresharku musime vyspecifikovat v takove tabulce skryte pod options -> tls. Bez toho se nam to neuplatni spravny disector a uvidime prdlajz.
