What does "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" means in WebSocket Protocol

Question

I don't understand the meaning of "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" in RFC 6455. Why does the server need this magic string? And why does the WebSocket protocol need this mechanism?

Rh

Answer 1

The RFC explains it. It is a GUID, selected because it is "unlikely to be used by network endpoints that do not understand the WebSocket Protocol". See RFC 6455.

If you're interested in the specifics of the format for GUIDs like that, see RFC 4122.

Metrics

Why does the WebSocket protocol need this mechanism? – Rh

@DavidSchwartz I think this is a Globally Unique Identifier used by server to verify whether the coming connection is websocket or not – Epigenesis

@DavidSchwartz: Except it does. 1.3 is the plainspoken summary of the mechanism and they are not normative. The technical, exhaustive description of the same mechanism in Section 4.2.2 is normative. The GUID appears under step 5, substep 4. – Sylviesylvite

Answer 2

From the Quora answer:

There is no reason for choosing the magic string. The particular magic string GUID was chosen to add some level of integrity to the WebSockets protocol, because the string is globally unique.

The RFC (RFC 6455 - The WebSocket Protocol) only says:

...concatenate this with the Globally Unique Identifier (GUID, [RFC4122]) "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" in string form, which is unlikely to be used by network endpoints that do not understand the WebSocket Protocol.

Hope that answers your question.

Gainey

Of course it's globally unique, except maybe this site's html, which just happen to include the same plaintext guid – Stereobate

Answer 3

Why does the WebSocket protocol need this mechanism?

---

1. A WebSocket connection is asked by a browser, simply with the code below

new WebSocket("wss://echo.websocket.org")

From the debugger we can see a 101 GET, and by inspecting the request header, we can see this particular entry:

Sec-WebSocket-Key: qcq+klmT4W41IrmG3/fseA==

This is a unique hash, identifying the browser.

---

2. On the server side the $client_key hash is received. Only the hash value is kept. The return value looks like this using PHP:

"Sec-WebSocket-Accept: " . base64_encode(sha1( $client_key . "258EAFA5-E914-47DA-95CA-C5AB0DC85B11",true))

3. The browser gets back the response, (example). This is the SHA1 of the sent key concatenated with the 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 WebSocket unique GUID.

Sec-WebSocket-Accept: r1Km05q03xuNRYy7mxkCRRgbh2M=

The browser then checks if the hash matches his own calculation, done under the hood. If so, the handshake is complete (the remote server is actually a real WebSocket server) and hence the tunnel has been created and kept alive.

---

https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers

Shoa

Why is it designed like this? What if the protocol doesn't concatenate the guid and just simply encode the client key? – Gardener

This is to make sure the server is a real websocket server. You have to ask the IETF tools.ietf.org/html/rfc6455 why they choose this particular key and process. Definitely not doable to remember quickly! The browsers are knowing this key, when it get the response back «Sec-WebSocket-Accept», it calculate the hash, since it knows the key he sent, and the guid. The «Sec-WebSocket-Accept» must match. – Shoa

This is to initiate the http 101 Switching protocol, or it won't work. The accept key + the guid in sha1, encoded in base64. This is universal. – Shoa

I guess this is just kind of salt i.e. to prevent revealing the original client_key by lookup on rainbow tables. – Rockbottom

Note: the echo.websocket.org service is no longer available – Windcheater

@Sergey What is the problem with revealing the client key? (If an attacker gets the server response, wouldn't they likely already have the client key, which was sent in the other direction on the same connection?) – Ioab