HTTPS liikluse uurimine tcpdump, Wireshark ja mitmproxy abil
See artikkel räägib HTTPS liikluse analüüsimisest (HTTP päringute avatekstiks lahtivõtmise teel) kahes olukorras. Esiteks -- kui nii klient kui server on meie hallata ja me soovime testida, kas server saab just selliseid HTTP päringuid ja saadab selliseid vastuseid, nagu me eeldame. Teiseks -- kui serveriks on mõni avalik veebiteenus, millega suhtleme üle HTTPS protokolli, ja soovime teada, mida meie brauser serveriga räägib. Sisuliselt on siin tegemist olukorraga, kus me ei pruugi usaldada ei klienti (brauser jooksutab meie teadmata mingit kuritahtlikku skripti) ega ka serverit.
Autor: Marju Ignatjeva
Töövahendid ja keskkond
Kasutame töövahenditena tcpdump-i ja Wiresharki ning mitmproxy-t.
Artikli lugejalt eeldan, et HTTPS üldine tööpõhimõte on selge ja et lugeja oskab Linuxi keskkonnas paigaldada tarkvara nii süsteemsest pakimajandusest kui ka Pythoni pakendussüsteemide (eeskätt pip) vahenditega, samuti saab hakkama käsureal. Töövahendite paigaldamise juhised on siiski ka artiklis olemas.
Artiklis toodud näited põhinevad katsetustel 64-bitise Kubuntu 12.10 operatsioonisüsteemi all.
Töövahendite paigaldamine
Kui tcpdump ei ole paigaldatud, tuleb see juurkasutajana paigaldada käsuga
apt-get install tcpdump
Wiresharki paigaldame käsuga
apt-get install wireshark
HTTP päringuid on käsurealt mugav teha curl nimelise tööriistaga, paigaldame ka selle.
apt-get install curl
Kuna erinevate Linuxi distributsioonide pakimajanduses ei pruugi alati olla Pythonis kirjutatud tarkvarast väga värskeid versioone, siis mitmproxy paigaldamiseks on mõistlik kasutada pip-i.
apt-get install python-pip pip install mitmproxy
tcpdump ja Wireshark
HTTPS liikluse püüdmiseks kasutame käsureavahendit tcpdump seetõttu, et servereid hallates ei ole meil tihtipeale ligipääsu graafilisele keskkonnale. Samas on Wireshark mugav ja kasutajasõbralik võrguliikluse uurimise töövahend ja tcpdump-i abil salvestatud liiklust saab Wiresharki abil hiljem suvalises teises masinas analüüsida.
Kuna veebiserver on meie hallata, siis on meil olemas tema privaatvõti. See on ainus vajalik sisend Wiresharkile, et ta oskaks kinnipüütud pakette lahti krüpteerida.
Pakettide püüdmine
Kõigepealt paneme tcpdump-i kuulama liiklust liidesel eth1 (antud juhul on see Virtualboxi host-only võrguliides), aadressil 192.168.56.201, pordil 443 (meil on sinna konfitud üks HTTPS toega virtualhost). Seda tuleb teha juurkasutaja õigustes, et meile antaks ligipääs võrguliidesele.
tcpdump -w https_dump.pcap -i eth1 host 192.168.56.201 and port 443
Teeme klientmasinast päringu (öeldes, et usaldame serveri enda poolt allkirjastatud sertifikaati):
curl --insecure https://192.168.56.201
Nüüd lõpetame Ctrl+C abil serveris tcpdumpi töö -- too ütleb lõpetades käsureale midagi sellist:
15 packets captured 15 packets received by filter 0 packets dropped by kernel
Püütud pakettide uurimine
Järgmiseks on vaja tcpdump-i väljundfail saada masinasse, kus meil on võimalik kasutada Wiresharki (kusjuures salvestatud faili uurimiseks ei ole juurkasutaja õiguseid vaja). Käivitame Wiresharki ja avame oma .pcap faili. Esialgu näitab Wireshark küll HTTPS-iga seotud andmevahetust, kuid HTTP päringuid avatekstina pole võimalik näha. Wireshark võimaldab seda krüpteeritud sisuga andmevoogu ka eraldi aknas uurida ("Follow TCP Stream" suvalise paketi kontekstimenüüst).
Järgmiseks hangime serverist tema privaatvõtme (NB! Erinevate virtualhostide olemasolul pead hankima just antud päringus kasutatud IP-le vastava võtme!)
Wiresharkis võtame menüüst "Edit"->"Preferences" avanevas aknas "Protocols" alt "SSL" ja lisame serveri võtme:
Kasulik on seadistada ka SSL debuglogi failitee, et probleemide korral saaks vigu otsida. Näiteks võib juhtuda, et brauseri või serveri krüpto vaikeseadistused on sellised, et Wireshark ei saa pakettide sisu lahti krüpteerida, kuigi serveri privaatvõti ja muud parameetrid on korrektsed.
Nimelt võib juhtuda, et peale võtmefaili määramist ja HTTPS suhtlusega seotud paketi kontekstimenüüs "Follow SSL Stream" valimist näidatakse tühjust.
Sellisel juhul võiks debuglogist otsida sääraseid ridu:
ssl_decrypt_pre_master_secret session uses DH (17) key exchange, which is impossible to decrypt dissect_ssl3_handshake can't decrypt pre master secret
Nimelt Apache2 mod_ssl vaikimisi konfis on lubatud Diffie-Hellman võtmevahetuse protokolli kasutamine, mis aga muudab HTTPS liikluse Wireshark-i jaoks lahtivõetamatuks. Lähemalt loe näiteks: http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange ja http://security.stackexchange.com/questions/8343/what-key-exchange-mechanism-should-be-used-in-tls
Üks võimalikke lahendusi on Apache2 mod_ssl konfis (/etc/apache2/mods-available/ssl.conf) keelata Diffie-Hellman võtmevahetuse tugi, näiteks võtmesõna DH abil:
SSLCipherSuite ALL:!EXP:!NULL:!DH:!LOW
Vt. lähemalt: http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslciphersuite
Peale veebiserveri restarti tuleb teha uus paketipüüdmine. Kui kõik muu on korrektselt tehtud, võib Wiresharkis uue .pcap faili avamisel näha umbes sellist pilti:
mitmproxy
FIXME