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

Richard Moore rich at kde.org
Wed Feb 12 16:51:25 CET 2014


On 12 February 2014 14:44, Konrad Rosenbaum <konrad at silmor.de> wrote:
> On Wednesday, Wednesday 12 February 2014 at 08:01, Kurt Pattyn wrote:
>> On 11 Feb 2014, at 19:14, Thiago Macieira <thiago.macieira at intel.com> wrote:
>> > Em ter 11 fev 2014, às 16:26:44, Tony Van Eerd escreveu:
>> >> http://channel9.msdn.com/Events/GoingNative/2013/rand-Considered-Harmful
>> >
>> > No doubt. And we should have a more secure generator, at least until we
>> > can rely on std::random.
>>
>> We can always 'duplicate' some code from the std::random library :-)
>> How 'secure' should this be? Is a Mersenne-Twister for instance 'secure'
>> enough?
>
> Secure enough for a simple Monte-Carlo style simulation? Yes, definitely,
> that's what it was designed for.
>
> Secure enough for the initial WebSocket implementation in Qt 5.3? Well, not
> really, but let's go with it (qrand) and fix it in 5.4.

It's really fine for this use-case as I said in my earlier email. Qt
does not provide any form of sandbox - all code that can use the
websockets classes is either 1) trusted or 2) must be secured by a
sandbox provided by the application. Given this, the only purpose of
the masking in Qt is to prevent accidental problems due to triggering
the class of problems that lead to request smuggling flaws in proxies.
Making the mask change is really only necessary so that you won't get
a consistent failure (since the second time the mask will be
different). This is a completely different environment to use the use
of websockets in a browser where untrusted code is being run and could
potentially exploit request smuggling to by-pass SOP, which is why
they need secure random numbers and we do not.

It would be nice to have a secure random number source in Qt, but
that's a completely different question.

Regards

Rich.



More information about the Development mailing list