Mitmproxy posílá požadavky zpět na klienta

[SamElanius]

Zdravim,
zkousim si pouziti mitmproxy. Infrastruktura vypada takto:
Client - odposlouchavany odesila pozadavky na http do internetu
router odklani jeho pozadavky na proxy server (rovnou smeruje na port 8080, na serveru tedy nejsou pravidla pro preposilani z 80/433 -> 8080)
proxy server - zde je nainstalovany mitmproxy a spusteny v transparentnim modu.

Problemem je to, ze proxy prijme pozadavek od klienta, ale misto toho aby udelala ten samy pozadavek na cilovou adresu, odesle udela ho na zdrojoveho klienta (ten samozrejme nema vystavenou 80 -> okamzite refuse -> proxy vrati na puvodni pozadavek 402).

Nemate predstavu kde by mohl byt problem? Dekuji

[Reklama]

[AgentK]

Zdar,
není mi úplně přesně jasný design toho přesměrování: pokud je router zároveň proxy a děláš redirect preš TPROXY, pak by to mělo fungovat. TPROXY target zajistí přesun informace o cílové adrese, přestože to spojení naváže na lokální naslouchací socket. Proxy pak může zjistit skutečnou cílovou adresu, a navázat nové spojení, ať už se zdrojovou IP vlastní, nebo transparentně - se zdrojovou IP původního klienta.
Je to celkem netriviální problém, pokud se do toho zamotá ještě IPv6 - tam je třeba rozumně nové jádro.

Naopak pokud je proxy někde na jiném stroji než router, TPROXY nebude fungovat, informace o původní dst adrese se ztratí, a transparentní to asi nikdy nebude.

Takže bychom potřebovali vědět více :-)

Shameless plug: můžeš zkusit použít mojí smithproxy.org. Pokud děláš něco zajímavého, můžu to dokódit nebo poradit jak to nastavit.

[Filip Jirsák]

Moc jste nepopsal, jak vypadá vaše testovací síť její konfigurace – třeba „odklání požadavky“ je dost široký pojem a vůbec není jasné, jestli je to třeba DNAT nebo něco jiného. Pokud by to byl právě NAT, je to špatně, požadavky na mitmproxy v transparentním módu musí být směrované přímo, bez NATu.

[Vilith]

Moc jste nepopsal, jak vypadá vaše testovací síť její konfigurace – třeba „odklání požadavky“ je dost široký pojem a vůbec není jasné, jestli je to třeba DNAT nebo něco jiného. Pokud by to byl právě NAT, je to špatně, požadavky na mitmproxy v transparentním módu musí být směrované přímo, bez NATu.

Jen jsi zapomnel doplnit nejaky odkaz, ktery mozna pomuze - https://docs.mitmproxy.org/stable/howto-transparent/

[SamElanius]

Zdravim,
opravdu byla chyba v architekture presmerovani. Tu jsem aktualne zmenil, ale mam jiny problem.
Nyni mam na odposlouchavanem serveru nastaveny proxyserver jako vychozi branu (z dokumentace to je ten prvni pripad u transparent proxy) a mam i importovane certifikaty. A nyni:
1. udelam wget na zabezpecenou stranku
2. proxy odposlechne a prebali komunikaci - na proxy vidim obsah dotazu i odpovedi
3. wget nenahlasi problem s certifikatem - vse se tvari ok
4. ALE wget stahne rozsypany caj (mozna nejak zasifrovanou komunikaci)

jedu presne podle manualu. Zkousel jsem to na 2 verzich mitmproxy (na dvou ruznych strojich) a na obou stejne.

[Reklama]

[czipis]

zkus pridat mitproxy parametr --anticomp nebo -z

[SamElanius]

Anticomp nepomohl. Pridavam vypisy z clienta i proxy:

Kód: [Vybrat]

root@xxxxx:/opt/test# wget https://seznam.cz
\--2019-03-22 14:49:21--  https://seznam.cz/
Resolving seznam.cz (seznam.cz)... 77.75.77.53, 77.75.79.39, 77.75.79.53, ...
Connecting to seznam.cz (seznam.cz)|77.75.77.53|:443... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: https://www.seznam.cz/ [following]
--2019-03-22 14:49:22--  https://www.seznam.cz/
Resolving www.seznam.cz (www.seznam.cz)... 77.75.79.53, 77.75.77.39, 77.75.77.53, ...
Connecting to www.seznam.cz (www.seznam.cz)|77.75.79.53|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: 'index.html.5'

