Triple DES, and other 64-bit block-size ciphers vulnerable
to "Sweet32" birthday attack (CVE-2016-6329). Limit such
cipher keys to no more than 64 MB of data
encrypted/decrypted. While our overall goal is to limit
data-limited keys to 64 MB, we trigger a renegotiation
at 48 MB to compensate for possible delays in renegotiation
and rollover to the new key.
This client-side implementation extends data limit
protection to the entire session, even when the server
doesn't implement data limits.
This capability is advertised to servers via the a
peer info setting:
IV_BS64DL=1
meaning "Block-Size 64-bit Data Limit". The "1" indicates
the implementation version.
The implementation currently has some limitations:
* Keys are renegotiated at a maximum rate of once per
5 seconds to reduce the likelihood of loss of
synchronization between peers.
* The maximum renegotiation rate may be further extended
if the peer delays rollover from the old to new key
after renegotiation.
Added N_KEY_LIMIT_RENEG stats counter to count the number
of data-limit-triggered renegotiations.
Added new stats counter KEY_STATE_ERROR which roughly
corresponds to the OpenVPN 2.x error "TLS Error:
local/remote TLS keys are out of sync".
Prevously, the TLS ack/retransmit timeout was hardcoded to
2 seconds. Now we lower the default to 1 second and make
it variable using the (pushable) "tls-timeout" directive.
Additionally, the tls-timeout directive can be specified
in milliseconds instead of seconds by using the
"tls-timeout-ms" form of the directive.
Made the "become primary" time duration configurable via
the (pushable) "become-primary" directive which accepts
a number-of-seconds parameter. become-primary indicates
the time delay between renegotiation and rollover to the
new key for encryption/transmission. become-primary
defaults to the handshake-window which in turn defaults
to 60 seconds.
Incremented core version to 3.0.20.
INFO,<payload>
Payload can be any UTF-8 printable string under 64 KB
(multiple lines are okay).
INFO notifications can be sent from server to client
in real-time, on any active client connection.
The client will attach the payload to an INFO event and
forward it to the controlling app via the event callback:
virtual void event(const Event&) = 0;
receive path to reassemble messages fragmented by the
SSL layer up to a max message size of 64 KB.
Ramifications:
* Peer info data and pushed options can be significantly
larger (i.e. approaching 64 KB).
* Less need for the options continuation feature.
Limitations:
* While this patch doesn't change the underlying OpenVPN
protocol, it can result in messages being sent that are
fragmented by the receiving SSL implementation into
multiple buffers. Implementations that lack reassembly
capabilities (such as OpenVPN 2.x at this point in time)
would see each buffer fragment as a separate message.
* This patch running on the server will break negotiation
with pre-peer-info clients. Basically this means it will
interoperate with any OpenVPN 3 version or OpenVPN 2.x
version that includes the June 2010 commit "Implemented a
key/value auth channel from client to server.
Version 2.1.1i".
* eliminated the GENERAL_POOL enumeration and vector.
* added support for standalone "ifconfig-push" directive
as alternative to "server" for OMI agents that
manage their own IP address pools.
In ServerProto::Session (servproto.hpp),
push_halt_restart_msg() can now push AUTH_FAILED messages
as well.
In fact ServerProto::Session::auth_failed() is now defined
in terms of push_halt_restart_msg().
When parsing listen directives, "ssl" or "!ssl" may
be specified as the last parameter to set the ssl
switch. By default, the switch is set to unspecified.
to be multiplied by the number of processor cores on the machine
using this syntax:
listen 0.0.0.0 1194 udp 4*N
The 4*N syntax indicates that OpenVPN should spawn 4 * N threads
to listen on 0.0.0.0:1194 where N is the number of processor
cores on the machine.
