Re: [hybi] Insight you need to know: Browsers are at fault when servers crash

[Adam Barth <[e-mail]>]

On Mon, Jul 26, 2010 at 7:15 AM, Maciej Stachowiak <[e-mail]> wrote:
> On Jul 25, 2010, at 10:12 PM, John Tamplin wrote:
> On Mon, Jul 26, 2010 at 1:03 AM, Maciej Stachowiak <[e-mail]> wrote:
>> I think the idea here would be to use encryption solely to prevent the
>> attacker from predicting either input or output bytes - in effect to
>> scramble the bits, rather than to provide confidentiality.
>
> Ineffective encryption doesn't really pose a barrier to producing plain text
> to produce a desired cipher text.  Maybe if the key can't be controlled by
> the attacker and varies on each packet, but it still seems like you are
> playing with fire to say you don't have to use a secure encryption method to
> prevent this.
>
> Let's see the details of Adam's idea before we discuss further.

Sorry, I'm slightly distracted at the IETF meeting in Maastricht at
the moment.  Here's the main idea.

Mike wanted to know if there was any way to avoid the round-trip in
the current handshake (I think he views round-trips as quite
expensive).  That leaves us with the following requirements:

1) Zero round trips.
2) We can't send attacker-controlled bytes to the server before the
server proves it understands web sockets.

So how can we start sending content before hearing back from the
server?  The idea is to encrypt the bytes using a key that a WebSocket
server can derive but that look uniformly at random to a non-WebSocket
server.  The easiest way to do this is for the client to send the
server a nonce and then for the client and server to hash that nonce
with a GUID that identifies the WebSocket protocol to generate an
encryption key.  You can then encrypt the attacker's content using
that key (e.g., using AES, RC4, or whatever you like).

Now, I should say this give slightly weaker security properties than a
handshake that waits for the server to opt-in.  For example, if the
server falls over (or generates print jobs) when it receives random
bytes, then we'll still get in trouble, but limiting the attacker to
random bytes reduce the attack surface significantly.  It's probably
also a good idea to limit how much data we're willing to send before
hearing back from the server, but this idea allows some flexibility
beyond zero.

There isn't really any dependency between the format of the handshake
and this trick for saving the round-trip.  You can build the entire
handshake using this idea so that the server only receives
random-looking bytes, but, as Maciej mentions, that makes it difficult
to share with an HTTP server.  You can also this this idea at the end
of an HTTP-like handshake to get started sending data without waiting
for the server to reply.

Adam