Websocket-Extension: NoXORMask IETF RFC Proposal Draft

Websocket is a robust, general, widely accepted and adopted communication protocol described in RFC 6455 (https://tools.ietf.org/html/rfc6455)

The communication starts as a standard http or https request and then upgraded to persistent TCP connection of general use.

In our experience and in comments on Internet, we detected one weakness and  critics which restrict wider adoption of the protocol on Internal Networks: The mandatory masking of the frames sent from client to server, as explained in Section 5.3. of the RFC, titled Client-to-Server Masking.

Every frame sent from client to server needs to carry additional 4 bytes on the header. Frame payload must be "XOR"ed with this 4 bytes prior being sent to server. And server must repeat this process as described in RFC Section 5.3.

XOR Masking is developed for security reasons for communications on Internet over proxies. It may be acceptable on public Internet. But there is no logical reason to force XOR masking which implies extra data overhead and extra CPU power on "trusted" networks, where, there is no proxy usage.

There is no mechanism to disable masking on RFC 6455.
From server to client communication without mask is allowed.
But, unfortunately, RFC 6455 forbids communications without mask bit set, from client to server by explicitly stating in Section 5.2 at page 28: "... Mask: 1 bit: ... All frames sent from client to server have this bit set to 1 ...".

We propose adding a new extension to completely disable masking, both from server to client and from client to server :

During negotiation, client sends an extra http header, as described in RFC 6455 Section 9.1:

Sec-WebSocket-Extensions: NoXorMask

When server receives this extension request, it will check whether it must allow it or not.
We don't want to violate the original spirit of RFC 6455. We share its security concerns.
That's why, at this point, server has a choice to allow it or not.
For example, in our internal application servers, we have a flag to indicate on which ports NoXorMask extension will be allowed. And we set this flag only for ports listening to our intranet behind firewall.

If server accepts NoXORMask extension, it sends back the same header on handshaking response:

Sec-WebSocket-Extensions: NoXorMask

And then, the rest of the websocket communication will continue without setting "frame-masked" bit of frame header, in both directions.

But if, server decides to not to allow communication without mask from client to server, it simply ignores Sec-WebSocket-Extensions: NoXorMask header and websocket communication will continue exactly as described in RFC 6455.




Note:
We implemented this extension in our in-house web server and it runs successfully. 
But this is still a draft. 
We haven't sent it yet to IETF. 
Comments, suggestions and English language corrections 
and especially IETF style corrections are wellcome.

Ismail Kizir

Yorumlar

Bu blogdaki popüler yayınlar

Ben utanaydım, ama, bunlar gerçekleşmeyeydi

Visual proofs of Hohha Dynamic XOR Encryption Algorithm