[hybi] Report of a dirty WS blocking issue with OfficeScan

Willy Tarreau <w@1wt.eu> Fri, 16 March 2012 10:18 UTC

Return-Path: <w@1wt.eu>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE16221F85C2 for <hybi@ietfa.amsl.com>; Fri, 16 Mar 2012 03:18:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.198
X-Spam-Level:
X-Spam-Status: No, score=-5.198 tagged_above=-999 required=5 tests=[AWL=-3.155, BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+5eGqG1HJa6 for <hybi@ietfa.amsl.com>; Fri, 16 Mar 2012 03:18:56 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 0600421F85AC for <hybi@ietf.org>; Fri, 16 Mar 2012 03:18:54 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q2GAIoqu010354; Fri, 16 Mar 2012 11:18:50 +0100
Date: Fri, 16 Mar 2012 11:18:50 +0100
From: Willy Tarreau <w@1wt.eu>
To: hybi@ietf.org
Message-ID: <20120316101850.GA10202@1wt.eu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Cc: Jason Strimpel <jstrimpel@gmail.com>
Subject: [hybi] Report of a dirty WS blocking issue with OfficeScan
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Mar 2012 10:18:57 -0000

Hi,

I'm posting this here as Jason is not subscribed to the list, please
keep him CCed for any response or for more details.

A few months ago I was contacted by Jason Strimpel (CCed) about an issue
with WS and haproxy. From the server side, the handshake correctly worked,
the server sent some data but the client never replied. To make the long
story short, after many tests, network captures, etc... it became obvious
that the data were not leaving the client for connections going to port
80. What made it look like it was haproxy was the fact that connecting
directly to the server on port 8000 used to work.

After inspecting all components deployed on the desktop, Jason found
that Trend Micro's OfficeScan was installed on the machine, and that
disabling it fixed the issue. It seems like this product inspects
outgoing traffic to port 80, doesn't understand HTTP 101+Upgrade and
blocks any further outgoing traffic without closing the connection
(probably that it considers 101 as 200 and the lack of content-length
as a close mode).

It would be nice to know if minor adaptations to the handshake could
make such connections fail cleanly and quickly. I wonder if just sending
"Content-length: 0" in responses would workaround such components. If
the product considers that 101 is a final response, at least with cl:0
it should wait for a new request and reject further client data as an
invalid request. Possibly that if this works, adding "Connection: close"
in the response would also handle the situation when the client expects
the server to speak first.

These are some of the tests we could possibly do with Jason as he has
access to the faulty device.

I wanted to report this here so that nobody needlessly wastes as much time
on a similar issue. We'll report here if we find an simple workaround for
the issue so that the connection fails cleanly.

Regards,
Willy