Vybalení SSL obsahu z tunelu

[kapetr]

Máme nějakou službu - např. ftps nebo pop3s - čili něco zabaleného do SSL (implicitního).

Z přík. řádky mohu například použít openssl s_client-a:

Kód: [Vybrat]

openssl s_client -connect pop3.volny.cz:995 -CApath /etc/ssl/certs/ -quiet -crlfa krásně pracuji s POP3, jako by tam žádná SSL obálka nebyla.

A co chci ?

Co nejjednodušeji vytvořit nějakým příkazem socket (např. 127.0.0.1 : 10000) na nějž se připojím telnetem, standardním ftp klientem, ... a na něm se spustí ten s_client => rozbalí mi  obsah z SSL obálky.
(Čili STDIN/OUT příkazu (např. s_client)) provázat s tím lokálním socketem - nic víc, nic míň !?)

Myslel jsem na stunnel, inetd, ale chtěl jsem to zkusit "jednodušeji" - jen na př. řádku, ale ničeho jsem se nedobral.

Zkusil jsem třeba

Kód: [Vybrat]

$ micro-inetd 10000 "openssl s_client -connect pop3.volny.cz:995 -CApath /etc/ssl/certs/ -quiet -crlf"

... ale

$ telnet 127.0.0.1 10000
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
execl: No such file or directory
Connection closed by foreign host.



Zkusil jsem přes micro-inetd spustit i bash. či pouhé echo, ale vždy to skončilo stejnou chybou.

Také jsem četl man stránky od příkazů netcat (nc) a socket, ale nenapadá mě, jak to udělat.

Neporadí mi prosím někdo ?

Díky.

[Reklama]

[Mirek Prýmek]

Kód: [Vybrat]

socat openssl:pop3.volny.cz:995,verify=0 stdio
Misto stdio si pak das cokoli potrebujes.

[kapetr]

Nerozumím ...

výstup obsahu z SSL na STDIN/OUT mi dává přímo s_client.

Já potřebuji dostat tento STDIN/OUT dostat na lokální soket (např 127..0.1:10000), abych k němu mohl přistupovat telnetem, ftp klientem, ...

[Mirek Prýmek]

Já potřebuji dostat tento STDIN/OUT dostat na lokální soket (např 127..0.1:10000), abych k němu mohl přistupovat telnetem, ftp klientem, ...

...a přesně to je primární účel socatu. Viz např. http://www.cyberciti.biz/faq/linux-unix-tcp-port-forwarding/

Jenom mi není úplně jasné, jak chceš na imap přistupovat ftp klientem

[kapetr]

Jenom mi není úplně jasné, jak chceš na imap přistupovat ftp klientem

Pochopitelně jsem mínil přistupovat příslušnými klienty (popř. telnetem) k příslušným službám.
Např. standardním FTP klientem k "vybalenému" FTPS.
Nebo si prohlédnout HTTP konverzaci "vybalenou" z HTTPS, atd ...

Blíže jsem si pročetl man socat a děkuji - zřejmě to to bude to, co jsem hledal.

Správné použití pro mnou žádaný příklad je:

Kód: [Vybrat]

$ socat openssl:pop3.volny.cz:995,CApath=/etc/ssl/certs TCP4-LISTEN:10000a klient:

Kód: [Vybrat]

$ telnet 127.0.0.1 10000
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
+OK BalaPop3 server ready for users @volny.cz
user xxxxxxx
+OK user accepted
pass yyyyyyy
+OK welcome
stat
+OK 193 7747402
quit
+OK thPOP3 server says 'Bye!'
Connection closed by foreign host.

Děkuji a zdravím.

P.S.: to https se mi zatím nějak nedaří: socat openssl:www.fio.cz:443,CApath=/etc/ssl/certs TCP4-LISTEN:10000

[Reklama]

[Mirek Prýmek]

Pochopitelně jsem mínil přistupovat příslušnými klienty (popř. telnetem) k příslušným službám.

To byl hloupý pokus o hloupý vtip

P.S.: to https se mi zatím nějak nedaří: socat openssl:www.fio.cz:443,CApath=/etc/ssl/certs TCP4-LISTEN:10000

A v čem je problém?

Kód: [Vybrat]

# socat openssl:www.fio.cz:443,verify=0 TCP4-LISTEN:10000,reuseaddr

# telnet localhost 10000
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.1
host: www.fio.cz

