[Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)

[Konrad Rosenbaum]

On Sunday 26 January 2014, Kurt Pattyn wrote:
> On 17 Jan 2014, at 19:46, Frederik Gladhorn <frederik.gladhorn at digia.com> 
wrote:
> > Just another remark which I'm not sure about:
> > In section 5.2 of rfc 6455 randomness is mentioned. I didn't read up on
> > the background but currently there is only a call to initialize qsrand
> > with
> > 
> > QDateTime::currentMSecsSinceEpoch() which is probably not quite 
according to:
> >   The masking key needs to
> >   be unpredictable; thus, the masking key MUST be derived from a strong
> >   source of entropy, and the masking key for a given frame MUST NOT
> >   make it simple for a server/proxy to predict the masking key for a
> >   subsequent frame.  The unpredictability of the masking key is
> >   essential to prevent authors of malicious applications from selecting
> >   the bytes that appear on the wire.
> 
> Date and time are quite predictable :-)
> Creating random numbers with a high entropy is quite expensive (if not
> cached beforehand). This can be problematic, as a new mask has to be
> calculated for every frame.
> 
> What I do find strange though, is that the masking key is sent along
> unencrypted with the frame header and is thus readable by everyone (if
> not sent over secure websockets). The messages can thus be perfectly
> decoded, and as the server is not checking for the source, a malicious
> application can invent his own masking keys or intercept the message and
> repackage it (the server just takes whatever masking key that is in the
> header). I honestly don’t see how this mechanism can protect against
> malicious applications.
> 
> So, I wonder if it is worth the effort.

Depends. What is it used for? Is it just obfuscation or is it supposed to be 
real security?

If the latter: is it the only way to generate security? (If so: in all 
likelyhood you are affixed by an inclined plane wrapped helicly around an 
axis. In laymans terms: screwed.)

If the former: unless it is absolutely necessary for understanding the other 
side of the communication channel - don't bother implementing it. Obscurity 
is no security.

> > I'd like others with more experience in this area to chime in though.

Getting milliseconds since Epoch gives you less than one bit of random 
(entropy), if and only if nobody can predict precisely when you'll call for 
the current time. Calling it several times does not increase entropy unless 
there are sufficiently random intervals between calls and nobody can observe 
you calling (i.e. you are working on a perfectly secured system). Micro- and 
Nano-Seconds are slightly more random, but not much (fractions of bits).

You need about 128 bits of entropy for good security. After you've got that 
you can stretch those with a secure random number generator. The q(s)rand 
functions can be safely assumed to be completely insecure on most operating 
systems and inadequate on all the others. Don't use them for security.

I would not recommend trying to implement your own PRNG either - getting it 
right is horribly difficult. Getting the entropy gathering right in a cross-
platform way is much worse effort...

I wonder whether it would be possible to expose the low-level APIs of 
OpenSSL to Qt, it has quite a good random number generator and it is used 
for QSslSocket already.



	Konrad