🚀 go-pugleaf

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