HTTP/1.0 301 Permanently moved.
Date: Sat, 28 Nov 2015 18:22:58 GMT
Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips PHP/5.4.16
Set-Cookie: PHPSESSID=8ddmc6qa5a258g958q4le7pve1; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: webLng=1; expires=Mon, 28-Dec-2015 18:23:06 GMT; path=/
Location: http://www.fio.cz/
X-Frame-Options: SAMEORIGIN
Content-Length: 0
Connection: close
Content-Type: text/html; charset=windows-1250

Connection closed by foreign host.


[kapetr]

Problém je v tom, že jsem získal stejnou reply. A ta není to, co jsem čekal.
Viz http://www.checkupdown.com/status/E301.html

Nevidím v odpovědi, kam jinam jít.

Zkusil jsem ve FF otevřít 127.0.0.1:10000 a nic. Ale neměl jsem momentálně čas to blíže zkoumat.

[Mirek Prýmek]

Problém je v tom, že jsem získal stejnou reply. A ta není to, co jsem čekal.

Inu, pro / je tam redirect z HTTPS na HTTP (Location: http://www.fio.cz/). Si to zkus v prohlizeci bez toho tunelu, ze te to taky z https hodi na http.

Pokud pristoupis na stranku, kde redirect nemaji a vali to po https, tak dostanes to, co (predpokladam) chces:

Kód: [Vybrat]

# telnet localhost 10000
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /e-broker/e-broker.cgi HTTP/1.1
host: www.fio.cz

HTTP/1.1 200 OK
Date: Sat, 28 Nov 2015 19:14:16 GMT
Server: Apache-Coyote/1.1
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: no-cache
Cache-Control: no-store
Content-Type: text/html;charset=UTF-8
Content-Language: cs
Vary: Accept-Encoding
X-Frame-Options: SAMEORIGIN
Transfer-Encoding: chunked

[...]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">


<html>
<head>
<title>e-Broker: Login - 20:14:16</title>

Můžu se zeptat, co s tím máš v plánu dělat?

[kapetr]

Toho redirektu https->http jsem si nevšiml.

Obecně - vícekrát jsem se setkal se situací, kdy z neznámých důvodů selhávala komunikace (přihlašování pře https, smtps, sips, ...) a já se chtěl podívat na komunikaci ve wiresharku, ale pochopitelně jsem viděl zašifrované ... nic :-)
Nebo např, midnight-commander nepodporuje pro svůj ftpfs ftps protokol - takže proč mu pro konkrétní spojení nenadefinovat takovouto vybalovací proxy. Atd ...

Co se týče toho firefoxu na 127.0.0.1:10000, tak jsem z wiresharku zjistil, že je by byl problém v "načasování" ?
FF pošle SYN v době, kdy socat teprve resolvuje fio.cz a odpoví RST-ACK a FF to okamžitě (?!) vzdá.
Při použití telnetu to tak není.

Přitom si myslím, že by socat měl být tím SYN na loc:10000 vzbuzen a pak teprve navazovat komunikaci s fio.cz a trpělivě čekat na (jakožto "proxy") mezi komunikujícími stranami a předávat data.
Nevím, proč na SYN na loc:10000 reaguje RST-ACK jen proto (?), že ještě nemá navázané spojení s fio.cz.
A také nevím, proč se to liší, je-li klientem telnet. Nemůže to být pomalostí člověk+telnet, protože jde o reakci už na na SYN.

Takže FF x [socat proxy] zatím nejde. Nevím proč.

[Mirek Prýmek]

Co se týče toho firefoxu na 127.0.0.1:10000, tak jsem z wiresharku zjistil, že je by byl problém v "načasování" ?
FF pošle SYN v době, kdy socat teprve resolvuje fio.cz a odpoví RST-ACK a FF to okamžitě (?!) vzdá.
Při použití telnetu to tak není.

Přitom si myslím, že by socat měl být tím SYN na loc:10000 vzbuzen a pak teprve navazovat komunikaci s fio.cz a trpělivě čekat na (jakožto "proxy") mezi komunikujícími stranami a předávat data.
Nevím, proč na SYN na loc:10000 reaguje RST-ACK jen proto (?), že ještě nemá navázané spojení s fio.cz.
A také nevím, proč se to liší, je-li klientem telnet. Nemůže to být pomalostí člověk+telnet, protože jde o reakci už na na SYN.

Takže FF x [socat proxy] zatím nejde. Nevím proč.

