Major_Sauce
Major_Sauce

Reputation: 11

Where to locate the mask bit in a WebSocket frame?

I´m currently trying to create a WebSocket server in Java and I got some issues with it. Currently I got the handshake running (at least I don´t get any errors on any side). Then I started with the frames and I´ve got the following things done:

The next step would be the masking bit which should be located at the 8th bit (which should be bit 1 in the second byte of the frame) The RFC 6455 specification (see here) tells me that this bit should be set or "1" if sent from a client, I´m using Firefox to connect so this is definately a client, but it´s not set to 1. Here´s what I get as bit-input:

Byte 1: 10000001
Byte 2: 00100001
Byte 3: 11101101
Byte 4: 01000101
Byte 5: 01010001
Byte 6: 00110101
Byte 7: 11100111
Byte 8: 11010011
Byte 9: 00100111

As you can see at byte 2 bit 0 there´s a 0 which indicates that the frame is not masked. Can someone tell me if I´m looking at the correct place for the Mask indication and if so, does someone have an idea why the mask isn´t set ? Anyways, I guess the packet itself is valid since the first bits are always 10000001 which is an indication of a healthy final frame Text packet.

Also, just to confirm, next steps would be to look for bit 1-7, it this one is smaller than 126, this is my frame length in bytes. If it´s 126, those 7 bits plus the next 16 bits indicate the length, if it´s 127 then the 7 bits plus next 64 indicate the lenght. The next is the mask key which is 32 bits (4 bytes) and everything from there is the payload. I got to run a xor over the payload using the masking-key to decrypt. Right ?

Also, I currently just read the first two bytes of the frame, check everything and maybe even get the size. If I got the size I should be able to read the whole packet, right ?

Edit: Thank you guys, I found the "issue". I haven´t yet worked directly on bit level so I didn´t really know that bit numbering works from right to left (at least if it´s LSB) which caused some irritation. Since the first byte looks perfectly symetrical there was a bit set in the biginning and at the end so the final-check and the check for the optcode worked. So if someone has similar problems, try to check if you´re really reading the right bits and you may want to check this page;

Best regards, Major

Upvotes: 0

Views: 647

Answers (1)

Myst
Myst

Reputation: 19221

As indicated in the WebSocket Protocol RFC, the masking indicator bit is bit #8 on the 2nd byte.

i.e. (in C, since I'm not sure about writing this in Java):

// assuming `msg` is `unsigned char` (byte string)
if ((msg[2] & 128)) // ... masked

Upvotes: 0

Related Questions