I am planning to implement the Websocket protocol and currently learning how handshake headers must be structured.
According to this link
http://datatracker.ietf.org/doc/rfc6455/?include_text=1
To prove that the handshake was received, the server has to take two
pieces of information and combine them to form a response. The first
piece of information comes from the |Sec-WebSocket-Key| header field
in the client handshake:Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
For this header field, the server has to take the value (as present
in the header field, e.g., the base64-encoded [RFC4648] version minus
any leading and trailing whitespace) and 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. A
SHA-1 hash (160 bits) [FIPS.180-3], base64-encoded (see Section 4 of
[RFC4648]), of this concatenation is then returned in the server’s
handshake.Concretely, if as in the example above, the |Sec-WebSocket-Key|
header field had the value “dGhlIHNhbXBsZSBub25jZQ==”, the server
would concatenate the string “258EAFA5-E914-47DA-95CA-C5AB0DC85B11”
to form the string “dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA-
C5AB0DC85B11”. The server would then take the SHA-1 hash of this,
giving the value 0xb3 0x7a 0x4f 0x2c 0xc0 0x62 0x4f 0x16 0x90 0xf6
0x46 0x06 0xcf 0x38 0x59 0x45 0xb2 0xbe 0xc4 0xea. This value is
then base64-encoded (see Section 4 of [RFC4648]), to give the value
“s3pPLMBiTxaQ9kYGzzhZRbK+xOo=”. This value would then be echoed in
the |Sec-WebSocket-Accept| header field.
So when I actually decode “s3pPLMBiTxaQ9kYGzzhZRbK+xOo=” in base64 decoder on decoder, it gives me
@:e^qlk
Which I do not think it is going to decrypted into original value using SHA-1 properly.
So far, my understanding is
1) Server received Sec-WebSocket-Key value from client and combine that with GUID generated from the server
So it becomes like:
dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA-C5AB0DC85B11
2) then server applies SHA-1 and base64 encoding onto it
and the key becomes:
s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
to send back to the clinet.
So in order to turn Websocket-accept value into the original “dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA-C5AB0DC85B11”, I need to decode the above value using Base64 and decrypt it with sha-1 and I must receive the original value back. However, when I actually attempt it, it gives me the weird value I have mentioned above. Could you please correct me which part I am doing wrong? Thank you.
You’re testing the base64_decode incorrectly. It decodes to a series of bytes which are not characters which can be viewed easily. But testing in PHP shows that decoding it with the code
$array = unpack("H*", base64_decode("s3pPLMBiTxaQ9kYGzzhZRbK+xOo="));
var_dump(str_split($array[1], 2));
gives the bytes.
0 => string 'b3' (length=2)
1 => string '7a' (length=2)
2 => string '4f' (length=2)
3 => string '2c' (length=2)
4 => string 'c0' (length=2)
5 => string '62' (length=2)
6 => string '4f' (length=2)
7 => string '16' (length=2)
8 => string '90' (length=2)
9 => string 'f6' (length=2)
10 => string '46' (length=2)
11 => string '06' (length=2)
12 => string 'cf' (length=2)
13 => string '38' (length=2)
14 => string '59' (length=2)
15 => string '45' (length=2)
16 => string 'b2' (length=2)
17 => string 'be' (length=2)
18 => string 'c4' (length=2)
19 => string 'ea' (length=2)
As mentioned in chat, you don’t need to ‘decode’ this anywhere, it’s just that your server is meant to be generating the correct value from the source values to send back to the client.
1