Hallo Admins und Netzwerkler,
kennt jemand sowas - eine Firewall zerstört HTTP-Responses?
Ich habe bisher noch nichts passendes bei gefunden beim Suchen (falsch
gesucht?).
Ein CGI-Script biete etwas zum Download an:
Content-Type: application/octet-stream\r\n
Content-Disposition: attachment; filename="test.file"\r\n
Beim Client kommt folgendes an (siehe die Dumps am Ende)
Content-Type: application/octet-stream\r\n
Content-Disposition: attachment; filename="test.file\0\r\n
Interesannterweise ist das Problem nur mit einem Opera auf Clientseite
aufgefallen, der Firefox scheint da robuster oder nachlässiger zu sein.
Nun zu den Dumps:
Der Server in einer DMZ hinter einer Firewall+NAT (unbekanntes Produkt,
vermutlich Cisco PIX), der Client ebenfalls hinter einer Firewall+NAT
(Linux) - daher die z.T. privaten Adressen von Server und Client.
Server Client
(mein Laptop)
192.168.231.97 | ***.158.12.203 <---> 88.72.186.34 | 192.168.7.45
Hier die Dumps für den Request, einmal auf der Server- und einmal auf
der Clientseite. Die m.E. nach interessanten Stellen habe ich markiert.
Die Dumps sind direkt auf den betroffenen Maschinen erstellt worden.
<< CLIENT >>
#
T 192.168.7.45:48040 -> ***.158.12.203:80 [AP]
GET /tools/download.cgi HTTP/1.1..Host: ***.*************.**..User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.
9.0.6) Gecko/2009020409 Iceweasel/3.0.6 (Debian-3.0.6-1)..Accept: text/html,application/xhtml+xml,application/xml;q=0.9
,*/*;q=0.8..Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3..Accept-Encoding: gzip,deflate..Accept-Charset: ISO-88
+ 59-1,utf-8;q=0.7,*;q=0.7..Keep-Alive: 300..Connection: keep-alive..Referer: http://***.*************.**/tools/..Authori
zation: Basic ************....
##
T ***.158.12.203:80 -> 192.168.7.45:48040 [AP]
HTTP/1.1 200 OK..Date: Sun, 08 Mar 2009 23:22:41 GMT..Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny2 with Suhosin-Pat
+ ch mod_ssl/2.2.9 OpenSSL/0.9.8g mod_perl/2.0.4 Perl/v5.10.0..Content-Disposition: attachment; filename="test.file...Tra
nsfer-Encoding: chunked..Connection: close..Content-Type: application/octet-stream....
##
T ***.158.12.203:80 -> 192.168.7.45:48040 [AP]
24..
##
T ***.158.12.203:80 -> 192.168.7.45:48040 [AFP]
Das ist ein schlichter b..ser Text....0....
##exit
<< SERVER >>
#
T 88.72.186.34:48040 -> 192.168.231.97:80 [AP]
GET /tools/download.cgi HTTP/1.1..Host: ***.*************.**..User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.
9.0.6) Gecko/2009020409 Iceweasel/3.0.6 (Debian-3.0.6-1)..Accept: text/html,application/xhtml+xml,application/xml;q=0.9
,*/*;q=0.8..Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3..Accept-Encoding: gzip,deflate..Accept-Charset: ISO-88
+ 59-1,utf-8;q=0.7,*;q=0.7..Referer: http://***.*************.**/tools/..Authorization: Basic ************....
##
T 192.168.231.97:80 -> 88.72.186.34:48040 [AP]
HTTP/1.1 200 OK..Date: Sun, 08 Mar 2009 23:22:41 GMT..Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny2 with Suhosin-Pat
+ ch mod_ssl/2.2.9 OpenSSL/0.9.8g mod_perl/2.0.4 Perl/v5.10.0..Content-Disposition: attachment; filename="test.file"..Tra
nsfer-Encoding: chunked..Content-Type: application/octet-stream....24..Das ist ein schlichter b..ser Text....
##
T 192.168.231.97:80 -> 88.72.186.34:48040 [AP]
0....
#####exit
Auffällig ist, daß beim Server das "Keep-Alive" vom Client nicht
ankommt. Aber das würde vielleicht nicht weiter stören. Schlimmer ist,
daß das vom Server gesendete <<filename="test.file">> zu
<<filename="test.file\0>> wird. (Hier im Dump ist dort nur "." zu sehen,
aber im Hex-Output ist es \0. Für mich sieht's aus wie "off-by-one" in
einem HTTP-Sanitizing-Versuch.?
Viele Grüße
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann HS12-RIPE -----------------------------------------
gnupg encrypted messages are welcome - key ID: 48D0359B ---------------
gnupg fingerprint: 3061 CFBF 2D88 F034 E8D2 7E92 EE4E AC98 48D0 359B -