[hybi] WebSocket, TLS and intermediaries

[Vladimir Katardjiev <[e-mail]>]

On 16 apr 2010, at 22.13, Ian Hickson wrote:
> On Fri, 16 Apr 2010, Greg Wilkins wrote:
>> 
>> The whole point of having a standard like websocket, is so that the 
>> network infrastructure can implement the RFC and then we have known 
>> semantics over that connection that intermediaries can at least handle 
>> correctly, but may also do clever stuff with.
> 
> That wasn't even on my list of reasons for originally coming up with 
> TCPConnection, let alone the main reason.

> 
> The main reason for the Web Socket protocol is to have one protocol that 
> the browsers can all implement in an interoperable fashion so that servers 
> can implement things once and have them work with all browsers. In the 
> ideal deployment the connection is wrapped in end-to-end TLS, so the 
> intermediaries can't do anything with it. There were only two reasons for 
> even allowing unencrypted Web Socket originally: requiring amateurs to 
> figure out TLS seemed like too high a bar, and there is still some concern 
> that when the connection is being used for entirely public information, 
> the TLS connection overhead is too expensive to justify.

Fair enough, it wasn't originally. But wouldn't it be better if it did? Let's take a couple of hypothetical scenarios where an amateur programmer can _transparently_ gain additional, desirable functionality by an intermediary "messing" with a well-defined protocol.

1. Compression
For all the talk about transferring 5gb using WebSockets, the FCC still maintains a fairly conservative definition of "broadband" at 768kbps. I believe the US average broadband speed was a handy contribution to the speed savings that SPDY's compression of data made possible. In other words, it's not unlikely that a future iteration of WebSockets adds compression (let's say gzip) to the equation.

Obviously, for this to work it needs to be optional, because otherwise we raise the barrier of entry. But in some deployments it is a desirable thing for the ISP to add. An ISP might want to compress the traffic to lower the load on their edge network (or their 768kbps broadband customers) In the case of a mobile network, the shorter time the radio is kept alive, the more battery savings, so it's highly desirable to compress WebSocket connections if appropriate.

2. Optimisation
Suppose we had a way of determining that a client cannot receive messages larger than 1mb, due to memory restrictions. (Feel free to substitute it with 5gb for the 2020 scenario). Wouldn't it be a waste of time to send all that data to the remote client only for it to discover that state on its own? For a mobile client, if the behaviour on too large frames is well-defined, we may even handle it without waking the client up (or close the connection if that's the defined behaviour) potentially saving a lot of bandwidth and battery.

3. Error checking
A properly written intermediary is also expertly written. So it would be able to prevent protocol exploits that may appear. In addition, these types of intermediaries would be maintained for the purpose of security and thus updated faster than you could hypothetically update client(s) and server(s). While it doesn't eliminate the spread of exploits and malware, it can reduce it. If we are supposed to be as concerned as we are about security, we should also cover the possibility that there may be a security hole in the future (one that we couldn't consider now) and make sure it can be protected. An intermediary can be a part of such a solution, but that also implies we must have intermediaries that can talk WebSockets.

4. Deployment
This falls into the category of "making the protocol actually work", but I do count it as a benefit to the amateur programmer because, yeah, I don't quite think TLS is so trivial to implement either. I don't remember where the original reference is, but I don't think creating a protocol whose design goal is to be wrapped end to end in TLS to simulate having open network access is going to work.

For one, you can't guarantee having no intermediaries with TLS (for the amateur programmer). All you need to do to MITM a TLS connection is, well, an intermediary box (I'd wager most ISPs can arrange one of those) and a signed certificate (shouldn't be an issue either). Since the WebSocket connection is user transparent they won't notice that the certificate no longer says Bank.com but ISP.com. Or Corporation.com for that matter. (I won't discuss ethics/morality/legality, just technology)

(course, this won't work if the TLS box shares https and wss traffic, but then we're not dealing with the amateur programmer are we?)

I don't think working on bypassing intermediaries for all traffic is a productive avenue. Rather, I think it'd just lead to a pointless arms race. It was my impression that what this wg was out to make was a protocol that played "nice" with both nonexistent, current and future intermediaries.

Don't get me wrong, the actual data passed through the WebSocket connection should be (possible to be?) opaque to any intermediaries, but the fact that it is a message, or a keepalive, or a graceful close, should be information available for intermediaries. 

Vladimir