Subject: [hybi] outbound HTTPS inspection

From: Tobias Oberstein <[email-masked]>
Date: Fri, 5 Aug 2011 23:43:20 -0700

In the presence of explicit or transparent http proxies, a WebSocket
connection is more likely to work when done over wss.

However, what about https intermediaries breaking up the "end-to-end" secure
connection, acting as a man-in-the-middle?

Today, such systems often will buffer until a complete http response has
been received, then inspect, then forward to client. They also often fail
the request whenever response body size (or request body size for other
direction) exceeds some network admin defined limits.

How does WebSockets address this problem? Will it only work, when those
systems are fully WebSockets aware and friendly?

What would those intermediaries likely (want to) do? Buffer a WS frame,
inspect, forward? Buffer a complete WS message, inspect and forward?
Fail on frame/message too large?

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 6 Aug 2011 09:27:18 +0200

> direction) exceeds some network admin defined limits.

It depends. Some of them look at the beginning of contents and let
streams pass through (eg: video).

> systems are fully WebSockets aware and friendly?

WebSocket makes use of the HTTP Upgrade mechanism, by which an intermediary
will see HTTP/1.1 101 in the response, and will know how to act accordingly.
Quite frankly, a number of them will break at the beginning, for the very
same reasons that some proxies will break when they don't implement 101.
But since it's a standard HTTP mechanism, they will eventually get fixed
for that.

> Fail on frame/message too large?

Several failure modes are known to be possible :
  - ignore the status code and consider that 101 is equivalent to 2xx or 3xx
    and take it as a valid response. These ones will then try to analyse the
    contents and might do anything, such as wait for more data, wait for the
    close (now I remember why I wanted to advertise "content-length: 0" in
    the response), not recognize any wrong pattern and let everything pass
    through, or break the connection.

  - fail on the response because 101 is an unknown status code. They could
    possibly either break the connection or return a 5xx status code.

  - consider 101 as a 1xx status and wait for a second status code which will
    not come. Instead, WS frames will be considered as garbage where a second
    HTTP response is expected, and a 5xx status should  be returned

  - let the 101 pass but remove the Upgrade header. That way the client will
    immediately know it went through a non-compliant proxy and will break the
    connection.

My bet is that browsers will come with a configurable websocket proxy
and that admins will quickly open a new port on their proxies to bypass
the HTTP content analysis for WS. We should probably emit recommendations
on ways to safely distinguish WS from HTTP on a proxy so that the deployed
rules do not open ways to easily bypass URL or content filtering.

In parallel, bug reports will be emitted for broken intermediaries and
some of them will be fixed, other ones will wait for a new major version
to announce a shiny new WS feature. But I think it can happen very quickly
due to end user pressure.

Regards,
Willy