2023-10-09 18:58:32 +08:00
Overview of changes in 2.7
==========================
2023-12-30 22:37:33 +08:00
Deprecated features
-------------------
2023-10-09 18:58:32 +08:00
`` secret `` support has been removed by default.
static key mode (non-TLS) is no longer considered "good and secure enough"
for today's requirements. Use TLS mode instead. If deploying a PKI CA
is considered "too complicated", using `` --peer-fingerprint `` makes
TLS mode about as easy as using `` --secret `` .
This mode can still be enabled by using
`` --allow-deprecated-insecure-static-crypto `` but will be removed in
OpenVPN 2.8.
2024-01-18 23:12:42 +08:00
NTLMv1 authentication support for HTTP proxies has been removed.
This is considered an insecure method of authentication that uses
obsolete crypto algorithms.
NTLMv2 support is still available, but will be removed in a future
release.
When configured to authenticate with NTLMv1 (`` ntlm `` keyword in
`` --http-proxy `` ) OpenVPN will try NTLMv2 instead.
2023-12-30 22:37:33 +08:00
2024-03-07 22:03:55 +08:00
`` persist-key `` option has been enabled by default.
All the keys will be kept in memory across restart.
2023-12-30 22:37:33 +08:00
2023-12-01 19:20:22 +08:00
Default for `` --topology `` changed to `` subnet ``
Previous releases used `` net30 `` as default. This only affects
configs with `` --dev tun `` and only IPv4. Note that this
changes the semantics of `` --ifconfig `` , so if you have manual
settings for that in your config but not set `` --topology ``
your config might fail to parse with the new version. Just adding
`` --topology net30 `` to the config should fix the problem.
By default `` --topology `` is pushed from server to client.
2020-10-09 19:54:53 +08:00
Overview of changes in 2.6
==========================
2022-11-30 21:31:54 +08:00
Project changes
---------------
We want to deprecate our old Trac bug tracking system.
Please report any issues with this release in GitHub
instead: https://github.com/OpenVPN/openvpn/issues
2020-10-09 19:54:53 +08:00
New features
------------
2021-09-08 06:31:25 +08:00
Support unlimited number of connection entries and remote entries
Add remote-count and remote-entry query via management
Selecting the remote host via the management interface
(management-query-remote) provides a restrictive user
experience as there is no easy way to tabulate all available
remote entries and show a list to the user to choose from.
Fix that.
Two new commands for querying the management interface are added:
(i) remote-entry-count : returns the number of remotes specified
in the config file. Example result:
10
END
(ii) remote-entry-get i [j]: returns the remote entry at index i
in the form index,host,port,protocol. Or, if j is present
all entries from index i to j-1 are returned, one per line.
Example result for i = 2:
2,ovpn.example.com,1194,udp
END
Example result for i = 2, j = 4
2,ovpn.example.com,1194,udp
3,ovpn.example.com,443,tcp-client
END
remote-entry-get all: returns all remote entries.
v2: use independent callback functions for the two commands
v3: return results as 0 or more lines terminated by END, as done
for all other similar commands. v1 was fashioned after
pkcs11-id-count and pkcs11-id-get which uses a format not
consistent with the rest of the management commands.
See also management-notes.txt
Signed-off-by: Selva Nair <selva.nair@gmail.com>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20210907223126.8440-1-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg22815.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
2021-09-08 06:31:24 +08:00
New management commands to enumerate and list remote entries
Use `` remote-entry-count `` and `` remote-entry-get ``
commands from the management interface to get the number of
remote entries and the entries themselves.
2020-10-09 19:54:53 +08:00
Keying Material Exporters (RFC 5705) based key generation
As part of the cipher negotiation OpenVPN will automatically prefer
the RFC5705 based key material generation to the current custom
OpenVPN PRF. This feature requires OpenSSL or mbed TLS 2.18+.
2021-03-05 22:13:52 +08:00
Compatibility with OpenSSL in FIPS mode
OpenVPN will now work with OpenSSL in FIPS mode. Note, no effort
has been made to check or implement all the
requirements/recommendation of FIPS 140-2. This just allows OpenVPN
to be run on a system that be configured OpenSSL in FIPS mode.
Require at least 100MB of mlock()-able memory if --mlock is used.
If --mlock is used, the amount of memory OpenVPN can use is guarded
by the RLIMIT_MEMLOCK value (see mlockall(2)). The OS default for this
is usually 64 Kbyte, which is enough for OpenVPN to initialize, but
as soon as the first TLS handshake comes it, OpenVPN will crash due
to "ouf of memory", and might even end up in a crash loop.
Steady-state OpenVPN requires between 8 MB and 30-50 MB (servers with
many concurrent clients) of memory. TLS renegotiation with EC keys
requires up to 90 MB of transient memory.
So: with this patch, we check if getrlimit() is available, and if yes,
log the amount of mlock'able memory. If the amount is below 100 MB,
which is an arbitrary value "large enough for most smaller deployments",
we try to increase the limits to 100 MB, and abort if this fails.
v2:
change arbitrary number to 100 MB, introduce #define for it
not only check but also increase with setrlimit()
uncrustify fixes
v3:
OpenSolaris has mlockall() and getrlimit(), but no RLIMIT_MEMLOCK -
make code conditional on HAVE_GETRLIMIT *and* RLIMIT_MEMLOCK
add Changes.rst entry
Trac: #1390
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Selva Nair <selva.nair@gmail.com>
Message-Id: <20210310124808.14741-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21657.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
2021-03-10 20:48:08 +08:00
`` mlock `` will now check if enough memlock-able memory has been reserved,
and if less than 100MB RAM are available, use setrlimit() to upgrade
the limit. See Trac #1390. Not available on OpenSolaris.
2021-03-21 22:33:53 +08:00
Certificate pinning/verify peer fingerprint
The `` --peer-fingerprint `` option has been introduced to give users an
easy to use alternative to the `` tls-verify `` for matching the
fingerprint of the peer. The option takes use a number of allowed
SHA256 certificate fingerprints.
2021-07-28 23:49:22 +08:00
See the man page section "Small OpenVPN setup with peer-fingerprint"
for a tutorial on how to use this feature. This is also available online
under https://github.com/openvpn/openvpn/blob/master/doc/man-sections/example-fingerprint.rst
2020-09-08 23:41:57 +08:00
TLS mode with self-signed certificates
When `` --peer-fingerprint `` is used, the `` --ca `` and `` --capath `` option
become optional. This allows for small OpenVPN setups without setting up
a PKI with Easy-RSA or similar software.
2021-04-07 23:49:51 +08:00
Deferred auth support for scripts
The `` --auth-user-pass-verify `` script supports now deferred authentication.
Pending auth support for plugins and scripts
Both auth plugin and script can now signal pending authentication to
the client when using deferred authentication. The new `` client-crresponse ``
script option and `` OPENVPN_PLUGIN_CLIENT_CRRESPONSE `` plugin function can
be used to parse a client response to a `` CR_TEXT `` two factor challenge.
See `` sample/sample-scripts/totpauth.py `` for an example.
Require at least 100MB of mlock()-able memory if --mlock is used.
If --mlock is used, the amount of memory OpenVPN can use is guarded
by the RLIMIT_MEMLOCK value (see mlockall(2)). The OS default for this
is usually 64 Kbyte, which is enough for OpenVPN to initialize, but
as soon as the first TLS handshake comes it, OpenVPN will crash due
to "ouf of memory", and might even end up in a crash loop.
Steady-state OpenVPN requires between 8 MB and 30-50 MB (servers with
many concurrent clients) of memory. TLS renegotiation with EC keys
requires up to 90 MB of transient memory.
So: with this patch, we check if getrlimit() is available, and if yes,
log the amount of mlock'able memory. If the amount is below 100 MB,
which is an arbitrary value "large enough for most smaller deployments",
we try to increase the limits to 100 MB, and abort if this fails.
v2:
change arbitrary number to 100 MB, introduce #define for it
not only check but also increase with setrlimit()
uncrustify fixes
v3:
OpenSolaris has mlockall() and getrlimit(), but no RLIMIT_MEMLOCK -
make code conditional on HAVE_GETRLIMIT *and* RLIMIT_MEMLOCK
add Changes.rst entry
Trac: #1390
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Selva Nair <selva.nair@gmail.com>
Message-Id: <20210310124808.14741-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21657.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
2021-03-10 20:48:08 +08:00
2021-09-08 15:26:06 +08:00
Compatibility mode (`` --compat-mode `` )
The modernisation of defaults can impact the compatibility of OpenVPN 2.6.0
with older peers. The options `` --compat-mode `` allows UIs to provide users
with an easy way to still connect to older servers.
2021-11-12 21:02:31 +08:00
OpenSSL 3.0 support
OpenSSL 3.0 has been added. Most of OpenSSL 3.0 changes are not user visible but
improve general compatibility with OpenSSL 3.0. `` --tls-cert-profile insecure ``
has been added to allow selecting the lowest OpenSSL security level (not
recommended, use only if you must). OpenSSL 3.0 no longer supports the Blowfish
(and other deprecated) algorithm by default and the new option `` --providers ``
allows loading the legacy provider to renable these algorithms.
2021-09-08 15:26:06 +08:00
2021-12-02 02:07:19 +08:00
Optional ciphers in `` --data-ciphers ``
Ciphers in `` --data-ciphers `` can now be prefixed with a `` ? `` to mark
those as optional and only use them if the SSL library supports them.
2022-01-02 00:25:23 +08:00
2022-02-12 08:33:31 +08:00
Improved `` --mssfix `` and `` --fragment `` calculation
The `` --mssfix `` and `` --fragment `` options now allow an optional :code: `mtu`
parameter to specify that different overhead for IPv4/IPv6 should taken into
account and the resulting size is specified as the total size of the VPN packets
including IP and UDP headers.
2022-01-02 00:25:23 +08:00
2022-05-05 21:03:48 +08:00
Cookie based handshake for UDP server
Instead of allocating a connection for each client on the initial packet
OpenVPN server will now use an HMAC based cookie as its session id. This
way the server can verify it on completing the handshake without keeping
state. This eliminates the amplification and resource exhaustion attacks.
For tls-crypt-v2 clients, this requires OpenVPN 2.6 clients or later
because the client needs to resend its client key on completing the hand
shake. The tls-crypt-v2 option allows controlling if older clients are
accepted.
2023-01-10 09:59:01 +08:00
By default the rate of initial packet responses is limited to 100 per 10s
interval to avoid OpenVPN servers being abused in reflection attacks
(see `` --connect-freq-initial `` ).
2022-08-05 17:37:03 +08:00
Data channel offloading with ovpn-dco
2.6.0+ implements support for data-channel offloading where the data packets
are directly processed and forwarded in kernel space thanks to the ovpn-dco
kernel module. The userspace openvpn program acts purely as a control plane
application. Note that DCO will use DATA_V2 packets in P2P mode, therefore,
this implies that peers must be running 2.6.0+ in order to have P2P-NCP
which brings DATA_V2 packet support.
2022-10-07 04:37:31 +08:00
Session timeout
It is now possible to terminate a session (or all) after a specified amount
of seconds has passed session commencement. This behaviour can be configured
using `` --session-timeout `` . This option can be configured on the server, on
the client or can also be pushed.
2022-09-17 21:48:32 +08:00
Inline auth username and password
Username and password can now be specified inline in the configuration file
2022-09-15 02:59:37 +08:00
within the <auth-user-pass></auth-user-pass> tags. If the password is
missing OpenVPN will prompt for input via stdin. This applies to inline'd
http-proxy-user-pass too.
2022-09-17 21:48:32 +08:00
2022-11-09 23:48:09 +08:00
Tun MTU can be pushed
The client can now also dynamically configure its MTU and the server
will try to push the client MTU when the client supports it. The
directive `` --tun-mtu-max `` has been introduced to increase the maximum
pushable MTU size (defaults to 1600).
2022-08-05 17:37:03 +08:00
Dynamic tls-crypt for secure soft_reset/session renegotiation
Currently we have only one slot for renegotiation of the session/keys.
If a replayed/faked packet is inserted by a malicous attacker, the
legimate peer cannot renegotiate anymore.
This commit introduces dynamic tls-crypt. When both peer support this
feature, both peer create a dynamic tls-crypt key using TLS EKM (export
key material) and will enforce using that key and tls-crypt for all
renegotiations. This also add an additional protection layer for
renegotiations to be taken over by an illegimate client, binding the
renegotiations tightly to the original session. Especially when 2FA,
webauth or similar authentication is used, many third party setup ignore
the need to secure renegotiation with an auth-token.
Since one of tls-crypt/tls-crypt-v2 purposes is to provide poor man's post
quantum crypto guarantees, we have to ensure that the dynamic key tls-crypt
key that replace the original tls-crypt key is as strong as the orginal key
to avoid problems if there is a weak RNG or TLS EKM produces weak keys. We
ensure this but XORing the original key with the key from TLS EKM. If
tls-crypt/tls-cryptv2 is not active, we use just the key generated by
TLS EKM. We also do not use hashing or anything else on the original key
before XOR to avoid any potential of a structure in the key or something
else that might weaken post-quantum use cases.
OpenVPN 2.x reserves the TM_ACTIVE session for renegotiations. When a
SOFT_RESET_V1 packet is received, the active TLS session is moved from
KS_PRIMARY to KS_SECONDARY. Here an attacker could theorectically send a
faked/replayed SOFT_RESET_V1 and first packet containing the TLS client
hello. If this happens, the session is blocked until the TLS
renegotiation attempt times out, blocking the legimitate client.
Using a dynamic tls-crypt key here blocks any SOFT_RESET_V1 (and following
packets) as replay and fake packets will not have a matching
authentication/encryption and will be discarded.
HARD_RESET packets that are from a reconnecting peer are instead put in the
TM_UNTRUSTED/KS_PRIMARY slot until they are sufficiently verified, so the
dynamic tls-crypt key is not used here. Replay/fake packets also do not
block the legimitate client.
This commit delays the purging of the original tls-crypt key data from
directly after passing it to crypto library to tls_wrap_free. We do this
to allow us mixing the new exported key with the original key.
To be able to generate the dynamic tls-cryptn key, we need the original
key, so deleting the key is not an option if we need it later again to
generate another key. Even when the client does not support secure
renegotiation, deleting the key is not an option since when the
reconnecting client or (especially in p2p mode with float) another client
does the reconnect, we might need to generate a dynamic tls-crypt key
again. Delaying the deletion of the key has also little effect as the
key is still present in the OpenSSL/mbed TLS structures in the tls_wrap
structure, so only the number of times the keys is in memory would be
reduced.
Patch v2: fix spellings of reneg and renegotiations.
Patch v3: expand comment to original_tlscrypt_keydata and commit message,
add Changes.rst
Patch v4: improve commit message, Changes.rst
Patch v5: fix spelling/grammar mistakes. Add more comments.
Patch v6: consistently calld this feature dynamic tls-crypt crypt. Note
this changes the export label and makes it incompatible with
previous patches.
Patch v7: also xor tls-auth key data into the dynamic tls-crypt key like
tls-crypt key data
Patch v8: Avoid triggering ASSERT added in v7 by properly setting keys.n = 2
when loading tls crypt v2 client keys. Add dyn-tls-crypt to
protocol options printout.
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Heiko Hund <heiko@ist.eigentlich.net>
Message-Id: <20230307150233.3551436-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg26341.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
2023-03-07 23:02:33 +08:00
Dynamic TLS Crypt
When both peers are OpenVPN 2.6.1+, OpenVPN will dynamically create
a tls-crypt key that is used for renegotiation. This ensure that only the
previously authenticated peer can do trigger renegotiation and complete
renegotiations.
2022-11-04 20:56:55 +08:00
Improved control channel packet size control (`` max-packet-size `` )
The size of control channel is no longer tied to
`` --link-mtu `` /`` --tun-mtu `` and can be set using `` --max-packet-size `` .
Sending large control channel frames is also optimised by allowing 6
outstanding packets instead of just 4. `` max-packet-size `` will also set
`` mssfix `` to try to limit data-channel packets as well.
2020-12-15 01:24:07 +08:00
Deprecated features
-------------------
`` inetd `` has been removed
This was a very limited and not-well-tested way to run OpenVPN, on TCP
and TAP mode only.
2021-03-22 17:16:21 +08:00
`` verify-hash `` has been deprecated
This option has very limited usefulness and should be replaced by either
a better `` --ca `` configuration or with a `` --tls-verify `` script.
2020-12-15 01:24:07 +08:00
2021-03-28 17:05:30 +08:00
`` secret `` has been deprecated
static key mode (non-TLS) is no longer considered "good and secure enough"
for today's requirements. Use TLS mode instead. If deploying a PKI CA
is considered "too complicated", using `` --peer-fingerprint `` makes
TLS mode about as easy as using `` --secret `` .
2021-05-20 23:11:47 +08:00
`` ncp-disable `` has been removed
This option mainly served a role as debug option when NCP was first
introduced. It should now no longer be necessary.
2021-09-14 03:29:29 +08:00
TLS 1.0 and 1.1 are deprecated
`` tls-version-min `` is set to 1.2 by default. OpenVPN 2.6.0 defaults
to a minimum TLS version of 1.2 as TLS 1.0 and 1.1 should be generally
avoided. Note that OpenVPN versions older than 2.3.7 use TLS 1.0 only.
2021-09-04 17:56:26 +08:00
`` --cipher `` argument is no longer appended to `` --data-ciphers ``
by default. Data cipher negotiation has been introduced in 2.4.0
and been significantly improved in 2.5.0. The implicit fallback
to the cipher specified in `` --cipher `` has been removed.
Effectively, `` --cipher `` is a no-op in TLS mode now, and will
only have an effect in pre-shared-key mode (`` --secret `` ).
From now on `` --cipher `` should not be used in new configurations
for TLS mode.
Should backwards compatibility with older OpenVPN peers be
required, please see the `` --compat-mode `` instead.
2021-11-07 17:01:47 +08:00
`` --prng `` has beeen removed
OpenVPN used to implement its own PRNG based on a hash. However implementing
a PRNG is better left to a crypto library. So we use the PRNG
mbed TLS or OpenSSL now.
2023-02-01 21:52:21 +08:00
`` --keysize `` has been removed
The `` --keysize `` option was only useful to change the key length when using the
BF, CAST6 or RC2 ciphers. For all other ciphers the key size is fixed with the
chosen cipher. As OpenVPN v2.6 no longer supports any of these variable length
ciphers, this option was removed as well to avoid confusion.
2021-09-04 17:56:26 +08:00
2021-09-04 17:56:25 +08:00
Compression no longer enabled by default
Unless an explicit compression option is specified in the configuration,
`` --allow-compression `` defaults to `` no `` in OpeNVPN 2.6.0.
By default, OpenVPN 2.5 still allowed a server to enable compression by
pushing compression related options.
2021-08-28 03:00:14 +08:00
PF (Packet Filtering) support has been removed
The built-in PF functionality has been removed from the code base. This
feature wasn't really easy to use and was long unmaintained.
This implies that also `` --management-client-pf `` and any other compile
time or run time related option do not exist any longer.
2023-01-11 21:44:39 +08:00
Option conflict checking is being deprecated and phased out
The static option checking (OCC) is no longer useful in typical setups
that negotiate most connection parameters. The `` --opt-verify `` and
`` --occ-disable `` options are deprecated, and the configure option
`` --enable-strict-options `` has been removed. Logging of mismatched
options has been moved to debug logging (verb 7).
2021-08-19 05:33:54 +08:00
User-visible Changes
--------------------
- CHACHA20-POLY1305 is included in the default of `` --data-ciphers `` when available.
2021-12-06 09:00:07 +08:00
- Option `` --prng `` is ignored as we rely on the SSL library random number generator.
- Option `` --nobind `` is default when `` --client `` or `` --pull `` is used in the configuration
2022-01-02 00:25:26 +08:00
- :code: `link_mtu` parameter is removed from environment or replaced with 0 when scripts are
called with parameters. This parameter is unreliable and no longer internally calculated.
2021-08-19 05:33:54 +08:00
2022-11-04 20:56:55 +08:00
- control channel packet maximum size is no longer influenced by
`` --link-mtu `` /`` --tun-mtu `` and must be set by `` --max-packet-size `` now.
The default is 1250 for the control channel size.
2022-10-16 23:49:53 +08:00
- In point-to-point OpenVPN setups (no `` --server `` ), using
`` --explict-exit-notiy `` on one end would terminate the other side at
session end. This is considered a no longer useful default and has
been changed to "restart on reception of explicit-exit-notify message".
If the old behaviour is still desired, `` --remap-usr1 SIGTERM `` can be used.
FreeBSD: for topology subnet, put tun interface into IFF_BROADCAST mode
For reasons unknown, OpenVPN has always put FreeBSD tun(4) interfaces
into point-to-point mode (IFF_POINTOPOINT), which means "local and
remote address, no on-link subnet".
"--topology subnet" was emulated by adding a subnet-route to the "remote"
(which was just picking a free address from the subnet).
This works well enough for classic tun(4) interfaces that have no
next-hop resolution, and routes pointing to "that fake remote" only
(because all routing is done inside OpenVPN and it does not matter how
packets get there) - but for ovpn(4) interfaces, it breaks iroute setup,
where the route next-hop must be an on-link address.
Thus, change interface to IFF_BROADCAST mode, and get rid of all the
special code needed to "fake" subnet mode.
Tested with tun(4) and ovpn(4) on FreeBSD 14, client and server, and
with tun(4) on FreeBSD 12 and 7.4
To actually work with ovpn(4) / FreeBSD DCO, a followup patch for
kernel ovpn(4) and OpenVPN dco_freebsd.c is needed.
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Kristof Provost <kprovost@netgate.com>
Message-Id: <20221012145915.25810-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg25396.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
2022-10-12 22:59:14 +08:00
- FreeBSD tun interfaces with `` --topology subnet `` are now put into real
subnet mode (IFF_BROADCAST instead of IFF_POINTOPOINT) - this might upset
software that enumerates interfaces, looking for "broadcast capable?" and
expecting certain results. Normal uses should not see any difference.
2022-11-29 19:30:31 +08:00
- The default configurations will no longer allow connections to OpenVPN 2.3.x
peer or earlier, use the new `` --compat-mode `` option if you need
compatibility with older versions. See the manual page on the
`` --compat-mode `` for details.
2023-03-01 21:53:53 +08:00
- The `` client-pending-auth `` management command now requires also the
key id. The management version has been changed to 5 to indicate this change.
2023-03-24 01:05:59 +08:00
- (OpenVPN 2.6.2) A client will now refuse a connection if pushed compression
settings will contradict the setting of allow-compression as this almost
always results in a non-working connection.
2022-11-29 19:30:31 +08:00
Common errors with OpenSSL 3.0 and OpenVPN 2.6
----------------------------------------------
Both OpenVPN 2.6 and OpenSSL 3.0 tighten the security considerable, so some
configuration will no longer work. This section will cover the most common
causes and error message we have seen and explain their reason and temporary
workarounds. You should fix the underlying problems as soon as possible since
these workaround are not secure and will eventually stop working in a future
update.
- weak SHA1 or MD5 signature on certificates
This will happen on either loading of certificates or on connection
to a server::
OpenSSL: error:0A00018E:SSL routines::ca md too weak
Cannot load certificate file cert.crt
Exiting due to fatal error
OpenSSL 3.0 no longer allows weak signatures on certificates. You can
downgrade your security to allow them by using `` --tls-cert-profile insecure ``
but should replace/regenerate these certificates as soon as possible.
- 1024 bit RSA certificates, 1024 bit DH parameters, other weak keys
This happens if you use private keys or other cryptographic material that
does not meet today's cryptographic standards anymore. Messages are similar
to::
OpenSSL: error:0A00018F:SSL routines::ee key too small
OpenSSL: error:1408518A:SSL routines:ssl3_ctx_ctrl:dh key too small
DH parameters (`` --dh `` ) can be regenerated with `` openssl dhparam 2048 `` .
For other cryptographic keys, these keys and certificates need to be
regenerated. TLS Security level can be temporarily lowered with
`` --tls-cert-profile legacy `` or even `` --tls-cert-profile insecure `` .
- Connecting to a OpenVPN 2.3.x server or allowing OpenVPN 2.3.x or earlier
clients
This will normally result in messages like::
OPTIONS ERROR: failed to negotiate cipher with server. Add the server's cipher ('AES-128-CBC') to --data-ciphers (currently 'AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305') if you want to connect to this server.
or
client/127.0.0.1:49954 SENT CONTROL [client]: 'AUTH_FAILED,Data channel cipher negotiation failed (no shared cipher)' (status=1)
You can manually add the missing cipher to the `` --data-ciphers `` . The
standard ciphers should be included as well, e.g.
`` --data-ciphers AES-256-GCM:AES-128-GCM:?Chacha20-Poly1305:?AES-128-CBC `` .
You can also use the `` --compat-mode `` option. Note that these message may
also indicate other cipher configuration problems. See the data channel
cipher negotiation manual section for more details. (Available online under
https://github.com/OpenVPN/openvpn/blob/master/doc/man-sections/cipher-negotiation.rst)
- Use of a legacy or deprecated cipher (e.g. 64bit block ciphers)
OpenSSL 3.0 no longer supports a number of insecure and outdated ciphers in
its default configuration. Some of these ciphers are known to be vulnerable (SWEET32 attack).
This will typically manifest itself in messages like::
OpenSSL: error:0308010C:digital envelope routines::unsupported
Cipher algorithm 'BF-CBC' not found
Unsupported cipher in --data-ciphers: BF-CBC
If your OpenSSL distribution comes with the legacy provider (see
also `` man OSSL_PROVIDER-legacy `` ), you can load it with
`` --providers legacy default `` . This will re-enable the old algorithms.
- OpenVPN version not supporting TLS 1.2 or later
The default in OpenVPN 2.6 and also in many distributions is now TLS 1.2 or
later. Connecting to a peer that does not support this will results in
messages like::
TLS error: Unsupported protocol. This typically indicates that client and
server have no common TLS version enabled. This can be caused by mismatched
tls-version-min and tls-version-max options on client and server. If your
OpenVPN client is between v2.3.6 and v2.3.2 try adding tls-version-min 1.0
to the client configuration to use TLS 1.0+ instead of TLS 1.0 only
OpenSSL: error:0A000102:SSL routines::unsupported protocol
This can be an OpenVPN 2.3.6 or earlier version. `` compat-version 2.3.0 `` will
enable TLS 1.0 support if supported by the OpenSSL distribution. Note that
on some Linux distributions enabling TLS 1.1 or 1.0 is not possible.
2022-10-16 23:49:53 +08:00
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
2020-07-17 21:47:38 +08:00
The option `` ncp-ciphers `` has been renamed to `` data-ciphers `` .
The old name is still accepted. The change in name signals that
`` data-ciphers `` is the preferred way to configure data channel
ciphers and the data prefix is chosen to avoid the ambiguity that
exists with `` --cipher `` for the data cipher and `` tls-cipher ``
for the TLS ciphers.
2020-07-09 18:15:56 +08:00
OpenVPN clients will now signal all supported ciphers from the
2020-07-17 21:47:38 +08:00
`` data-ciphers `` option to the server via `` IV_CIPHERS `` . OpenVPN
servers will select the first common cipher from the `` data-ciphers ``
2020-07-09 18:15:56 +08:00
list instead of blindly pushing the first cipher of the list. This
allows to use a configuration like
2020-07-17 21:47:38 +08:00
`` data-ciphers ChaCha20-Poly1305:AES-256-GCM `` on the server that
2020-07-09 18:15:56 +08:00
prefers ChaCha20-Poly1305 but uses it only if the client supports it.
2020-08-10 17:00:32 +08:00
See the data channel negotiation section in the manual for more details.
Removal of BF-CBC support in default configuration:
By default OpenVPN 2.5 will only accept AES-256-GCM and AES-128-GCM as
data ciphers. OpenVPN 2.4 allows AES-256-GCM,AES-128-GCM and BF-CBC when
2020-08-15 20:05:21 +08:00
no --cipher and --ncp-ciphers options are present. Accepting BF-CBC can be
2020-08-10 17:00:32 +08:00
enabled by adding
data-ciphers AES-256-GCM:AES-128-GCM:BF-CBC
and when you need to support very old peers also
data-ciphers-fallback BF-CBC
To offer backwards compatibility with older configs an *explicit*
cipher BF-CBC
in the configuration will be automatically translated into adding BF-CBC
to the data-ciphers option and setting data-ciphers-fallback to BF-CBC
(as in the example commands above). We strongly recommend to switching
away from BF-CBC to a more secure cipher.
2020-07-15 17:01:05 +08:00
Asynchronous (deferred) authentication support for auth-pam plugin.
See src/plugins/auth-pam/README.auth-pam for details.
2020-07-20 22:27:03 +08:00
Deferred client-connect
The `` --client-connect `` option and the connect plugin API allow
asynchronous/deferred return of the configuration file in the same way
as the auth-plugin.
2020-07-26 07:48:03 +08:00
Faster connection setup
A client will signal in the `` IV_PROTO `` variable that it is in pull
mode. This allows the server to push the configuration options to
the client without waiting for a `` PULL_REQUEST `` message. The feature
is automatically enabled if both client and server support it and
significantly reduces the connection setup time by avoiding one
extra packet round-trip and 1s of internal event delays.
2020-08-12 18:08:21 +08:00
Netlink support
On Linux, if configured without `` --enable-iproute2 `` , configuring IP
addresses and adding/removing routes is now done via the netlink(3)
kernel interface. This is much faster than calling `` ifconfig `` or
`` route `` and also enables OpenVPN to run with less privileges.
If configured with --enable-iproute2, the `` ip `` command is used
(as in 2.4). Support for `` ifconfig `` and `` route `` is gone.
Wintun support
On Windows, OpenVPN can now use `` wintun `` devices. They are faster
than the traditional `` tap9 `` tun/tap devices, but do not provide
`` --dev tap `` mode - so the official installers contain both. To use
a wintun device, add `` --windows-driver wintun `` to your config
(and use of the interactive service is required as wintun needs
SYSTEM privileges to enable access).
IPv6-only operation
It is now possible to have only IPv6 addresses inside the VPN tunnel,
and IPv6-only address pools (2.4 always required IPv4 config/pools
and IPv6 was the "optional extra").
Improved Windows 10 detection
Correctly log OS on Windows 10 now.
Linux VRF support
Using the new `` --bind-dev `` option, the OpenVPN outside socket can
now be put into a Linux VRF. See the "Virtual Routing and Forwarding"
documentation in the man page.
TLS 1.3 support
TLS 1.3 support has been added to OpenVPN. Currently, this requires
OpenSSL 1.1.1+.
2020-08-15 20:05:21 +08:00
The options `` --tls-ciphersuites `` and `` --tls-groups `` have been
2020-08-12 18:08:21 +08:00
added to fine tune TLS protocol options. Most of the improvements
were also backported to OpenVPN 2.4 as part of the maintainance
releases.
Support setting DHCP search domain
A new option `` --dhcp-option DOMAIN-SEARCH my.example.com `` has been
defined, and Windows support for it is implemented (tun/tap only, no
wintun support yet). Other platforms need to support this via `` --up ``
script (Linux) or GUI (OSX/Tunnelblick).
2020-08-15 20:05:21 +08:00
per-client changing of `` --data-ciphers `` or `` data-ciphers-fallback ``
2020-08-12 18:08:21 +08:00
from client-connect script/dir (NOTE: this only changes preference of
ciphers for NCP, but can not override what the client announces as
"willing to accept")
Handle setting of tun/tap interface MTU on Windows
If IPv6 is in use, MTU must be >= 1280 (Windows enforces IETF requirements)
Add support for OpenSSL engines to access private key material (like TPM).
HMAC based auth-token support
The `` --auth-gen-token `` support has been improved and now generates HMAC
based user token. If the optional `` --auth-gen-token-secret `` option is
used clients will be able to seamlessly reconnect to a different server
using the same secret file or to the same server after a server restart.
Improved support for pending authentication
The protocol has been enhanced to be able to signal that
the authentication should use a secondary authentication
via web (like SAML) or a two factor authentication without
disconnecting the OpenVPN session with AUTH_FAILED. The
session will instead be stay in a authenticated state and
wait for the second factor authentication to complete.
This feature currently requires usage of the managent interface
on both client and server side. See the `management-notes.txt`
`` client-pending-auth `` and `` cr-response `` commands for more
details.
VLAN support
OpenVPN servers in TAP mode can now use 802.1q tagged VLANs
on the TAP interface to separate clients into different groups
that can then be handled differently (different subnets / DHCP,
firewall zones, ...) further down the network. See the new
options `` --vlan-tagging `` , `` --vlan-accept `` , `` --vlan-pvid `` .
802.1q tagging on the client side TAP interface is not handled
today (= tags are just forwarded transparently to the server).
Support building of .msi installers for Windows
Allow unicode search string in `` --cryptoapicert `` option (Windows)
Support IPv4 configs with /31 netmasks now
(By no longer trying to configure `` broadcast x.x.x.x'' in
ifconfig calls, /31 support "just works")
New option `` --block-ipv6 `` to reject all IPv6 packets (ICMPv6)
this is useful if the VPN service has no IPv6, but the clients
might have (LAN), to avoid client connections to IPv6-enabled
servers leaking "around" the IPv4-only VPN.
`` --ifconfig-ipv6 `` and `` --ifconfig-ipv6-push `` will now accept
hostnames and do a DNS lookup to get the IPv6 address to use
2020-07-09 18:15:56 +08:00
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.
2020-07-23 23:59:37 +08:00
- `` inetd `` has been deprecated
This is a very limited and not-well-tested way to run OpenVPN, on TCP
and TAP mode only, which complicates the code quite a bit for little gain.
To be removed in OpenVPN 2.6 (unless users protest).
2020-07-18 01:15:44 +08:00
- `` no-iv `` has been removed
This option was made into a NOOP option with OpenVPN 2.4. This has now
been completely removed.
2018-10-08 06:30:34 +08:00
2020-07-20 19:30:10 +08:00
- `` --client-cert-not-required `` has been removed
This option will now cause server configurations to not start. Use
`` --verify-client-cert none `` instead.
2020-07-20 19:51:56 +08:00
- `` --ifconfig-pool-linear `` has been removed
2020-08-12 18:08:21 +08:00
This option is removed. Use `` --topology p2p `` or `` --topology subnet ``
instead.
- `` --compress xxx `` is considered risky and is warned against, see below.
- `` --key-method 1 `` has been removed
2020-07-20 19:51:56 +08:00
2020-07-20 01:34:32 +08:00
User-visible Changes
--------------------
- If multiple connect handlers are used (client-connect, ccd, connect
plugin) and one of the handler succeeds but a subsequent fails, the
client-disconnect-script is now called immediately. Previously it
was called, when the VPN session was terminated.
2020-07-17 21:47:32 +08:00
- Support for building with OpenSSL 1.0.1 has been removed. The minimum
supported OpenSSL version is now 1.0.2.
2020-07-26 07:48:03 +08:00
- The GET_CONFIG management state is omitted if the server pushes
the client configuration almost immediately as result of the
faster connection setup feature.
2020-08-15 20:05:21 +08:00
- `` --compress `` is nowadays considered risky, because attacks exist
2020-08-12 18:08:21 +08:00
leveraging compression-inside-crypto to reveal plaintext (VORACLE). So
2020-08-15 20:05:21 +08:00
by default, `` --compress xxx `` will now accept incoming compressed
2020-08-12 18:08:21 +08:00
packets (for compatibility with peers that have not been upgraded yet),
but will not use compression outgoing packets. This can be controlled with
the new option `` --allow-compression yes|no|asym `` .
- Stop changing `` --txlen `` aways from OS defaults unless explicitly specified
in config file. OS defaults nowadays are actually larger then what we used
to configure, so our defaults sometimes caused packet drops = bad performance.
- remove `` --writepid `` pid file on exit now
- plugin-auth-pam now logs via OpenVPN logging method, no longer to stderr
(this means you'll have log messages in syslog or openvpn log file now)
- use ISO 8601 time format for file based logging now (YYYY-MM-DD hh:mm:dd)
(syslog is not affected, nor is `` --machine-readable-output `` )
- `` --clr-verify `` now loads all CRLs if more than one CRL is in the same
file (OpenSSL backend only, mbedTLS always did that)
- when `` --auth-user-pass file `` has no password, and the management interface
is active, query management interface (instead of trying console query,
which does not work on windows)
- skip expired certificates in Windows certificate store (`` --cryptoapicert `` )
- `` --socks-proxy `` + `` --proto udp* `` will now allways use IPv4, even if
IPv6 is requested and available. Our SOCKS code does not handle IPv6+UDP,
and before that change it would just fail in non-obvious ways.
- TCP listen() backlog queue is now set to 32 - this helps TCP servers that
receive lots of "invalid" connects by TCP port scanners
- do no longer print OCC warnings ("option mismatch") about `` key-method `` ,
`` keydir `` , `` tls-auth `` and `` cipher `` - these are either gone now, or
negotiated, and the warnings do not serve a useful purpose.
- `` dhcp-option DNS `` and `` dhcp-option DNS6 `` are now treated identically
(= both accept an IPv4 or IPv6 address for the nameserver)
Maintainer-visible changes
--------------------------
- the man page is now in maintained in .rst format, so building the openvpn.8
manpage from a git checkout now requires python-docutils (if this is missing,
the manpage will not be built - which is not considered an error generally,
but for package builders or `` make distcheck `` it is). Release tarballs
contain the openvpn.8 file, so unless some .rst is changed, doc-utils are
not needed for building.
- OCC support can no longer be disabled
- AEAD support is now required in the crypto library
- `` --disable-server `` has been removed from configure (so it is no longer
possible to build a client-/p2p-only OpenVPN binary) - the saving in code
size no longer outweighs the extra maintenance effort.
- `` --enable-iproute2 `` will disable netlink(3) support, so maybe remove
that from package building configs (see above)
- support building with MSVC 2019
- cmocka based unit tests are now only run if cmocka is installed externally
(2.4 used to ship a local git submodule which was painful to maintain)
- `` --disable-crypto `` configure option has been removed. OpenVPN is now always
built with crypto support, which makes the code much easier to maintain.
This does not affect `` --cipher none `` to do a tunnel without encryption.
- `` --disable-multi `` configure option has been removed
2020-07-17 21:47:32 +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
2024-03-08 22:01:12 +08:00
the authentication result is ready, instead of waiting for 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 `` .
