Subject: Re: [hybi] Experiment comparing Upgrade and CONNECT

From: Michael Platov <[email-masked]>
Date: Tue, 30 Nov 2010 15:40:51 +0300

> On 27.11.2010 00:48, Adam Barth wrote:
>> David Huang, Eric Chen, Eric Rescorla, Collin Jackson, and I have been
>> experimenting with the security of the Upgrade-based and CONNECT-based
>> WebSocket handshakes.  Please find a paper detailing our findings at
>> this location:
>> 
>> http://www.adambarth.com/experimental/websocket.pdf
>> ...
> 
> Very interesting stuff.
> 
> How about:
> 
> 1) Installing a permanent test service which would allow people to check 
> whether they have broken intermediaries in the path, and then

We did just that two month ago to troubleshot the problems our users were having with WebSocket-enabled browsers. We've being using websockets  (as an additional option, when they are available in a browser and work for the end user) and to help troubleshooting various problems we created a test service:
http://websocketstest.com/

The test consists of connecting to a websocket-enabled server and sending some data back and forth. Same procedure is repeated for 3 different ports. A client is considered to have a working websocket connection if data exchange succeed at least for one of the websocket ports. For comparison, similar test is also run using Comet as a transport.

Quick summary after running the test for 2 month (more than 4000 browsers tested):
WebSocket browser support: 30%
WebSocket success rate: 72%

More detailed information on the experiment can be found here:
http://websocketstest.com/ws/stats

Our experience so far showed that there are two biggest obstacles for Websockets in the wild:
1. Proxy servers (or other intermediaries). We're trying to detect proxies by HTTP headers, but it seems that many proxies don't set them. Judging by ones who set them (~4% of all failed connections), we can say that some of the incompatible proxies include various version of Squid and Microsoft ISA Server (there are others, but it's hard to identify them by their headers). We also have seen some problems with squid in transparent proxying setup.

2. Antivirus software installed on the PCs of the end users. We found that some antiviruses are blocking websocket connections. For some of the them, adding a simple exception helps to resolve the issue. Most of the users aren't going or not able to update their antivirus rules anyway, so hopefully antivirus vendors will address this issue once the usage of the websockets increases.

> 
> 2) Re-run the experiment again at a later point.
> 

We'll probably do that once the new version of the protocol we'll be supported by the browsers of our end users.

> Also:
> 
> 3) Stop shipping implementations of the so-called "76" protocol; we 
> know, that the current version performs better because of the framing, 
> right?

Even in its present form, websockets are useful as a backup option to workaround rare issue with Comet that are present in some environments. However, a version of a WebScoket protocol with better compatibility with existing HTTP-infrastructure (e.g. more HTTP-compatible handshake that works with already deployed HTTP proxies) is very anticipated.

> Best regards, Julian

Best regards,
Michael

---

From: Joe Mason <[email-masked]>
Date: Tue, 30 Nov 2010 15:04:58 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Platov
> Sent: Tuesday, November 30, 2010 7:41 AM
> To: [email-masked]
> Subject: Re: [hybi] Experiment comparing Upgrade and CONNECT
>
> We did just that two month ago to troubleshot the problems our users were having with WebSocket-enabled
> browsers. We've being using websockets  (as an additional option, when they are available in a browser and 
> work for the end user) and to help troubleshooting various problems we created a test service:
> The test consists of connecting to a websocket-enabled server and sending some data back and forth. Same 
> procedure is repeated for 3 different ports. A client is considered to have a working websocket connection 
> if data exchange succeed at least for one of the websocket ports. For comparison, similar test is also run 
> using Comet as a transport.
>

This suggests a 28% failure rate, partly due to Upgrade.

Adam's paper (page 8) says: "[Out of 54,543 attempts with the Upgrade-based handshake] 7,196 (13.2%) failed. The handshake failed more often than the POST-based handshake, possibly when the Upgrade mechanism was unsupported and, perhaps, stripped."  This gives the impression that the Upgrade based handshake is the most fragile of the 3 (the strawman POST handshake failed "5,316 (9.4%)" of the time.)  But with the Connect-based handshake, "7,328 (13.4%) failed".  I've heard a lot of assertions that Connect will succeed more often than Upgrade, but there's no difference in this test.  Do we have any actual evidence that's true?

Joe

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Adam Barth <[email-masked]>
Date: Tue, 30 Nov 2010 12:56:34 -0800

> Adam's paper (page 8) says: "[Out of 54,543 attempts with the Upgrade-based handshake] 7,196 (13.2%) failed. The handshake failed more often than the POST-based handshake, possibly when the Upgrade…

The evidence I've seen is that the success rates are similar.

Adam