2018-10-08 06:30:34 +08:00
|
|
|
Overview of changes in 2.5
|
|
|
|
|
==========================
|
|
|
|
|
|
|
|
|
|
New features
|
|
|
|
|
------------
|
2018-10-22 19:45:15 +08:00
|
|
|
Client-specific tls-crypt keys (``--tls-crypt-v2``)
|
|
|
|
|
``tls-crypt-v2`` adds the ability to supply each client with a unique
|
|
|
|
|
tls-crypt key. This allows large organisations and VPN providers to profit
|
|
|
|
|
from the same DoS and TLS stack protection that small deployments can
|
|
|
|
|
already achieve using ``tls-auth`` or ``tls-crypt``.
|
|
|
|
|
|
2018-10-08 06:30:34 +08:00
|
|
|
ChaCha20-Poly1305 cipher support
|
|
|
|
|
Added support for using the ChaCha20-Poly1305 cipher in the OpenVPN data
|
|
|
|
|
channel.
|
|
|
|
|
|
2020-07-09 18:15:56 +08:00
|
|
|
Improved Data channel cipher negotiation
|
|
|
|
|
OpenVPN clients will now signal all supported ciphers from the
|
|
|
|
|
``ncp-ciphers`` option to the server via ``IV_CIPHERS``. OpenVPN
|
|
|
|
|
servers will select the first common cipher from the ``ncp-ciphers``
|
|
|
|
|
list instead of blindly pushing the first cipher of the list. This
|
|
|
|
|
allows to use a configuration like
|
|
|
|
|
``ncp-ciphers ChaCha20-Poly1305:AES-256-GCM`` on the server that
|
|
|
|
|
prefers ChaCha20-Poly1305 but uses it only if the client supports it.
|
|
|
|
|
|
|
|
|
|
Deprecated features
|
|
|
|
|
-------------------
|
|
|
|
|
For an up-to-date list of all deprecated options, see this wiki page:
|
|
|
|
|
https://community.openvpn.net/openvpn/wiki/DeprecatedOptions
|
|
|
|
|
|
|
|
|
|
- ``ncp-disable`` has been deprecated
|
|
|
|
|
With the improved and matured data channel cipher negotiation, the use
|
|
|
|
|
of ``ncp-disable`` should not be necessary anymore.
|
|
|
|
|
|
2018-10-08 06:30:34 +08:00
|
|
|
|
2017-03-05 02:49:57 +08:00
|
|
|
Overview of changes in 2.4
|
|
|
|
|
==========================
|
2015-10-15 22:44:58 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
New features
|
|
|
|
|
------------
|
2016-12-27 03:15:43 +08:00
|
|
|
Seamless client IP/port floating
|
|
|
|
|
Added new packet format P_DATA_V2, which includes peer-id. If both the
|
|
|
|
|
server and client support it, the client sends all data packets in
|
|
|
|
|
the new format. When a data packet arrives, the server identifies peer
|
2016-10-21 22:42:37 +08:00
|
|
|
by peer-id. If peer's ip/port has changed, server assumes that
|
|
|
|
|
client has floated, verifies HMAC and updates ip/port in internal structs.
|
2019-01-24 04:17:17 +08:00
|
|
|
This allows the connection to be immediately restored, instead of requiring
|
2016-12-27 03:15:43 +08:00
|
|
|
a TLS handshake before the server accepts packets from the new client
|
|
|
|
|
ip/port.
|
2015-10-15 22:44:58 +08:00
|
|
|
|
2016-12-27 03:15:43 +08:00
|
|
|
Data channel cipher negotiation
|
|
|
|
|
Data channel ciphers (``--cipher``) are now by default negotiated. If a
|
|
|
|
|
client advertises support for Negotiable Crypto Parameters (NCP), the
|
|
|
|
|
server will choose a cipher (by default AES-256-GCM) for the data channel,
|
|
|
|
|
and tell the client to use that cipher. Data channel cipher negotiation
|
|
|
|
|
can be controlled using ``--ncp-ciphers`` and ``--ncp-disable``.
|
2016-06-06 05:41:23 +08:00
|
|
|
|
2016-11-24 22:04:51 +08:00
|
|
|
A more limited version also works in client-to-server and server-to-client
|
|
|
|
|
scenarios where one of the end points uses a v2.4 client or server and the
|
|
|
|
|
other side uses an older version. In such scenarios the v2.4 side will
|
|
|
|
|
change to the ``--cipher`` set by the remote side, if permitted by by
|
|
|
|
|
``--ncp-ciphers``. For example, a v2.4 client with ``--cipher BF-CBC``
|
|
|
|
|
and ``ncp-ciphers AES-256-GCM:AES-256-CBC`` can connect to both a v2.3
|
|
|
|
|
server with ``cipher BF-CBC`` as well as a server with
|
|
|
|
|
``cipher AES-256-CBC`` in its config. The other way around, a v2.3 client
|
|
|
|
|
with either ``cipher BF-CBC`` or ``cipher AES-256-CBC`` can connect to a
|
|
|
|
|
v2.4 server with e.g. ``cipher BF-CBC`` and
|
|
|
|
|
``ncp-ciphers AES-256-GCM:AES-256-CBC`` in its config. For this to work
|
|
|
|
|
it requires that OpenVPN was built without disabling OCC support.
|
|
|
|
|
|
2016-10-21 22:42:37 +08:00
|
|
|
AEAD (GCM) data channel cipher support
|
|
|
|
|
The data channel now supports AEAD ciphers (currently only GCM). The AEAD
|
2016-12-27 03:15:43 +08:00
|
|
|
packet format has a smaller crypto overhead than the CBC packet format,
|
|
|
|
|
(e.g. 20 bytes per packet for AES-128-GCM instead of 36 bytes per packet
|
|
|
|
|
for AES-128-CBC + HMAC-SHA1).
|
2016-05-16 18:13:04 +08:00
|
|
|
|
2016-10-21 22:42:37 +08:00
|
|
|
ECDH key exchange
|
2016-11-18 21:35:01 +08:00
|
|
|
The TLS control channel now supports for elliptic curve diffie-hellmann
|
2016-10-21 22:42:37 +08:00
|
|
|
key exchange (ECDH).
|
|
|
|
|
|
2017-06-29 03:15:38 +08:00
|
|
|
Improved Certificate Revocation List (CRL) processing
|
|
|
|
|
CRLs are now handled by the crypto library (OpenSSL or mbed TLS), instead
|
|
|
|
|
of inside OpenVPN itself. The crypto library implementations are more
|
|
|
|
|
strict than the OpenVPN implementation was. This might reject peer
|
|
|
|
|
certificates that would previously be accepted. If this occurs, OpenVPN
|
|
|
|
|
will log the crypto library's error description.
|
|
|
|
|
|
2016-12-27 03:15:43 +08:00
|
|
|
Dualstack round-robin DNS client connect
|
2016-10-21 22:42:37 +08:00
|
|
|
Instead of only using the first address of each ``--remote`` OpenVPN
|
|
|
|
|
will now try all addresses (IPv6 and IPv4) of a ``--remote`` entry.
|
|
|
|
|
|
2016-11-24 22:04:51 +08:00
|
|
|
Support for providing IPv6 DNS servers
|
2016-12-27 03:15:43 +08:00
|
|
|
A new DHCP sub-option ``DNS6`` is added alongside with the already existing
|
|
|
|
|
``DNS`` sub-option. This is used to provide DNS resolvers available over
|
|
|
|
|
IPv6. This may be pushed to clients where `` --up`` scripts and ``--plugin``
|
|
|
|
|
can act upon it through the ``foreign_option_<n>`` environment variables.
|
2016-11-24 22:04:51 +08:00
|
|
|
|
2016-12-27 03:15:43 +08:00
|
|
|
Support for the Windows client picking up this new sub-option is added,
|
|
|
|
|
however IPv6 DNS resolvers need to be configured via ``netsh`` which requires
|
|
|
|
|
administrator privileges unless the new interactive services on Windows is
|
|
|
|
|
being used. If the interactive service is used, this service will execute
|
|
|
|
|
``netsh`` in the background with the proper privileges.
|
2016-11-24 22:04:51 +08:00
|
|
|
|
2016-10-21 22:42:37 +08:00
|
|
|
New improved Windows Background service
|
2016-11-18 21:35:01 +08:00
|
|
|
The new OpenVPNService is based on openvpnserv2, a complete rewrite of the OpenVPN
|
2016-10-21 22:42:37 +08:00
|
|
|
service wrapper. It is intended for launching OpenVPN instances that should be
|
|
|
|
|
up at all times, instead of being manually launched by a user. OpenVPNService is
|
|
|
|
|
able to restart individual OpenVPN processes if they crash, and it also works
|
|
|
|
|
properly on recent Windows versions. OpenVPNServiceLegacy tends to work poorly,
|
|
|
|
|
if at all, on newer Windows versions (8+) and its use is not recommended.
|
|
|
|
|
|
|
|
|
|
New interactive Windows service
|
2016-11-18 21:35:01 +08:00
|
|
|
The installer starts OpenVPNServiceInteractive automatically and configures
|
2016-10-21 22:42:37 +08:00
|
|
|
it to start at system startup.
|
|
|
|
|
|
|
|
|
|
The interactive Windows service allows unprivileged users to start
|
2016-11-18 21:35:01 +08:00
|
|
|
OpenVPN connections in the global config directory (usually
|
2016-11-29 03:06:52 +08:00
|
|
|
C:\\Program Files\\OpenVPN\\config) using OpenVPN GUI without any
|
2016-11-18 21:35:01 +08:00
|
|
|
extra configuration.
|
2016-10-21 22:42:37 +08:00
|
|
|
|
2016-11-18 21:35:01 +08:00
|
|
|
Users who belong to the built-in Administrator group or to the
|
|
|
|
|
local "OpenVPN Administrator" group can also store configuration
|
2016-11-29 03:06:52 +08:00
|
|
|
files under %USERPROFILE%\\OpenVPN\\config for use with the
|
2016-11-18 21:35:01 +08:00
|
|
|
interactive service.
|
2015-10-15 22:44:58 +08:00
|
|
|
|
|
|
|
|
redirect-gateway ipv6
|
|
|
|
|
OpenVPN has now feature parity between IPv4 and IPv6 for redirect
|
|
|
|
|
gateway including the handling of overlapping IPv6 routes with
|
2016-12-27 03:15:43 +08:00
|
|
|
IPv6 remote VPN server address.
|
2015-10-15 22:44:58 +08:00
|
|
|
|
2016-10-21 22:42:37 +08:00
|
|
|
LZ4 Compression and pushable compression
|
2016-11-18 21:35:01 +08:00
|
|
|
Additionally to LZO compression OpenVPN now also supports LZ4 compression.
|
2016-10-21 22:42:37 +08:00
|
|
|
Compression options are now pushable from the server.
|
2015-10-15 22:44:58 +08:00
|
|
|
|
2016-12-27 03:15:43 +08:00
|
|
|
Filter pulled options client-side: pull-filter
|
2016-10-21 22:42:37 +08:00
|
|
|
New option to explicitly allow or reject options pushed by the server.
|
|
|
|
|
May be used multiple times and is applied in the order specified.
|
2015-10-15 22:44:58 +08:00
|
|
|
|
2016-12-27 03:15:43 +08:00
|
|
|
Per-client remove push options: push-remove
|
|
|
|
|
New option to remove options on a per-client basis from the "push" list
|
|
|
|
|
(more fine-grained than ``--push-reset``).
|
2015-10-15 22:44:58 +08:00
|
|
|
|
2016-10-21 22:42:37 +08:00
|
|
|
Http proxy password inside config file
|
|
|
|
|
Http proxy passwords can be specified with the inline file option
|
|
|
|
|
``<http-proxy-user-pass>`` .. ``</http-proxy-user-pass>``
|
2015-10-15 22:44:58 +08:00
|
|
|
|
2016-12-27 03:15:43 +08:00
|
|
|
Windows version detection
|
2015-12-30 05:02:37 +08:00
|
|
|
Windows version is detected, logged and possibly signalled to server
|
2016-12-27 03:15:43 +08:00
|
|
|
(IV_PLAT_VER=<nn> if ``--push-peer-info`` is set on client).
|
2015-10-15 22:44:58 +08:00
|
|
|
|
2016-10-29 03:48:40 +08:00
|
|
|
Authentication tokens
|
2016-12-27 03:15:43 +08:00
|
|
|
In situations where it is not suitable to save user passwords on the client,
|
|
|
|
|
OpenVPN has support for pushing a --auth-token since v2.3. This option is
|
2016-10-29 03:48:40 +08:00
|
|
|
pushed from the server to the client with a token value to be used instead
|
|
|
|
|
of the users password. For this to work, the authentication plug-in would
|
|
|
|
|
need to implement this support as well. In OpenVPN 2.4 --auth-gen-token
|
|
|
|
|
is introduced, which will allow the OpenVPN server to generate a random
|
|
|
|
|
token and push it to the client without any changes to the authentication
|
|
|
|
|
modules. When the clients need to re-authenticate the OpenVPN server will
|
2016-12-27 03:15:43 +08:00
|
|
|
do the authentication internally, instead of sending the re-authentication
|
|
|
|
|
request to the authentication module . This feature is especially
|
|
|
|
|
useful in configurations which use One Time Password (OTP) authentication
|
|
|
|
|
schemes, as this allows the tunnel keys to be renegotiated regularly without
|
2016-10-29 03:48:40 +08:00
|
|
|
any need to supply new OTP codes.
|
|
|
|
|
|
2016-10-21 22:42:37 +08:00
|
|
|
keying-material-exporter
|
|
|
|
|
Keying Material Exporter [RFC-5705] allow additional keying material to be
|
|
|
|
|
derived from existing TLS channel.
|
Add AEAD cipher support (GCM)
Add Authenticated Encryption with Additional Data (AEAD) support for
ciphers, which removes the need for a separate HMAC step. The MAC is
integrated into the cipher and the MAC tag is prepended to the payload.
This patch is inspired by the patch originally submitted by Kenny Root
on the openvpn-devel mailinglist, but does a number things differently:
* Don't support XTS (makes no sense for VPN)
* Don't support CCM (needs extra code to make it actually work)
* Don't force the user to specify "auth none" (that would break
tls-auth)
* Add support for PolarSSL (and change internal API for this)
* Update openvpn frame size ('link mtu') calculation for AEAD modes
* Use the HMAC key as an implicit part of the IV to save 8 bytes per
data channel network packet.
* Also authenticate the opcode/peer-id as AD in P_DATA_V2 packets.
By using the negotiated HMAC key as an implicit part of the IV for
AEAD-mode ciphers in TLS mode, we can save (at least) 8 bytes on each
packet sent. This is particularly interesting for connections which
transfer many small packets, such as remote desktop or voip connections.
The current AEAD-mode ciphers (for now GCM) are based on CTR-mode cipher
operation, which requires the IV to be unique (but does not require
unpredictability).
IV uniqueness is guaranteed by using a combination of at least 64-bits
of the HMAC key (unique per TLS session), and a 32-bit packet counter.
The last 32-bit word of the 128-bit cipher block is not part of the IV,
but is used as a block counter.
AEAD cipher mode is not available for static key mode, since IV
uniqueness is harder the guarantee over sessions, and I believe
supporting AEAD in static key mode too is not worth the extra
complexity. Modern setups should simply use TLS mode.
OpenSSL 1.0.1-1.0.1c will not work with AEAD mode, because those
versions have an unnecessary check that fails to update the cipher if
the tag was not already set. 1.0.1d, which fixes that, was released in
February 2013. People should have updated, and distros should have
backported the fix by now.
Changes in v2:
* Remove extra code that was just for making OpenSSL 1.0.1-1.0.1c work
in AEAD mode.
* Do not make AEAD support configurable in ./configure.
* Get rid of '12' magic constant in openvpn_encrypt_aead().
* Update manpage to explain that --auth is ignored for the data channel
when using an AEAD cipher.
* Move setting the IV in AEAD cipher modes to the IV generation code.
This is a more natural place and now we can pull iv[] into the IV
generation scope.
* Read packet ID directly from packet buffer instead of from iv buffer,
to remove the need for an extra buffer.
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <CAA1AbxL_S4umZr5Nd0VTvUvXEHjoWmji18GqM6FgmWqntOKqaA@mail.gmail.com>
URL: http://article.gmane.org/gmane.network.openvpn.devel/11162
Signed-off-by: Gert Doering <gert@greenie.muc.de>
2015-10-24 22:44:09 +08:00
|
|
|
|
2016-10-21 22:42:37 +08:00
|
|
|
Android platform support
|
|
|
|
|
Support for running on Android using Android's VPNService API has been added.
|
2016-12-27 03:15:43 +08:00
|
|
|
See doc/android.txt for more details. This support is primarily used in
|
2016-10-21 22:42:37 +08:00
|
|
|
the OpenVPN for Android app (https://github.com/schwabe/ics-openvpn)
|
|
|
|
|
|
|
|
|
|
AIX platform support
|
2016-11-18 21:35:01 +08:00
|
|
|
AIX platform support has been added. The support only includes tap
|
2016-10-21 22:42:37 +08:00
|
|
|
devices since AIX does not provide tun interface.
|
2016-06-29 05:36:11 +08:00
|
|
|
|
Add control channel encryption (--tls-crypt)
This adds a --tls-crypt option, which uses a pre-shared static key (like
the --tls-auth key) to encrypt control channel packets.
Encrypting control channel packets has three main advantages:
* It provides more privacy by hiding the certificate used for the TLS
connection.
* It is harder to identify OpenVPN traffic as such.
* It provides "poor-man's" post-quantum security, against attackers who
will never know the pre-shared key (i.e. no forward secrecy).
Control channel packet encryption
---------------------------------
We propose to use the following encryption method, based on the SIV
construction [0], to achieve nonce misuse-resistant authenticated
encryption:
msg = control channel plaintext
header = opcode (1 byte) || session_id (8 bytes) || packet_id (8
bytes)
Ka = authentication key (256 bits)
Ke = encryption key (256 bits)
(Ka and Ke are pre-shared keys, like with --tls-auth)
auth_tag = HMAC-SHA256(Ka, header || msg)
IV = 128 most-significant bits of auth_tag
ciph = AES256-CTR(Ke, IV, msg)
output = Header || Tag || Ciph
This boils down to the following on-the-wire packet format:
-opcode- || -session_id- || -packet_id- || auth_tag || * payload *
Where
- XXX - means authenticated, and
* XXX * means authenticated and encrypted.
Which is very similar to the current tls-auth packet format, and has the
same overhead as "--tls-auth" with "--auth SHA256".
The use of a nonce misuse-resistant authenticated encryption scheme
allows us to worry less about the risks of nonce collisions. This is
important, because in contrast with the data channel in TLS mode, we
will not be able to rotate tls-crypt keys often or fully guarantee nonce
uniqueness. For non misuse-resistant modes such as GCM [1], [2], the
data channel in TLS mode only has to ensure that the packet counter
never rolls over, while tls-crypt would have to provide nonce uniqueness
over all control channel packets sent by all clients, for the lifetime
of the tls-crypt key.
Unlike with tls-auth, no --key-direction has to be specified for
tls-crypt. TLS servers always use key direction 1, and TLS clients
always use key direction 2, which means that client->server traffic and
server->client traffic always use different keys, without requiring
configuration.
Using fixed, secure, encryption and authentication algorithms makes both
implementation and configuration easier. If we ever want to, we can
extend this to support other crypto primitives. Since tls-crypt should
provide privacy as well as DoS protection, these should not be made
negotiable.
Security considerations:
------------------------
tls-crypt is a best-effort mechanism that aims to provide as much
privacy and security as possible, while staying as simple as possible.
The following are some security considerations for this scheme.
1. The same tls-crypt key is potentially shared by a lot of peers, so it
is quite likely to get compromised. Once an attacker acquires the
tls-crypt key, this mechanism no longer provides any security against
the attacker.
2. Since many peers potentially use the tls-crypt key for a long time, a
lot of data might be encrypted under the tls-crypt key. This leads
to two potential problems:
* The "opcode || session id || packet id" combination might collide.
This might happen in larger setups, because the session id contains
just 64 bits or random. Using the uniqueness requirement from the
GCM spec [3] (a collision probability of less than 2^(-32)),
uniqueness is achieved when using the tls-crypt key for at most
2^16 (65536) connections per process start. (The packet id
includes the daemon start time in the packet ID, which should be
different after stopping and (re)starting OpenPVN.)
And if a collision happens, an attacker can *only* learn whether
colliding packets contain the same plaintext. Attackers will not
be able to learn anything else about the plaintext (unless the
attacker knows the plaintext of one of these packets, of course).
Since the impact is limited, I consider this an acceptable
remaining risk.
* The IVs used in encryption might collide. When two IVs collide, an
attacker can learn the xor of the two plaintexts by xorring the
ciphertexts. This is a serious loss of confidentiality. The IVs
are 128-bit, so when HMAC-SHA256 is a secure PRF (an assumption
that must also hold for TLS), and we use the same uniqueness
requirement from [3], this limits the total amount of control
channel messages for all peers in the setup to 2^48. Assuming a
large setup of 2^16 (65536) clients, and a (conservative) number of
2^16 control channel packets per connection on average, this means
that clients may set up 2^16 connections on average. I think these
numbers are reasonable.
(I have a follow-up proposal to use client-specific tls-auth/tls-crypt
keys to partially mitigate these issues, but let's tackle this patch
first.)
References:
-----------
[0] Rogaway & Shrimpton, A Provable-Security Treatment of the Key-Wrap
Problem, 2006
(https://www.iacr.org/archive/eurocrypt2006/40040377/40040377.pdf)
[1] Ferguson, Authentication weaknesses in GCM, 2005
(http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Ferg
uson2.pdf)
[2] Joux, Authentication Failures in NIST version of GCM, 2006
(http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/800-38_Serie
s-Drafts/GCM/Joux_comments.pdf)
[3] Dworking, Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC, 2007
(http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf)
Patch history:
--------------
v2 - processed Arne's review comments:
* Error out early with a clear error message when AES-256-CTR or
HMAC-SHA-256 are not supported by the crypto library.
* Clarify that cipher_ctx_reset() sets the IV.
v3 - actually add error messages promised in v2...
Signed-off-by: Steffan Karger <steffan.karger@fox-it.com>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <1479216586-20078-1-git-send-email-steffan.karger@fox-it.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13069.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
2016-11-15 21:29:46 +08:00
|
|
|
Control channel encryption (``--tls-crypt``)
|
|
|
|
|
Use a pre-shared static key (like the ``--tls-auth`` key) to encrypt control
|
|
|
|
|
channel packets. Provides more privacy, some obfuscation and poor-man's
|
|
|
|
|
post-quantum security.
|
|
|
|
|
|
2016-12-07 17:56:57 +08:00
|
|
|
Asynchronous push reply
|
2016-12-14 20:23:30 +08:00
|
|
|
Plug-ins providing support for deferred authentication can benefit from a more
|
|
|
|
|
responsive authentication where the server sends PUSH_REPLY immediately once
|
2016-12-27 03:15:43 +08:00
|
|
|
the authentication result is ready, instead of waiting for the the client to
|
2016-12-14 20:23:30 +08:00
|
|
|
to send PUSH_REQUEST once more. This requires OpenVPN to be built with
|
|
|
|
|
``./configure --enable-async-push``. This is a compile-time only switch.
|
2016-12-07 17:56:57 +08:00
|
|
|
|
Add AEAD cipher support (GCM)
Add Authenticated Encryption with Additional Data (AEAD) support for
ciphers, which removes the need for a separate HMAC step. The MAC is
integrated into the cipher and the MAC tag is prepended to the payload.
This patch is inspired by the patch originally submitted by Kenny Root
on the openvpn-devel mailinglist, but does a number things differently:
* Don't support XTS (makes no sense for VPN)
* Don't support CCM (needs extra code to make it actually work)
* Don't force the user to specify "auth none" (that would break
tls-auth)
* Add support for PolarSSL (and change internal API for this)
* Update openvpn frame size ('link mtu') calculation for AEAD modes
* Use the HMAC key as an implicit part of the IV to save 8 bytes per
data channel network packet.
* Also authenticate the opcode/peer-id as AD in P_DATA_V2 packets.
By using the negotiated HMAC key as an implicit part of the IV for
AEAD-mode ciphers in TLS mode, we can save (at least) 8 bytes on each
packet sent. This is particularly interesting for connections which
transfer many small packets, such as remote desktop or voip connections.
The current AEAD-mode ciphers (for now GCM) are based on CTR-mode cipher
operation, which requires the IV to be unique (but does not require
unpredictability).
IV uniqueness is guaranteed by using a combination of at least 64-bits
of the HMAC key (unique per TLS session), and a 32-bit packet counter.
The last 32-bit word of the 128-bit cipher block is not part of the IV,
but is used as a block counter.
AEAD cipher mode is not available for static key mode, since IV
uniqueness is harder the guarantee over sessions, and I believe
supporting AEAD in static key mode too is not worth the extra
complexity. Modern setups should simply use TLS mode.
OpenSSL 1.0.1-1.0.1c will not work with AEAD mode, because those
versions have an unnecessary check that fails to update the cipher if
the tag was not already set. 1.0.1d, which fixes that, was released in
February 2013. People should have updated, and distros should have
backported the fix by now.
Changes in v2:
* Remove extra code that was just for making OpenSSL 1.0.1-1.0.1c work
in AEAD mode.
* Do not make AEAD support configurable in ./configure.
* Get rid of '12' magic constant in openvpn_encrypt_aead().
* Update manpage to explain that --auth is ignored for the data channel
when using an AEAD cipher.
* Move setting the IV in AEAD cipher modes to the IV generation code.
This is a more natural place and now we can pull iv[] into the IV
generation scope.
* Read packet ID directly from packet buffer instead of from iv buffer,
to remove the need for an extra buffer.
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <CAA1AbxL_S4umZr5Nd0VTvUvXEHjoWmji18GqM6FgmWqntOKqaA@mail.gmail.com>
URL: http://article.gmane.org/gmane.network.openvpn.devel/11162
Signed-off-by: Gert Doering <gert@greenie.muc.de>
2015-10-24 22:44:09 +08:00
|
|
|
|
2016-11-15 04:06:07 +08:00
|
|
|
Deprecated features
|
|
|
|
|
-------------------
|
2017-08-16 05:54:51 +08:00
|
|
|
For an up-to-date list of all deprecated options, see this wiki page:
|
|
|
|
|
https://community.openvpn.net/openvpn/wiki/DeprecatedOptions
|
|
|
|
|
|
2017-08-16 04:53:01 +08:00
|
|
|
- ``--key-method 1`` is deprecated in OpenVPN 2.4 and will be removed in v2.5.
|
|
|
|
|
Migrate away from ``--key-method 1`` as soon as possible. The recommended
|
|
|
|
|
approach is to remove the ``--key-method`` option from the configuration
|
|
|
|
|
files, OpenVPN will then use ``--key-method 2`` by default. Note that this
|
|
|
|
|
requires changing the option in both the client and server side configs.
|
2016-11-15 04:06:07 +08:00
|
|
|
|
2017-08-16 04:53:01 +08:00
|
|
|
- ``--tls-remote`` is removed in OpenVPN 2.4, as indicated in the v2.3
|
|
|
|
|
man-pages. Similar functionality is provided via ``--verify-x509-name``,
|
|
|
|
|
which does the same job in a better way.
|
2016-11-15 21:40:56 +08:00
|
|
|
|
2017-08-16 04:53:01 +08:00
|
|
|
- ``--compat-names`` and ``--no-name-remapping`` were deprecated in OpenVPN 2.3
|
|
|
|
|
and will be removed in v2.5. All scripts and plug-ins depending on the old
|
|
|
|
|
non-standard X.509 subject formatting must be updated to the standardized
|
|
|
|
|
formatting. See the man page for more information.
|
2016-11-15 04:06:07 +08:00
|
|
|
|
2017-08-16 04:53:01 +08:00
|
|
|
- ``--no-iv`` is deprecated in OpenVPN 2.4 and will be removed in v2.5.
|
2016-12-08 03:20:47 +08:00
|
|
|
|
2017-08-16 04:53:01 +08:00
|
|
|
- ``--keysize`` is deprecated in OpenVPN 2.4 and will be removed in v2.6
|
|
|
|
|
together with the support of ciphers with cipher block size less than
|
|
|
|
|
128-bits.
|
2017-07-01 19:29:51 +08:00
|
|
|
|
2017-08-16 05:54:51 +08:00
|
|
|
- ``--comp-lzo`` is deprecated in OpenVPN 2.4. Use ``--compress`` instead.
|
|
|
|
|
|
|
|
|
|
- ``--ifconfig-pool-linear`` has been deprecated since OpenVPN 2.1 and will be
|
|
|
|
|
removed in v2.5. Use ``--topology p2p`` instead.
|
|
|
|
|
|
|
|
|
|
- ``--client-cert-not-required`` is deprecated in OpenVPN 2.4 and will be removed
|
|
|
|
|
in v2.5. Use ``--verify-client-cert none`` for a functional equivalent.
|
|
|
|
|
|
|
|
|
|
- ``--ns-cert-type`` is deprecated in OpenVPN 2.3.18 and v2.4. It will be removed
|
|
|
|
|
in v2.5. Use the far better ``--remote-cert-tls`` option which replaces this
|
|
|
|
|
feature.
|
|
|
|
|
|
2017-06-20 01:44:00 +08:00
|
|
|
|
2015-10-15 22:44:58 +08:00
|
|
|
User-visible Changes
|
|
|
|
|
--------------------
|
2016-12-27 03:15:43 +08:00
|
|
|
- When using ciphers with cipher blocks less than 128-bits,
|
2016-12-24 00:07:44 +08:00
|
|
|
OpenVPN will complain loudly if the configuration uses ciphers considered
|
|
|
|
|
weak, such as the SWEET32 attack vector. In such scenarios, OpenVPN will by
|
2016-12-27 03:15:43 +08:00
|
|
|
default renegotiate for each 64MB of transported data (``--reneg-bytes``).
|
2016-12-24 00:07:44 +08:00
|
|
|
This renegotiation can be disabled, but is HIGHLY DISCOURAGED.
|
|
|
|
|
|
2015-11-29 17:39:24 +08:00
|
|
|
- For certificate DNs with duplicate fields, e.g. "OU=one,OU=two", both fields
|
|
|
|
|
are now exported to the environment, where each second and later occurrence
|
|
|
|
|
of a field get _$N appended to it's field name, starting at N=1. For the
|
|
|
|
|
example above, that would result in e.g. X509_0_OU=one, X509_0_OU_1=two.
|
|
|
|
|
Note that this breaks setups that rely on the fact that OpenVPN would
|
2019-01-24 04:17:17 +08:00
|
|
|
previously (incorrectly) only export the last occurrence of a field.
|
2015-11-29 17:39:24 +08:00
|
|
|
|
2016-12-27 03:15:43 +08:00
|
|
|
- ``proto udp`` and ``proto tcp`` now use both IPv4 and IPv6. The new
|
|
|
|
|
options ``proto udp4`` and ``proto tcp4`` use IPv4 only.
|
2015-10-15 22:44:58 +08:00
|
|
|
|
2016-10-21 22:42:37 +08:00
|
|
|
- ``--sndbuf`` and ``--recvbuf`` default now to OS defaults instead of 64k
|
2015-10-15 22:44:58 +08:00
|
|
|
|
2016-12-27 03:15:43 +08:00
|
|
|
- OpenVPN exits with an error if an option has extra parameters;
|
2015-10-15 22:44:58 +08:00
|
|
|
previously they were silently ignored
|
|
|
|
|
|
2016-10-21 22:42:37 +08:00
|
|
|
- ``--tls-auth`` always requires OpenVPN static key files and will no
|
2015-10-15 22:44:58 +08:00
|
|
|
longer work with free form files
|
|
|
|
|
|
2016-10-21 22:42:37 +08:00
|
|
|
- ``--proto udp6/tcp6`` in server mode will now try to always listen to
|
|
|
|
|
both IPv4 and IPv6 on platforms that allow it. Use ``--bind ipv6only``
|
2015-10-15 22:44:58 +08:00
|
|
|
to explicitly listen only on IPv6.
|
2015-11-30 02:52:24 +08:00
|
|
|
|
2016-10-21 22:42:37 +08:00
|
|
|
- Removed ``--enable-password-save`` from configure. This option is now
|
2015-11-30 02:52:24 +08:00
|
|
|
always enabled.
|
2016-01-10 22:37:19 +08:00
|
|
|
|
2016-04-18 02:32:07 +08:00
|
|
|
- Stricter default TLS cipher list (override with ``--tls-cipher``), that now
|
|
|
|
|
also disables:
|
|
|
|
|
|
|
|
|
|
* Non-ephemeral key exchange using static (EC)DH keys
|
|
|
|
|
* DSS private keys
|
|
|
|
|
|
2016-05-04 04:14:38 +08:00
|
|
|
- mbed TLS builds: changed the tls_digest_N values exported to the script
|
2016-04-05 03:59:38 +08:00
|
|
|
environment to be equal to the ones exported by OpenSSL builds, namely
|
|
|
|
|
the certificate fingerprint (was the hash of the 'to be signed' data).
|
|
|
|
|
|
2016-05-04 04:14:38 +08:00
|
|
|
- mbed TLS builds: minimum RSA key size is now 2048 bits. Shorter keys will
|
|
|
|
|
not be accepted, both local and from the peer.
|
|
|
|
|
|
2016-12-27 03:15:43 +08:00
|
|
|
- ``--connect-timeout`` now specifies the timeout until the first TLS packet
|
2016-10-21 22:42:37 +08:00
|
|
|
is received (identical to ``--server-poll-timeout``) and this timeout now
|
|
|
|
|
includes the removed socks proxy timeout and http proxy timeout.
|
|
|
|
|
|
2016-12-27 03:15:43 +08:00
|
|
|
In ``--static`` mode ``connect-timeout`` specifies the timeout for TCP and
|
2016-10-21 22:42:37 +08:00
|
|
|
proxy connection establishment
|
|
|
|
|
|
|
|
|
|
- ``--connect-retry-max`` now specifies the maximum number of unsuccessful
|
|
|
|
|
attempts of each remote/connection entry before exiting.
|
|
|
|
|
|
|
|
|
|
- ``--http-proxy-timeout`` and the static non-changeable socks timeout (5s)
|
|
|
|
|
have been folded into a "unified" ``--connect-timeout`` which covers all
|
2016-06-11 22:43:15 +08:00
|
|
|
steps needed to connect to the server, up to the start of the TLS exchange.
|
|
|
|
|
The default value has been raised to 120s, to handle slow http/socks
|
|
|
|
|
proxies graciously. The old "fail TCP fast" behaviour can be achieved by
|
2016-10-21 22:42:37 +08:00
|
|
|
adding "``--connect-timeout 10``" to the client config.
|
2016-06-11 22:43:15 +08:00
|
|
|
|
2016-10-21 22:42:37 +08:00
|
|
|
- ``--http-proxy-retry`` and ``--sock-proxy-retry`` have been removed. Proxy connections
|
|
|
|
|
will now behave like regular connection entries and generate a USR1 on failure.
|
2016-04-18 02:32:07 +08:00
|
|
|
|
2016-10-21 22:42:37 +08:00
|
|
|
- ``--connect-retry`` gets an optional second argument that specifies the maximum
|
2016-07-05 23:32:50 +08:00
|
|
|
time in seconds to wait between reconnection attempts when an exponential
|
|
|
|
|
backoff is triggered due to repeated retries. Default = 300 seconds.
|
|
|
|
|
|
2016-06-29 05:36:11 +08:00
|
|
|
- Data channel cipher negotiation (see New features section) can override
|
2016-10-21 22:42:37 +08:00
|
|
|
ciphers configured in the config file. Use ``--ncp-disable`` if you do not want
|
|
|
|
|
this behavior.
|
2016-06-29 05:36:11 +08:00
|
|
|
|
2016-10-14 00:54:16 +08:00
|
|
|
- All tun devices on all platforms are always considered to be IPv6
|
2016-10-21 22:42:37 +08:00
|
|
|
capable. The ``--tun-ipv6`` option is ignored (behaves like it is always
|
2016-10-14 00:54:16 +08:00
|
|
|
on).
|
|
|
|
|
|
2016-12-27 03:15:43 +08:00
|
|
|
- On the client side recursively routed packets, which have the same destination
|
|
|
|
|
as the VPN server, are dropped. This can be disabled with
|
Drop recursively routed packets
v4:
- Account for IP header offset in TAP mode
- Correct handle of non-IP protocols in TAP mode
v3: Use better way of figuring out IP proto version which
does not break TAP mode. Add an option to allow recursive
routing, could be useful when packets sent by openvpn itself
are not subject to the routing tables that would move packets
into the tunnel.
v2: better method naming
On certain OSes (Windows, OS X) when network adapter is
disabled (ethernet cable pulled off, Wi-Fi hardware switch disabled),
operating system starts to use tun as an external interface.
Outgoing packets are routed to tun, UDP encapsulated, given to
routing table and sent to.. tun.
As a consequence, system starts talking to itself on full power,
traffic counters skyrocket and user is not happy.
To prevent that, drop packets which have gateway IP as
destination address.
Tested on Win7/10, OS X, Linux.
Trac #642
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1478208503-25929-1-git-send-email-lstipakov@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12894.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
2016-11-04 05:28:23 +08:00
|
|
|
--allow-recursive-routing option.
|
2016-06-29 05:36:11 +08:00
|
|
|
|
2016-12-27 03:15:43 +08:00
|
|
|
- On Windows, when the ``--register-dns`` option is set, OpenVPN no longer
|
2016-12-01 05:51:36 +08:00
|
|
|
restarts the ``dnscache`` service - this had unwanted side effects, and
|
|
|
|
|
seems to be no longer necessary with currently supported Windows versions.
|
|
|
|
|
|
2016-12-27 03:15:43 +08:00
|
|
|
- If no flags are given, and the interactive Windows service is used, "def1"
|
|
|
|
|
is implicitly set (because "delete and later reinstall the existing
|
|
|
|
|
default route" does not work well here). If not using the service,
|
|
|
|
|
the old behaviour is kept.
|
|
|
|
|
|
2016-12-01 18:41:45 +08:00
|
|
|
- OpenVPN now reloads a CRL only if the modication time or file size has
|
|
|
|
|
changed, instead of for each new connection. This reduces the connection
|
|
|
|
|
setup time, in particular when using large CRLs.
|
|
|
|
|
|
2016-12-27 03:15:43 +08:00
|
|
|
- OpenVPN now ships with more up-to-date systemd unit files which take advantage
|
2016-12-02 07:09:00 +08:00
|
|
|
of the improved service management as well as some hardening steps. The
|
2016-12-10 03:52:17 +08:00
|
|
|
configuration files are picked up from the /etc/openvpn/server/ and
|
|
|
|
|
/etc/openvpn/client/ directories (depending on unit file). This also avoids
|
|
|
|
|
these new unit files and how they work to collide with older pre-existing
|
|
|
|
|
unit files.
|
2016-12-02 07:09:00 +08:00
|
|
|
|
2016-12-27 03:15:43 +08:00
|
|
|
- Using ``--no-iv`` (which is generally not a recommended setup) will
|
2016-12-08 02:01:24 +08:00
|
|
|
require explicitly disabling NCP with ``--disable-ncp``. This is
|
|
|
|
|
intentional because NCP will by default use AES-GCM, which requires
|
|
|
|
|
an IV - so we want users of that option to consciously reconsider.
|
|
|
|
|
|
2016-12-01 18:41:45 +08:00
|
|
|
|
2016-01-10 22:37:19 +08:00
|
|
|
Maintainer-visible changes
|
|
|
|
|
--------------------------
|
|
|
|
|
- OpenVPN no longer supports building with crypto support, but without TLS
|
|
|
|
|
support. As a consequence, OPENSSL_CRYPTO_{CFLAGS,LIBS} and
|
|
|
|
|
OPENSSL_SSL_{CFLAGS,LIBS} have been merged into OPENSSL_{CFLAGS,LIBS}. This
|
|
|
|
|
is particularly relevant for maintainers who build their own OpenSSL library,
|
|
|
|
|
e.g. when cross-compiling.
|
2016-12-02 07:09:00 +08:00
|
|
|
|
|
|
|
|
- Linux distributions using systemd is highly encouraged to ship these new unit
|
|
|
|
|
files instead of older ones, to provide a unified behaviour across systemd
|
|
|
|
|
based Linux distributions.
|
2016-12-13 20:16:56 +08:00
|
|
|
|
2017-08-16 04:53:01 +08:00
|
|
|
- With OpenVPN 2.4, the project has moved over to depend on and actively use
|
2016-12-27 03:15:43 +08:00
|
|
|
the official C99 standard (-std=c99). This may fail on some older compiler/libc
|
|
|
|
|
header combinations. In most of these situations it is recommended to
|
|
|
|
|
use -std=gnu99 in CFLAGS. This is known to be needed when doing
|
2016-12-13 20:16:56 +08:00
|
|
|
i386/i686 builds on RHEL5.
|
2017-03-05 02:49:57 +08:00
|
|
|
|
2017-06-20 01:44:00 +08:00
|
|
|
|
2017-11-13 00:36:36 +08:00
|
|
|
Version 2.4.5
|
|
|
|
|
=============
|
|
|
|
|
|
|
|
|
|
New features
|
|
|
|
|
------------
|
|
|
|
|
- The new option ``--tls-cert-profile`` can be used to restrict the set of
|
|
|
|
|
allowed crypto algorithms in TLS certificates in mbed TLS builds. The
|
|
|
|
|
default profile is 'legacy' for now, which allows SHA1+, RSA-1024+ and any
|
|
|
|
|
elliptic curve certificates. The default will be changed to the 'preferred'
|
|
|
|
|
profile in the future, which requires SHA2+, RSA-2048+ and any curve.
|
|
|
|
|
|
|
|
|
|
|
2017-05-05 04:42:01 +08:00
|
|
|
Version 2.4.3
|
|
|
|
|
=============
|
Fix mbedtls fingerprint calculation
Commit 'Migrate to mbed TLS 2.x' (86d8cd68) introduced a bug in mbedtls
builds where we would calculate the certificate fingerprint over the
(too-short) 'to-be-signed' length of the certificate, rather than over the
certificate including the signature. Fix that.
The security impact of the incorrect calculation is very minimal; the last
few bytes (max 4, typically 4) are not verified by the fingerprint. We
expect no real-world impact, because users that used this feature before
will notice that it has suddenly stopped working, and users that didn't
will notice that connection setup fails.
Even if the user managed to somehow extract the incorrect hash (e.g. by
reading out the tls_digest_* env vars using a --tls-verify script), the
impact is miminal: the last 4 bytes must still be properly signed by the
CA, and typically contain extension fields, or the last bytes of the
public key (which are hard to choose). The most important bits of the
certificate were always checked: the version, serial, signature algorithm,
issuer, validity and subject.
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <1495285075-4957-1-git-send-email-steffan@karger.me>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14711.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
2017-05-20 20:57:55 +08:00
|
|
|
|
2017-06-20 01:44:00 +08:00
|
|
|
New features
|
|
|
|
|
------------
|
|
|
|
|
- Support building with OpenSSL 1.1 now (in addition to older versions)
|
|
|
|
|
|
|
|
|
|
- On Win10, set low interface metric for TAP adapter when block-outside-dns
|
|
|
|
|
is in use, to make Windows prefer the TAP adapter for DNS queries
|
|
|
|
|
(avoiding large delays)
|
|
|
|
|
|
|
|
|
|
|
2017-06-19 17:28:36 +08:00
|
|
|
Security
|
|
|
|
|
--------
|
2017-06-20 01:44:00 +08:00
|
|
|
- CVE-2017-7522: Fix ``--x509-track`` post-authentication remote DoS
|
2017-08-16 04:53:01 +08:00
|
|
|
A client could crash a v2.4+ mbedtls server, if that server uses the
|
2017-06-20 01:44:00 +08:00
|
|
|
``--x509-track`` option and the client has a correct, signed and unrevoked
|
2017-06-19 17:28:36 +08:00
|
|
|
certificate that contains an embedded NUL in the certificate subject.
|
|
|
|
|
Discovered and reported to the OpenVPN security team by Guido Vranken.
|
2017-06-20 01:44:00 +08:00
|
|
|
|
2017-06-19 17:28:38 +08:00
|
|
|
- CVE-2017-7521: Fix post-authentication remote-triggerable memory leaks
|
|
|
|
|
A client could cause a server to leak a few bytes each time it connects to the
|
2019-01-24 04:17:17 +08:00
|
|
|
server. That can eventually cause the server to run out of memory, and thereby
|
2017-06-19 17:28:38 +08:00
|
|
|
causing the server process to terminate. Discovered and reported to the
|
|
|
|
|
OpenVPN security team by Guido Vranken. (OpenSSL builds only.)
|
2017-06-20 01:44:00 +08:00
|
|
|
|
2017-06-19 17:28:40 +08:00
|
|
|
- CVE-2017-7521: Fix a potential post-authentication remote code execution
|
2017-06-20 01:44:00 +08:00
|
|
|
attack on servers that use the ``--x509-username-field`` option with an X.509
|
2017-06-19 17:28:40 +08:00
|
|
|
extension field (option argument prefixed with ``ext:``). A client that can
|
|
|
|
|
cause a server to run out-of-memory (see above) might be able to cause the
|
|
|
|
|
server to double free, which in turn might lead to remote code execution.
|
|
|
|
|
Discovered and reported to the OpenVPN security team by Guido Vranken.
|
|
|
|
|
(OpenSSL builds only.)
|
2017-06-19 17:28:36 +08:00
|
|
|
|
2017-06-20 01:44:00 +08:00
|
|
|
- CVE-2017-7520: Pre-authentication remote crash/information disclosure for
|
|
|
|
|
clients. If clients use a HTTP proxy with NTLM authentication (i.e.
|
|
|
|
|
``--http-proxy <server> <port> [<authfile>|'auto'|'auto-nct'] ntlm2``),
|
|
|
|
|
a man-in-the-middle attacker between the client and the proxy can cause
|
|
|
|
|
the client to crash or disclose at most 96 bytes of stack memory. The
|
|
|
|
|
disclosed stack memory is likely to contain the proxy password. If the
|
|
|
|
|
proxy password is not reused, this is unlikely to compromise the security
|
|
|
|
|
of the OpenVPN tunnel itself. Clients who do not use the ``--http-proxy``
|
|
|
|
|
option with ntlm2 authentication are not affected.
|
|
|
|
|
|
|
|
|
|
- CVE-2017-7508: Fix remotely-triggerable ASSERT() on malformed IPv6 packet.
|
|
|
|
|
This can be used to remotely shutdown an openvpn server or client, if
|
|
|
|
|
IPv6 and ``--mssfix`` are enabled and the IPv6 networks used inside the VPN
|
|
|
|
|
are known.
|
|
|
|
|
|
|
|
|
|
- Fix null-pointer dereference when talking to a malicious http proxy
|
|
|
|
|
that returns a malformed ``Proxy-Authenticate:`` headers for digest auth.
|
|
|
|
|
|
|
|
|
|
- Fix overflow check for long ``--tls-cipher`` option
|
|
|
|
|
|
|
|
|
|
- Windows: Pass correct buffer size to ``GetModuleFileNameW()``
|
|
|
|
|
(OSTIF/Quarkslabs audit, finding 5.6)
|
|
|
|
|
|
|
|
|
|
|
Fix mbedtls fingerprint calculation
Commit 'Migrate to mbed TLS 2.x' (86d8cd68) introduced a bug in mbedtls
builds where we would calculate the certificate fingerprint over the
(too-short) 'to-be-signed' length of the certificate, rather than over the
certificate including the signature. Fix that.
The security impact of the incorrect calculation is very minimal; the last
few bytes (max 4, typically 4) are not verified by the fingerprint. We
expect no real-world impact, because users that used this feature before
will notice that it has suddenly stopped working, and users that didn't
will notice that connection setup fails.
Even if the user managed to somehow extract the incorrect hash (e.g. by
reading out the tls_digest_* env vars using a --tls-verify script), the
impact is miminal: the last 4 bytes must still be properly signed by the
CA, and typically contain extension fields, or the last bytes of the
public key (which are hard to choose). The most important bits of the
certificate were always checked: the version, serial, signature algorithm,
issuer, validity and subject.
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <1495285075-4957-1-git-send-email-steffan@karger.me>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14711.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
2017-05-20 20:57:55 +08:00
|
|
|
User-visible Changes
|
|
|
|
|
--------------------
|
2017-05-05 04:42:01 +08:00
|
|
|
- ``--verify-hash`` can now take an optional flag which changes the hashing
|
|
|
|
|
algorithm. It can be either SHA1 or SHA256. The default if not provided is
|
|
|
|
|
SHA1 to preserve backwards compatibility with existing configurations.
|
2017-06-20 01:44:00 +08:00
|
|
|
|
|
|
|
|
- Restrict the supported ``--x509-username-field`` extension fields to subjectAltName
|
2017-06-19 17:28:39 +08:00
|
|
|
and issuerAltName. Other extensions probably didn't work anyway, and would
|
|
|
|
|
cause OpenVPN to crash when a client connects.
|
2017-03-05 02:49:57 +08:00
|
|
|
|
2017-06-20 01:44:00 +08:00
|
|
|
|
Fix mbedtls fingerprint calculation
Commit 'Migrate to mbed TLS 2.x' (86d8cd68) introduced a bug in mbedtls
builds where we would calculate the certificate fingerprint over the
(too-short) 'to-be-signed' length of the certificate, rather than over the
certificate including the signature. Fix that.
The security impact of the incorrect calculation is very minimal; the last
few bytes (max 4, typically 4) are not verified by the fingerprint. We
expect no real-world impact, because users that used this feature before
will notice that it has suddenly stopped working, and users that didn't
will notice that connection setup fails.
Even if the user managed to somehow extract the incorrect hash (e.g. by
reading out the tls_digest_* env vars using a --tls-verify script), the
impact is miminal: the last 4 bytes must still be properly signed by the
CA, and typically contain extension fields, or the last bytes of the
public key (which are hard to choose). The most important bits of the
certificate were always checked: the version, serial, signature algorithm,
issuer, validity and subject.
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <1495285075-4957-1-git-send-email-steffan@karger.me>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14711.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
2017-05-20 20:57:55 +08:00
|
|
|
Bugfixes
|
|
|
|
|
--------
|
|
|
|
|
- Fix fingerprint calculation in mbed TLS builds. This means that mbed TLS users
|
2017-08-16 04:53:01 +08:00
|
|
|
of OpenVPN 2.4.0, v2.4.1 and v2.4.2 that rely on the values of the
|
2017-06-20 01:44:00 +08:00
|
|
|
``tls_digest_*`` env vars, or that use ``--verify-hash`` will have to change
|
Fix mbedtls fingerprint calculation
Commit 'Migrate to mbed TLS 2.x' (86d8cd68) introduced a bug in mbedtls
builds where we would calculate the certificate fingerprint over the
(too-short) 'to-be-signed' length of the certificate, rather than over the
certificate including the signature. Fix that.
The security impact of the incorrect calculation is very minimal; the last
few bytes (max 4, typically 4) are not verified by the fingerprint. We
expect no real-world impact, because users that used this feature before
will notice that it has suddenly stopped working, and users that didn't
will notice that connection setup fails.
Even if the user managed to somehow extract the incorrect hash (e.g. by
reading out the tls_digest_* env vars using a --tls-verify script), the
impact is miminal: the last 4 bytes must still be properly signed by the
CA, and typically contain extension fields, or the last bytes of the
public key (which are hard to choose). The most important bits of the
certificate were always checked: the version, serial, signature algorithm,
issuer, validity and subject.
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <1495285075-4957-1-git-send-email-steffan@karger.me>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14711.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
2017-05-20 20:57:55 +08:00
|
|
|
the fingerprint values they check against. The security impact of the
|
|
|
|
|
incorrect calculation is very minimal; the last few bytes (max 4, typically
|
|
|
|
|
4) are not verified by the fingerprint. We expect no real-world impact,
|
|
|
|
|
because users that used this feature before will notice that it has suddenly
|
|
|
|
|
stopped working, and users that didn't will notice that connection setup
|
|
|
|
|
fails if they specify correct fingerprints.
|
|
|
|
|
|
2017-06-20 01:44:00 +08:00
|
|
|
- Fix edge case with NCP when the server sends an empty PUSH_REPLY message
|
|
|
|
|
back, and the client would not initialize it's data channel crypto layer
|
|
|
|
|
properly (trac #903)
|
Fix mbedtls fingerprint calculation
Commit 'Migrate to mbed TLS 2.x' (86d8cd68) introduced a bug in mbedtls
builds where we would calculate the certificate fingerprint over the
(too-short) 'to-be-signed' length of the certificate, rather than over the
certificate including the signature. Fix that.
The security impact of the incorrect calculation is very minimal; the last
few bytes (max 4, typically 4) are not verified by the fingerprint. We
expect no real-world impact, because users that used this feature before
will notice that it has suddenly stopped working, and users that didn't
will notice that connection setup fails.
Even if the user managed to somehow extract the incorrect hash (e.g. by
reading out the tls_digest_* env vars using a --tls-verify script), the
impact is miminal: the last 4 bytes must still be properly signed by the
CA, and typically contain extension fields, or the last bytes of the
public key (which are hard to choose). The most important bits of the
certificate were always checked: the version, serial, signature algorithm,
issuer, validity and subject.
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <1495285075-4957-1-git-send-email-steffan@karger.me>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14711.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
2017-05-20 20:57:55 +08:00
|
|
|
|
2017-06-20 01:44:00 +08:00
|
|
|
- Fix SIGSEGV on unaligned buffer access on OpenBSD/Sparc64
|
|
|
|
|
|
|
|
|
|
- Fix TCP_NODELAY on OpenBSD
|
|
|
|
|
|
|
|
|
|
- Remove erroneous limitation on max number of args for ``--plugin``
|
|
|
|
|
|
|
|
|
|
- Fix NCP behaviour on TLS reconnect (Server would not send a proper
|
|
|
|
|
"cipher ..." message back to the client, leading to client and server
|
|
|
|
|
using different ciphers) (trac #887)
|
2017-05-07 19:01:18 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
Version 2.4.2
|
|
|
|
|
=============
|
|
|
|
|
|
|
|
|
|
Bugfixes
|
|
|
|
|
--------
|
2017-08-16 04:53:01 +08:00
|
|
|
- Fix memory leak introduced in OpenVPN 2.4.1: if ``--remote-cert-tls`` is
|
|
|
|
|
used, we leaked some memory on each TLS (re)negotiation.
|
2017-05-10 03:30:08 +08:00
|
|
|
|
2017-06-20 01:44:00 +08:00
|
|
|
|
2017-05-10 03:30:08 +08:00
|
|
|
Security
|
|
|
|
|
--------
|
2017-08-16 04:53:01 +08:00
|
|
|
- Fix a pre-authentication denial-of-service attack on both clients and
|
|
|
|
|
servers. By sending a too-large control packet, OpenVPN 2.4.0 or v2.4.1 can
|
|
|
|
|
be forced to hit an ASSERT() and stop the process. If ``--tls-auth`` or
|
|
|
|
|
``--tls-crypt`` is used, only attackers that have the ``--tls-auth`` or
|
|
|
|
|
``--tls-crypt`` key can mount an attack.
|
|
|
|
|
(OSTIF/Quarkslab audit finding 5.1, CVE-2017-7478)
|
2017-06-20 01:44:00 +08:00
|
|
|
|
2017-05-10 03:30:09 +08:00
|
|
|
- Fix an authenticated remote DoS vulnerability that could be triggered by
|
|
|
|
|
causing a packet id roll over. An attack is rather inefficient; a peer
|
|
|
|
|
would need to get us to send at least about 196 GB of data.
|
|
|
|
|
(OSTIF/Quarkslab audit finding 5.2, CVE-2017-7479)
|
2017-06-20 01:44:00 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
Version 2.4.1
|
|
|
|
|
=============
|
|
|
|
|
- ``--remote-cert-ku`` now only requires the certificate to have at least the
|
|
|
|
|
bits set of one of the values in the supplied list, instead of requiring an
|
|
|
|
|
exact match to one of the values in the list.
|
|
|
|
|
- ``--remote-cert-tls`` now only requires that a keyUsage is present in the
|
|
|
|
|
certificate, and leaves the verification of the value up to the crypto
|
|
|
|
|
library, which has more information (i.e. the key exchange method in use)
|
|
|
|
|
to verify that the keyUsage is correct.
|
|
|
|
|
- ``--ns-cert-type`` is deprecated. Use ``--remote-cert-tls`` instead.
|
|
|
|
|
The nsCertType x509 extension is very old, and barely used.
|
|
|
|
|
``--remote-cert-tls`` uses the far more common keyUsage and extendedKeyUsage
|
|
|
|
|
extension instead. Make sure your certificates carry these to be able to
|
|
|
|
|
use ``--remote-cert-tls``.
|
|
|
|
|
|
