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