Re: [hybi] WebSocket, TLS and intermediaries

[Mike Belshe <[e-mail]>]

On Mon, Apr 19, 2010 at 7:47 AM, Vladimir Katardjiev <[e-mail]>wrote:

> 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.
>

For the SPDY data point - for low speed links, the header compression
matters.  For high speed links, it doesn't.  SPDYs gains mostly come from
other factors.  I wish I had the graphs handy, but I do not.


>
> 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.
>

Let me try to be objective about the tradeoff here:  When everything is
encrypted and authenticated at the endpoints, it prevents an intermediary
(who's motivations may be different than yours) from taking action.  When
data is not encrypted & authenticated, intermediaries, which have different
motivations (good or bad) are possible.

So the sad news is that for every good motivation, there is an equal and
opposite bad motivation as a counter argument...



>
> 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)
>

Actually, if you do that, the browser throws up a huge red box saying
"danger".  The MITM will not have a signing cert for a CA trusted by the
browser.  So, the cert will be signed by the ISP or other transparent
intermediary, which won't match the trusted CA list, and the browser will
complain.  Corporations can get around this by forcing a CA cert onto the
browser; but that is no longer a transparent intermediary - it was
specifically granted permission at the endpoint.  Of course, the user, not
knowing what the hell is going on, will click through anyway, think "that's
weird", and everything else will still work.

BTW - there is another data point here; deployment of WebSockets over port
80 was measured in Chrome to have ~67% success rate today.  Deployment over
port 443 (with TLS) has a >95% success rate.  So, if you don't use TLS, then
browsers and websites will need to be made more complex to deal with the
edge case of WebSockets failing in weird ways due to existing intermediaries
which fail, even after the WebSocket handshake.

Mike




>
> (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
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>