CVE: Insecure generation of mask keys for websocket clients

[vinniefalco]

std::random_device is not guaranteed to be non-deterministic. And std::minstd_rand is weak. One solution is to invoke random_device for every key generation. Another solution is to use a more secure PRNG such as one based on RC4 or ChaCha20. Or a combination of these solutions.

It should also be possible for the user to either seed a secure PRNG through a new API, or to set a custom key generation function.

[pdimov]

Reference for std::random_device not being non-deterministic: https://stackoverflow.com/questions/18880654/why-do-i-get-the-same-sequence-for-every-run-with-stdrandom-device-with-mingw

Orson Peters's optimized ChaCha RNG: https://gist.github.com/orlp/32f5d1b631ab092608b1

random_provider, an implementation detail of Uuid: boostorg/uuid#53

[djarek]

I believe that the RNG should be a customization point (with a sensible default).

[vinniefalco]

Any solution needs to be header-only. Peter is against cryptographic customization points, preferring "secure by default."

[pdimov]

I don't mind a customization point here because the RNG could in principle visibly affect throughput.

[jeking3]

I'm working on moving Boost.Uuid's random_provider into Boost.Random as a replacement for the guts of random_device, however it will be subject to approval by the maintainer. I believe this will give you the optimal entropy generator provided by the operating system in as many cases as possible, and we can add more platform support if needed. This will support Windows UWP Desktop and non-desktop platforms, OpenBSD and CloudABI, and POSIX systems, it is also optimized on linux with glibc-2.25 or later to use the getentropy() call. It is also header-only.

[vinniefalco]

@pdimov The client is responsible for masking frames, not the server. So presumably they only have one connection.

[vinniefalco]

This has been resolved now for a few months. By default, the implementation uses a secure PRNG based on ChaCha, seeded from std::random_device. There are two configurable options here:

1. The user may manually set a new seed. This is for when you don't trust random_device, or if you have a better platform-specific source.
2. The user may opt-in to a faster, non-cryptographically secure generator.

If desired, these options must be set before any streams are constructed. I feel that this is now resolved. Any problems which come up should have new issue opened - thanks!