wer BayWotch 2.5 zusammen mit Norton Internet Security 2004 (NIS) betreibt, wird feststellen, daß BayWotch bei Onlineaktionen deutlich langsamer arbeitet, wenn der Punkt "Security" von NIS aktiviert ist.
Der Grund ist, daß NIS die Datenkompression unterdrückt, wodurch erheblich größere Datenmengen geladen werden müssen!
Gemeinsam mit Joscha Dzielak, dem Betreiber von SpeedSell, habe ich eine Email an den Heise "Security" Redakteur Daniel Bachfeld geschrieben, der uns im Heise Forum seine Unterstützung anbot.
Die Mail möchte ich als offenen Brief hier veröffentlichen, um die genauen Hintergründe zu verdeutlichen und den Umstand anzuprangern, wie NIS Daten manipuliert.
Ich werde an dieser Stelle berichten, wenn es Neuigkeiten gibt.Sehr geehrter Herr Bachfeld,
Joscha Dzielak schrieb gestern im Heise Forum einen Beitrag mit dem Titel "Wie wäre es mal mit einem Fehlerbericht über den NIS?" ( http://www.heise.de/security/news/foren ... m_id=51708 ). Sie boten in Ihrer Antwort Hilfe an und baten um weitere Informationen.
Joscha teilte mir dies mit, da wir in den letzten Tagen genau zu diesem Thema in Kontakt standen. Unten aufgeführt sind noch einmal die Argumente von Joscha.
Kurz zu meiner Person: Mein Name ist Elmar Denkmann, ich bin Autor der Software "BayWotch", ein eBay Tool, welches auch schon auf der c't Collection 3/2003 enthalten war.
Gestern ging eine neue Betaversion an den Start, die in den letzten Monaten entwickelt und getestet wurde. Diese neue Version arbeitet mit einem selbstentwickelten HTTP Client, welcher auf Winsock Basis HTML Seiten von eBay empfängt.
Einem meiner Betatester fiel nun auf, daß die Übertragung mit aktiviertem Norton Security 2004 merklich langsamer lief, was mich dazu veranlaßte, mir die Software zuzulegen und mein Programm damit zu testen.
Ich staunte nicht schlecht, als ich feststellte, daß NIS offensichtlich den HTTP Header manipuliert, ohne daß der Anwender dies mitgeteilt bekommt geschweige denn dies ändern kann. Dies ist sogar dann bereits der Fall, wenn lediglich der Hauptpunkt "Security" aktiviert ist; Firewall, Virenchecker, Werbeblocker und die ganzen anderen Optionen sind noch deaktiviert!
Das Problem betrifft die Datenkompression, welche mein Tool (genau wie andere Programm auch, z.B. der MS IE) nutzt, um die recht großen HTML Seiten in komprimierter Form zu empfangen. Dem Webserver wird dazu (gem. RFC 2616 http://www.faqs.org/rfcs/rfc2616.html) im HTTP Request Header die Zeile
"Accept-Encoding: gzip"
mitgeschickt, welche besagt, daß der Client GZIP komprimierte Inhalte empfangen kann und möchte.
eBay sendet darauf die passende Antwort. Die Daten werden - wie angefordert - mit GZIP komprimiert und gesendet. Im HTTP Response Header wird dies durch die Zeile
"Content-Encoding: gzip"
bestätigt.
NIS geht nun jedoch hin und manipuliert diese Daten, noch bevor sie beim Client ankommen. Statt der o.g. "Content-Encoding" Zeile empfängt der Client dies hier:
"----------------: ----"
Es wurde hierbei einfach der ursprünglich geschickte "Content-Encoding: gzip" Text ausgestrichen, wahrscheinlich, um die Header Länge nicht zu verändern. Offensichtlich möchte NIS den Inhalt der Seiten im Klartext vorliegen haben, um die Kontrolle über die Inhalte zu behalten.
Die angeforderten Seiten kommen somit jedoch unkomprimiert bei der Anwendung an!
Daß eBay im Normalfall komprimierte Seiten sendet, läßt sich hiermit leicht testen:
http://web-sniffer.net/?url=http%3A%2F% ... s&type=GET
Für mein Programm BayWotch bedeutet dies eine massive Beeinträchtigung der Downloadgeschwindigkeit, da hauptsächlich größere HTML Seiten geladen werden, die mit aktiviertem NIS nicht komprimiert werden können! Zum Vergleich: Eine eBay Suchergebnisseite mit 100 Treffern ist ca. 150 KB groß, komprimiert nur noch 25 KB!
Symantec läßt die Benutzer diesbezüglich im Dunkeln stehen. Weder in der Programmhilfe, noch in den FAQ der Homepage konnte ich zu diesem Thema etwas finden. Eine Anfrage per Mail von 12.01.04 an den US Support blieb bis jetzt unbeantwortet.
Eine Suche im Web und den Newsgroups brachte nur einen einzigen Treffer:
http://groups.google.de/groups?hl=de&lr ... 26rnum%3D1
Abgesehen von den dümmlichen Antworten der Mitleser kam es hier leider zu keiner Klärung. Ich hatte daraufhin den User per Email kontaktiert, in der Hoffnung, daß er zwischenzeitlich näheres herausgefunden hätte... leider Fehlanzeige: Keine weiteren Erkenntnisse.
Ich bin nun soweit, meinen Kunden mitteilen zu müssen, während einer BayWotch Sitzung NIS zu deaktivieren, um die größtmögliche Transfergeschwindigkeit zu erreichen. Daß die Sicherheit dann auf der Strecke bleibt, ist natürlich kontraproduktiv... eine Lösung, die weder mir noch meinen Kunden gefallen wird.
Aus diesem Grunde wäre es schön, wenn man zumindest seitens Symantec ein offizielles Statement dazu bekommen könnte:
"Läßt sich das o.g. Verhalten abstellen, ohne NIS komplett zu deaktivieren?"
Bin gespannt, ob Sie etwas herausfinden können.
Vielen Dank für Ihre Unterstützung. Bei Rückfragen stehe ich gerne zur Verfügung.
Gruß,
Elmar Denkmann
---------------------------------
Software Entwicklung und Vertrieb
Rothe Gasse 30
D-52224 Stolberg
===
Probleme von Joscha Dzielak:
Auch kurz zu meiner Person: Mein Name ist Joscha Dzielak und ich bin Betreiber der Webseite www.speedsell.de. SpeedSell ist ein Programm, welches Verkäufern bei Online-Auktionen die Verwaltung dieser abnimmt.
Hierbei spielt es eine große Rolle, dass meine Benutzer möglichst viele Daten der Auktionen auf einer Übersichtsseite angezeigt bekommen, und somit mit nur wenigen Klicks große Rechnungslisten erstellen und diese dann ausdrucken können (um nur ein Beispiel zu nennen). Da diese Seiten vom Umfang her recht groß werden können, werden sie vom Webserver komprimiert versendet.
Auch hier tritt der Effekt auf, dass der NIS diese Seiten unkomprimiert empfängt und somit die Anzeigegeschwindigkeit der Webseite deutlich bremst.
Neben diesem Problem tritt aber ein noch viel gravierenderes Problem auf, welches auch der NIS hervorruft:
Und zwar werden Seiten ab einer bestimmten Größe gar nicht mehr angezeigt. Dies äußert sich darin, dass die dann angezeigte Seite leer bleibt, eine gecachte Seite angezeigt wird oder der NIS die Seite falsch darstellt (bedeutet: es tauchen mitten im Quelltext Sonderzeichen auf, welche die Seite zerstören)
Die Nutzer meiner Seite sind nun total irritiert und halten die alten Seiten (welche gecached wurden und nicht mehr den aktuellen Datenbestand anzeigen) bzw. die leeren Seiten für ein Indiz, dass mit meiner Web-Anwendung etwas nicht richtig funktioniert.
Ich bekomme täglich Anfragen, ob etwas gerade defekt sei etc. Hierbei brauche ich seit langer Zeit keine weiteren Erklärungen von den Benutzern, sondern kann diese direkt darauf hinweisen, den NIS zu deaktivieren. Bisher war meine Trefferquote bei 100%. Bedeutet - ich kann Benutzern sagen, welche Firewall diese einsetzen aufgrund einer kurzen Mail.
Auch bei mir blieben etliche Anfragen an den Support entweder unbeantwortet oder man speiste mich mit der Antwort ab, dass mein Rechner falsch konfiguriert sei. Einen Hinweis darauf, dass ich selber diese Probleme nicht habe, diese aber bei allen Benutzern auftreten, welche den NIS verwenden, führte dazu, dass der Support mir nicht mehr antwortete.
Auch ich wäre hier dankbar für jede Art der Unterstützung von Ihrer Seite aus, da Sie geschäftlich einen engen Kontakt mit Symantec pflegen bzw. über die Möglichkeit der Berichterstattung auf diese Probleme effizient hinweisen und so eine Lösung forcieren können.
Mit freundlichem Gruss
// Joscha Dzielak
===
P.S.
Nachtrag von Elmar Denkmann:
Auch ich kann die Erfahrungswerte von Joscha bzgl. der Sonderzeichen in großen HTML Seiten bestätigen!! Anbei füge ich einige Screenshots, welche die empfangenen HTML eBay Seiten meiner Kunden zeigen. Auffällig dabei ist öfters das Auftreten von Ausrufezeichen.
Ein klärendes Gespräch mit den Kunden bestätige auch hier: NIS war aktiviert!
NIS werde ich wohl über die angegebene Rufnummer zurück geben. Testen wir mal Dieses aus! 