index.html.5                                                    [ <=>                                                                                                                                      ]  50.45K  --.-KB/s    in 0s

2019-03-22 14:49:22 (99.7 MB/s) - 'index.html.5' saved [51663]


Kód: [Vybrat]

xxx:~ xxx$ mitmproxy --mode  transparent --showhost --anticomp
Proxy server listening at http://*:8080
10.0.10.60:55162: clientconnect
10.0.10.60:55162: GET https://seznam.cz/
               << 302 Moved Temporarily 154b
10.0.10.60:48746: clientconnect
10.0.10.60:48746: GET https://www.seznam.cz/
               << 200 OK 50.45k
10.0.10.60:55162: clientdisconnect
10.0.10.60:48746: clientdisconnect

obsah souboru (od zacatku nekolik radek):

Kód: [Vybrat]

�[s�.�>�"
e5��aH��j�II%�nQŮQo�$y�T�$���z��e�p^�Vk��5�c�Y�ټ�5� �H��u��L$�o"Q�D������H���_�}����6�n`[w�)I���L�X�ٻ]���,��
                                                                                                            ��8\��$�k�7��[����� ��.��W�[���$��h]��,��]�U �yF`�;[l�P�(ġ==$�W�Ɖ����%�kN��n�
=���YdhL_V���A-�ר�n�+ĆB�d��v!2�k�{�(>�|�Kg��n`p'C�S�sh4��E<��ѻ��`��e�9��sX�#�
�F����AD�ޮ��԰5��:�a�z�B��/Lwyt���?����ԇǔpݤxnB]���g��]�.׍�8�k�U�u-C��*S2M��[��X�c�Y ���`H�c�(��믖J�_�.�I �i`�����)�~�]/W��F� |���6>ϭ�$))�L7hɰ�J��2��v�J�u�
��˼����VA^��o����.�F�#�?�U�t`���n����BϺ]
?tQJ��t<��g^��#stc�O�r��F�_q�bh]��!�z~/g_��h�G����ӧ/ϼ�.��م�'��/�h���bK;�NOˮ�ٟ�A]�q�����}v6�|2|�e>��
                                                                                                  �y�-���)�g�Ӻ 3���
                                                                                                                   ��/ɷx��


[Filip Jirsák]

Proxy server listening at http://*:8080

Tohle je divné. Vy zkoušíte protokol HTTPS, tedy potřebujete, aby mitmproxy očekával od klienta protokol HTTPS – tohle ale vypadá, že očekává HTTP.

Proxy se10.0.10.60:55162: GET https://seznam.cz/

A tohle je také divné, za HTTP metodou je normálně jenom cesta, název serveru se přenáší v hlavičce Host, případně v SNI rozšíření TLS. A protokol v požadavku není uveden vůbec. Pokud to není jenom způsob, jakým to vypisuje mitmproxy, vypadá to, jako by to byl požadavek na HTTP proxy server – jako byste v tom prostředí, kde spouštíte wget, měl nastavené proměnné prostředí HTTP_PROXY a HTTPS_PROXY a na tom mitmproxy se neodchytávala komunikace s cílovým serverem, ale komunikace s proxy serverem.

[SamElanius]

I v dokumentaci je ze http i https se smeruje na jeden port a ze se nepridava zadny prepinac jestli to ma byt http/https proxy. Z toho mi plyne, ze by mel zvladat oboje ale tento zapis je trochu zavadejici.

V systemu aktualne neni vyexportovane ani HTTP_PROXY ani HTTPs_PROXY.

Na proxyserveru (tam kde je mitmproxy abych byl presnejsi) jsem udelal jen to co je popsano zde https://docs.mitmproxy.org/stable/howto-transparent/.

Nicmene dokud jsem nenaimportovat certifikat tak wget hlasil nevalidni cert. Tzn. asi to po https pujde.

[Filip Jirsák]

Zkuste ten wget spustit s parametrem -d, ať vidíte, jaké přesně požadavky odesílá a jaké dostává odpovědi.

