[Cryptography] RFC for a websocket extension concerning also security
ikizir at gmail.com
Mon Nov 21 02:04:53 EST 2016
I don't know if this may be considered as off-topic.
But it concern a security issue.
So, I wanted to write here before submitting in order to
collaboratively discuss the subject.
We, all have custom protocols for our in-house applications and
servers. So I have.
But I also like standards. Websocket protocol is easily extendible.
WebSockets, described in RFC 6455
(https://tools.ietf.org/html/rfc6455#page-32), is a robust, extensible
and widely accepted standard.
So, I converted all my existing protocol to work on top of websocket
protocol, as extensions.
But I noticed some unnecessary performance and data overhead with 4
bytes XOR masking value:
Section 5.2 defines the XOR masking and Section 5.3 mandates use of
XOR masking from client to server.
I don't want to discuss here, the reasons for XOR masking from client
to server. They say, with some older proxies or with some malicious
intermediaries, it is possible to realize some attacks.
But, usually, such protocols work on Intranets, not Internet. For
example, all my BigTable server impelentation communication is on my
private Internet. I am sure of it when I connect it. It is my own
private intranet and I know absolutely there is not any kind of proxy
I am sure many other developers will think the same: Why paying the
cost of extra 4 bytes data overhead and extra cpu cycles to
So, I created a new websocket extension:
On handshake, I sent one extra header from client to server:
And server checks the connection and decides what to do: If it is an
internet ip(which, in my case is impossible, since intranet is
protected by a firewall), it accepts the offer sends back:
Then, the communication continues without mask bits set. No
unnecessary XOR mask data overhead and no wasted CPU cycles.
I want to submit this is an RFC proposal.
But the main RFC document 6455 mandates the use of XOR masking in Section 5.3.
I haven't a previous experience in writing RFC submissions.
Such a contradiction with main standart may be allowed in extensions
written for that RFC?
Is it a good idea to submit this extension as an RFC?
May there be any security holes that I couldn't realize?
Any comment, help, suggestion, English grammar/sentence
corrections/reorganisations are wellcome :)
More information about the cryptography