Teraz może przejdzie, serwer news nie lubi w treści wyrażenia
"Content-Typx:" (e muszę zamienić na x)
Od kilku tygodni męczyłem się z pewnym problemem z t-mobile. Mam
dedykowany APN, stały IP. Wykorzystywane jest to dla serwera apache,
który udostępnia swoje zasoby. Od kilku tygodni pojawił się dziwny
problem, w połączeniu do serwera (przy odwołaniach do / lub
/index.html) wstrzykiwany jest pakiet zawierający:
--cut here---
HTTP/1.0 Found.
Location: http://www.t-mobile.pl/blueconnect_kam/id_44
Content-Typx: text/html; charset=iso-8859-1
Proxy-Connection: close
The document has moved.
--cut here----
Powyższy payload nie ma sensu w kontekście połączenia
przeglądarka->serwer. Nie wysyła go przeglądarka, ale mimo to dociera
coś takiego do serwera - wygląda jak typowy MITM. Pakiet pojawia się
tuż po "oryginalnym" pakiecie z payloadem requestu z przeglądarki do
serwera:
GET / HTTP/1.0
User-Agent: Wget/1.12 (linux-gnu)
Accept: */*
Host: xxxxx.pl
Connection: Keep-Alive
Przez co do serwera docierają dwa requesty (w tym samym połączeniu):
---cut here-------
GET / HTTP/1.0
User-Agent: Wget/1.12 (linux-gnu)
Accept: */*
Host: xxxxx.pl
Connection: Keep-Alive
HTTP/1.0 Found
Location: http://www.t-mobile.pl/blueconnect_kam/id_44
Content-Typx: text/html; charset=iso-8859-1
Proxy-Connection: close
--cut here----
Na pierwszą część owego cudaka serwer odpowiada kontentem / a na
drugą Bad Request. Do przeglądarki nie docierają jednak te odpowiedzi
a tylko pakiet reset (!?) zamykający połączenie. Wget (przeglądarka)
widzi to tak:
$ wget http://xxxx.pl
---request begin---
GET / HTTP/1.0
User-Agent: Wget/1.12 (linux-gnu)
Accept: */*
Host: xxxx.pl
Connection: Keep-Alive
---request end---
Żądanie HTTP wysłano, oczekiwanie na odpowiedź... Błąd odczytu
(Połączenie zerwane przez drugą stronę) w nagłówkach. Closed fd 3
Ponawianie próby. itd. Co ciekawe ów MITM pojawia się tylko gdy
wywołuje się url na serwerze zawierający:
/
/index.htm[l]
/index.php
/index.asp
pozostałe urle działają prawidłowo (prawidłowa odpowiedź serwera).
Coś mnie tknęło i sprawdziłem jak wygląda próba połączenia na :80 z
dowolnym sajtem od strony serwera (przez t-mobile):
# wget onet.pl
--2015-04-29 20:38:48--
http://onet.pl/Translacja onet.pl... 213.180.141.140 Łączenie się z onet.pl|213.180.141.140|:80... połączono.
Żądanie HTTP wysłano, oczekiwanie na odpowiedź... 302
Found Lokalizacja: http://www.t-mobile.pl/pl/blueconnect_kam/id_44 [podążanie] --2015-04-29 20:38:49--
http://www.t-mobile.pl/pl/blueconnect_kam/id_44
Translacja www.t-mobile.pl... 83.220.101.56 Łączenie się z
www.t-mobile.pl|83.220.101.56|:80... połączono.
Żądanie HTTP wysłano, oczekiwanie na odpowiedź... 301 Moved
Permanently
Lokalizacja: http://www.t-mobile.pl [podążanie] --2015-04-29 20:38:49--
http://www.t-mobile.pl/
Ponowne użycie połączenia do www.t-mobile.pl:80.
Żądanie HTTP wysłano, oczekiwanie na odpowiedź... 302 Found
Lokalizacja: http://www.t-mobile.pl/pl/blueconnect_kam/id_44 [podążanie] -
-2015-04-29 20:38:49-- http://www.t-mobile.pl/pl/blueconnect_kam/id_44
Łączenie się z www.t-mobile.pl|83.220.101.56|:80... połączono.
Wszystko jasne. Przy drugiej próbie:
# wget onet.pl
--2015-04-29 20:39:25-- http://onet.pl/
Translacja onet.pl... 213.180.141.140
Łączenie się z onet.pl|213.180.141.140|:80... połączono.
Żądanie HTTP wysłano, oczekiwanie na odpowiedź... 301 Moved
Permanently
Lokalizacja: http://www.onet.pl [podążanie]
--2015-04-29 20:39:25--
http://www.onet.pl/
Translacja www.onet.pl... 213.180.141.140 Ponowne użycie połączenia
do onet.pl:80.
Żądanie HTTP wysłano, oczekiwanie na odpowiedź... 200 OK Długość:
275701 (269K) [text/html] Zapis do: `index.html'
Wszystko jasne. Od tego momentu problem zniknął. Jakiś geniusz w t-mobile
wymyślił, że przy każdym nowy zestawionym połączeniu klient musi odwiedzić
http://www.t-mobile.pl/pl/blueconnect_kam/id_44
Co ciekawe i tak ten url jest nieprawidłowy, bo przekierowuje do /.
--
Marek
|