Subject: [hybi] why did rfc6455 choose the 16-byte sec_websocket_key

From: juan li <[email-masked]>
Date: Sun, 19 Feb 2012 17:38:08 +0800

Hi,

       Why does rfc6455 choose the 16-byte sec_websocket_key?  When
encoded, it occupies 24 bytes. The sec_websocket_accept occupies 28 bytes.
They are so long.
Why not choose a shorter key?

Thanks for your reply.

---

From: John Tamplin <[email-masked]>
Date: Sun, 19 Feb 2012 20:33:43 -0500

> Why not choose a shorter key?

A shorter key has security implications, and since this happens once per
handshake the cost is negligible.

-- 
John A. Tamplin
Software Engineer (GWT), Google

---

From: Juan Li <[email-masked]>
Date: Mon, 27 Feb 2012 22:38:56 +0800

What kind of security implications? eg., how do that kind of security
problems happen?

Thanks,
juanzi.

2012/2/20 John Tamplin <[email-masked]>

---

From: John Tamplin <[email-masked]>
Date: Mon, 27 Feb 2012 10:04:37 -0500

> What kind of security implications? eg., how do that kind of security

The probability of guessing the key is inversely proportional to the number
of possible keys.

The primary point is to make sure that the server actually speaks the
WebSocket protocol, so the security implication would be allowing an
attacker to use a WebSocket client (which will run in every browser and be
able to connect to any server, since it is not subject to same-origin
policy) to attack a non-WebSocket server if he can somehow trick the client
into thinking it is a WebSocket server.  A smaller key would increase the
probability of generating a collision in the Sec-WebSocket-Accept, which
means a server that can be made to echo back attacker-controlled values but
which does not implement the WebSocket handshake could be made to pass the
handshake anyway.

Again, this happens once per connection, so the size isn't a significant
concern.