This resolves a medium vulnerability described in the
Beast Hybrid Assessment Report by Bishop Fox, where masks generated
for use with outgoing WebSocket client frames use an insufficient
source of entropy and a non-cryptographically secure pseudo-random
number generator.
By default, all newly constructed WebSocket streams will use a
uniquely seeded secure PRNG (ChaCha20 in counter mode). As this may
result in increased CPU resource consumption, the function
websocket::stream::secure_prng() may be used to select a faster but
less secure PRNG, for the case where the caller knows that the secure
generator is not necessary.
On some systems, std::random_device may produce insufficient entropy
to securely seed the PRNG. As this condition cannot be detected by
Beast, callers may use the function websocket::seed_prng() called
once at startup to provide at least 256 bits of entropy which will
be used to uniquely seed all subsequent PRNGs.
fix#849
This adds an additional `bool` template parameter to
`websocket::stream`:
* When deflateSupported is `true`, the stream will be capable
of negotiating the permessage-deflate websocket extension per
the configured run-time settings.
* When deflateSupported is `false`, the stream will never negotiate
the permessage-deflate websocket extension. Furthermore, all of the
code necessary for implementing the permessage-deflate extension
will be excluded from function instantiations. The resulting emitted
object code should be smaller.
fix#769
The following classes are removed:
* handler_type
* async_result
* async_completion
* is_dynamic_buffer
* is_const_buffer_sequence
* is_mutable_buffer_sequence
* handler_alloc
Actions Required:
* Use BOOST_ASIO_HANDLER_TYPE instead of handler_type
* Use BOOST_ASIO_INITFN_RESULT_TYPE instead of async_result
* Use boost::asio::async_completion
* Use boost::asio::is_dynamic_buffer
* Use boost::asio::is_const_buffer_sequence
* Use boost::asio::is_mutable_buffer_sequence
* boost::asio::associated_allocator_t replaces handler_alloc
* stream overloads of accept which take both a message
and a buffer sequence are removed.
Actions Required:
* Do not call websocket accept overloads which take
both a message and a buffer sequence, as it is
illegal per rfc6455.
fix#642
* Calls to stream::close and stream::async_close will
automatically perform the required read operations
Actions Required:
* Remove calling code which drains the connection after
calling stream::close or stream::async_close
Vinnie Falco