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#1113
This solves a problem where the message-oriented synchronous
HTTP write algorithms do not support messages whose body
writer requires a non-const reference to the message in
order to construct.
In addition, the message-oriented async_write algorithm is
modified to support messages passed by const reference when
possible, based on the body writer attributes.
The ssl_stream wrapper provides C++11 move semantics for ssl::stream,
as well as incorporating the flat_stream workaround for a performance
problem with ssl::stream writes and buffer sequences having length
greater than one.
fix#1108
The `flat_stream` is a stream wrapper designed to overcome a
performance limitation of the `boost::asio::ssl::stream`
implementation. Specifically, when writing buffer sequences having
length greater than one, the `ssl::stream` implementation does
not use scatter-gather I/O and instead performs a kernel transition
for every buffer in the sequence.
The wrapper addresses this problem by allocating memory and
presenting the buffer sequence into a single buffer, using
some logic to determine when this allocation is advantageous
versus simply passing the buffers through as-is.
See Also:
https://github.com/boostorg/asio/issues/100https://stackoverflow.com/questions/50026167/performance-drop-on-port-from-beast-1-0-0-b66-to-boost-1-67-0-beast
Vinnie Falco
Pierre Zawadil
cos-public
Benjamin Buch
Damian Jarek
Arvid Norberg