Edit: Pardon, u wgetu je to -d. -v má curl.

[SamElanius]

Kód: [Vybrat]

DEBUG output created by Wget 1.18 on linux-gnu.

Reading HSTS entries from /root/.wget-hsts
URI encoding = 'ANSI_X3.4-1968'
converted 'https://seznam.cz' (ANSI_X3.4-1968) -> 'https://seznam.cz' (UTF-8)
Converted file name 'index.html' (UTF-8) -> 'index.html' (ANSI_X3.4-1968)
--2019-03-22 17:01:29--  https://seznam.cz/
Certificates loaded: 152
Resolving seznam.cz (seznam.cz)... 77.75.77.39, 77.75.77.53, 77.75.79.39, ...
Caching seznam.cz => 77.75.77.39 77.75.77.53 77.75.79.39 77.75.79.53 2a02:598:2::1053 2a02:598:a::79:39 2a02:598:a::79:53 2a02:598:2::1039
Connecting to seznam.cz (seznam.cz)|77.75.77.39|:443... connected.
Created socket 3.
Releasing 0x0000564eedfaca80 (new refcount 1).

---request begin---
GET / HTTP/1.1
User-Agent: Wget/1.18 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: seznam.cz
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 302 Moved Temporarily
Server: nginx
Date: Fri, 22 Mar 2019 16:01:29 GMT
Content-Type: text/html
Content-Length: 154
Connection: keep-alive
Location: https://www.seznam.cz/

---response end---
302 Moved Temporarily
Registered socket 3 for persistent reuse.
Location: https://www.seznam.cz/ [following]
Skipping 154 bytes of body: [<html>
<head><title>302 Found</title></head>
<body bgcolor="white">
<center><h1>302 Found</h1></center>
<hr><center>nginx</center>
</body>
</html>
] done.
URI content encoding = None
converted 'https://www.seznam.cz/' (ANSI_X3.4-1968) -> 'https://www.seznam.cz/' (UTF-8)
Converted file name 'index.html' (UTF-8) -> 'index.html' (ANSI_X3.4-1968)
--2019-03-22 17:01:29--  https://www.seznam.cz/
Resolving www.seznam.cz (www.seznam.cz)... 77.75.77.53, 77.75.79.39, 77.75.79.53, ...
Caching www.seznam.cz => 77.75.77.53 77.75.79.39 77.75.79.53 77.75.77.39 2a02:598:a::79:53 2a02:598:2::1039 2a02:598:2::1053 2a02:598:a::79:39
Connecting to www.seznam.cz (www.seznam.cz)|77.75.77.53|:443... connected.
Created socket 4.
Releasing 0x0000564eee35f5f0 (new refcount 1).

---request begin---
GET / HTTP/1.1
User-Agent: Wget/1.18 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: www.seznam.cz
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 22 Mar 2019 16:01:29 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self'
Content-Encoding: gzip

---response end---
200 OK
Disabling further reuse of socket 3.
Registered socket 4 for persistent reuse.
URI content encoding = 'UTF-8'
Length: unspecified [text/html]
Saving to: 'index.html'

[Filip Jirsák]

Kód: [Vybrat]

Accept-Encoding: identity


Kód: [Vybrat]

Content-Encoding: gzip


wget Seznamu řekne, že nemá používat žádnou kompresi, ale Seznam to ignoruje a pošle soubor zazipovaný. Je to chyba na straně Seznamu, asi nepočítají s tím, že by někdo kompresi nepodporoval. Kdybyste ten přijatý soubor rozbalil gzipem, měl byste dostat správný obsah.

Nebo zkuste

Kód: [Vybrat]

curl --compressed https://www.seznam.cz
Překvapuje mne, že wget kompresi neumí vůbec a u curl se musí explicitně zapnout, jinak hlavičku serveru ignoruje (i když v tomto případě je chybná odpověď serveru). A taky mne překvapuje, že jde vůbec nginx nakonfigurovat tak, aby odpovídal takhle špatně.

[SamElanius]

Souhlasim. Zkusil jsem wget na stroji mimo proxy, a stejne chovani. Proste spatny vyber testovaciho vzorku, root.cz to nedela Velice dekuji za pomoc, tohle by me nenapadlo. V pondeli to zkusim nasadit na cilovy system.