Myslím, že sis něco nějak špatně vyložil, protože ten socat prvně naváže spojení a čeká. Pokud ho spustíš, můžeš si ověřit, že má navázané spojení (bez toho, abys na ten port 10000 ještě přistoupil):

Kód: [Vybrat]

# netstat -p | grep soca
tcp        0      0 XXXXXXXX:60206   www.fio.cz:https            ESTABLISHED 25019/socat
Spíš pokud to zkoušíš na tom /, tak se to chová správně: server po https pošle redirect (301) a ukončí spojení. Čili i socat spojení ukončí. Při přístupu na tu cestu e-brokeru se to neděje - server pošle 200 + odpověď a čeká na další request.

Pokud se zkusím (z Chromu) dostat na http://www.fio.cz:10000/e-broker/e-broker.cgi, tak normálně stránku dostanu, jenom bez CSS, které je asi umístěné někde jinde, to jsem nezkoumal. Můžu tam i klikat, jenom musím kliknout dostatečně rychle, než server spojení zavře. Pokud chceš, aby socat po uzavření spojení serverem otevřel nové (tj. abys mohl v prohlížeči normálně klikat dle libosti), musíš mu to říct. Viz manuál. Teď z hlavy si to přesně nepamatuju, ale bude to asi něco ve stylu:

Kód: [Vybrat]

socat openssl:www.fio.cz:443,verify=0 TCP4-LISTEN:10000,reuseaddr,fork

Samozřejmě předpokládám, že máš správně přesměrované www.fio.cz na localhost v /etc/hosts

[Mirek Prýmek]

P.S. tím "RST-ACK" neodpovídá socat, to je starost operačního systému. Software jenom otevírá a zavírá sockety, o nic víc se nezajímá. Všechny ty ACK, FIN, RST... jsou toho jenom důsledkem, posílá je OS.

[Filip Jirsák]

Obecně - vícekrát jsem se setkal se situací, kdy z neznámých důvodů selhávala komunikace (přihlašování pře https, smtps, sips, ...) a já se chtěl podívat na komunikaci ve wiresharku, ale pochopitelně jsem viděl zašifrované ... nic :-)
Nebo např, midnight-commander nepodporuje pro svůj ftpfs ftps protokol - takže proč mu pro konkrétní spojení nenadefinovat takovouto vybalovací proxy. Atd ...

Přesně tohle dělá stunnel, ne?

Případně pokud aplikace umí vyexportovat klíč, který si obě strany dohodly pro SSL, umí s ním pak Wireshark komunikaci dekódovat.

[kapetr]

S tím navázání spojení socat-em hned po spuštění máte pravdu. Nevím, kam sem koukal - několikrát! A po spuštění wiresharku se mi pakety hned nezobrazovaly. Teď ano - takže zjevně byla chyba ve mně - jako často :-)

Stejně to ale myslím nevysvětluje, proč jsem po spuštění socatu dostal následně telnetem alespoň ten "HTTP/1.0 301", zatímco FF jen ten RST-ACK. Jakou to má logiku ?

Vím určitě, že jsem ve wiresharku viděl SYN na loc:10000 (od FF) v době, kdy socat&co teprve resolvoval fio.cz.
A FF dostal RST-ACK. Možná protože socat čekal s LISTEN až mu openssl naváže spojení ?
Ne, ne v tom musí být ještě něco jiného - pak jsem zkusil před zavoláním FF chvíli počkat, takže SSL už musel být navázán - a stejně FF dostal na SYN jen RST-ACK.

Později to znovu prozkoumám s čistou hlavou. K problému s hosts  jsem se zatím nedostal, protože to vždy skončilo dříve, než začalo.

Zatím díky.

[kapetr]

Případně pokud aplikace umí vyexportovat klíč, který si obě strany dohodly pro SSL, umí s ním pak Wireshark komunikaci dekódovat.

S tím zatím nemám zkušenost. To by mohlo být zajímavé.
Která aplikace to umí ? Nějaké spec. verze ? A existuje třeba nějaký doplněk pro FF ?

[Filip Jirsák]

S tím zatím nemám zkušenost. To by mohlo být zajímavé.
Která aplikace to umí ? Nějaké spec. verze ? A existuje třeba nějaký doplněk pro FF ?

Já jsem to potřeboval pro Javu – mělo by fungovat vypsání klíče v debugovacích informacích přes -Djavax.net.debug=ssl,keygen a pak klíč zkonvertovat přes keygen2keylog. Nebo já jsem použil extract-ssl-secrets.

Pro FF by mohlo pomoci tohle: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format