63

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?

Community
  • 1
  • 1
Hakju Oh
  • 731
  • 1
  • 5
  • 5

3 Answers3

33

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.

Community
  • 1
  • 1
David Schwartz
  • 179,497
  • 17
  • 214
  • 278
  • 8
    Why does the WebSocket protocol need this mechanism? – Hakju Oh Nov 20 '12 at 07:20
  • @DavidSchwartz I think this is a Globally Unique Identifier used by server to verify whether the coming connection is websocket or not – C graphics Sep 23 '13 at 21:59
  • 1
    @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. – Jesper Oct 14 '13 at 11:01
8

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.

Community
  • 1
  • 1
chaudharyp
  • 3,394
  • 3
  • 26
  • 42
  • 2
    Of course it's globally unique, except maybe this site's html, which just happen to include the same plaintext guid – Rekin Jun 01 '22 at 15:34
4

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.

enter image description here

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

  1. The browser get 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=

enter image description here

The browser is then checking if the hash match his own calculation, done under the hood. If so, the handshake completed, the remote server is actually a real websocket server, and hence the tunnel is created, and kept alive.

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

NVRM
  • 11,480
  • 1
  • 88
  • 87
  • 2
    Why is it designed like this? What if the protocol doesn't concatenate the guid and just simply encode the client key? – K.Miao Jul 22 '20 at 07:08
  • This is to make sure the server is a real websocket server. You have to ask the IETF https://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. – NVRM Jul 22 '20 at 13:11
  • 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. – NVRM Jul 25 '20 at 17:56
  • I guess this is just kind of salt i.e. to prevent revealing the original client_key by lookup on rainbow tables. – Sergey Ponomarev Dec 27 '20 at 10:32
  • Note: the echo.websocket.org service is no longer available – perrocallcenter Jul 31 '23 at 00:58