Websocket handshake

Hi,

  Use WEBSOCKET + Upgrade, let the handshake establish that the origin
server wants to speak Websocket. Change the framing so that each frame
has a random encryption key. The key in a client->server frame does not
depend on the key in a server->client frame and vice versa.

Let's assume an attacker controls the client. He cannot learn the key
the browser is going to use for the next frame so he does not have any
meaningful control over what the browser sends.

Let's assume an attacker controls the server. He can send whatever he
wants, for that to have any effect his server or an intermediary would
have to have a vulnerability that materializes only when random data is
received from the client. (They are already vulnerable today since you
can send random data going through the Socket interfaces in plugins;
and if that ever changes, which seems unlikely, it's hard to come up
with an example of a meaningful attack.)

Clients usually don't have much data to send, and when they do, heavy
processing is usually involved in generating it and sending it over the
wire, relative to doing a little bit of encryption. The same usually
goes for the server, it's either receiving little, or has to apply some
heavy processing relative to decryption.

If the server is generating the data, there is no cost involved since
the server can choose the key as it likes; if it has some static file
to send, it can send it out verbatim. If it forwards the data to other
clients (for instance, a video conferencing server might) it can use
the same key as the client, so again it's just forwarding it verbatim
(symmetry of the framing format and use cases like that are the only
reason to have server->client encryption).

This would be bad for applications that want to send very little data
frequently, bad for applications where servers do only minimal pro-
cessing of a lot of data they receive from clients, and bad for some
hardware optimizations (say, a camera that can put a verbatim stream
directly onto the network stack but cannot do any encryption). All of
which is a bit far-fetched as far as the general Websocket assumptions
go.

It's also bad for lazy client developers who might forgoe encryption
or use a fixed key, correctly or incorrectly assuming that's okay for
their environment.

However, it does play nicely with HTTP, does provably not add any new
security problems, and is efficient in the vast majority of cases.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Thursday, 16 December 2010 04:47:51 UTC