This patch also refactors the if condition that checks the result of
the authentication since that has become quite unreadable. It renames
s1/s2 and extracts some parts of the condition into individual variables
to make the condition better understandle
Patch v2: add refactoring of the if condition
Patch v4: fix documentation not mentioning method as 2nd line
Patch v5: fix deferred auth used by both plugin and script not working
Patch v6: Add missing async inotify for script deferred auth
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Tested-by: Antonio Quartulli <antonio@openvpn.net>
Acked-by: Antonio Quartulli <antonio@openvpn.net>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20210407154951.13330-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg22072.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
The non-TLS mode is a relict from OpenVPN 1.x or 2.0. When TLS mode was
introduced the advantages of TLS over non-TLS were small but TLS mode
evolved to include a lot more features (NCP, multipeer, AEAD ciphers to
name a few).
Today VPN setups that use --secret are mainly used because this mode is
easier to setup and does not require setting up a PKI. This shortcoming
of TLS mode should be addressed now with the peer-fingerprint option.
The primary reason to deprecate --secret is that it is not secure enough
anymore for modern environments. This mode uses a fixed pre-shared key and
no session keys. Thus, no forward secrecy is possible, which means that
any captured VPN traffic can be decrypted later should the --secret key
get into the wrong hands. The cryptography overall used here was okay
when --secret was introduced but is not acceptable by today's standard
anymore.
Finally, modern hardware-accelerated crypto modes like AES-GCM can only
be used in TLS mode (due to IV requirements).
Patch V2: Improve commit message
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20210328090530.10653-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21868.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Despite trying to figure out with multiple people what the use case for
this option is, we could not come up with a good one. Checking that only
a specific CA is used can be also done by only using that CA in the --ca
directive.
Although it feels a bit strange to deprecate the option after improving
it with peer-fingerprint patches, all the improvements are needed for
--peer-fingerprint and making them specify to --peer-fingerprint would
have added more (unecessary) changes.
Patch v3: rebased on v3 version of other patches.
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Antonio Quartulli <antonio@openvpn.net>
Message-Id: <20210322091621.7864-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21779.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Also remove the static key setup example as it is less secure and we
want to avoid it for new setups as we want to slowly deprecate these.
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Antonio Quartulli <antonio@openvpn.net>
Message-Id: <20200908154157.13809-5-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20904.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
This option allows to pin one or more more peer certificates. It also
prepares for doing TLS authentication without a CA and just
self-signed certificates.
Patch V2: Allow peer-fingerprint to be specified multiple times
to allow multiple peers without needing to use inline
syntax. (e.g. on command line).
Patch V3: rebase on v3 of 1/4, reword message of verify-hash and
peer-fingerpring incompatibility
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Antonio Quartulli <antonio@openvpn.net>
Message-Id: <20210321143353.2677-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/search?l=mid&q=20210321143353.2677-1-arne@rfc2549.org
Signed-off-by: Gert Doering <gert@greenie.muc.de>
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>
This moves from using our own copy of the TLS1 PRF function to using
TLS library provided function where possible. This includes currently
OpenSSL 1.1.0+ and mbed TLS 2.18+.
For the libraries where it is not possible to use the library's own
function, we still use our own implementation. mbed TLS will continue
to use our own old PRF function while for OpenSSL we will use a
adapted version from OpenSSL 1.0.2t code. The version allows to be
used in a FIPS enabled environment.
The old OpenSSL and mbed TLS implementation could have shared some
more code but as we will eventually drop support for older TLS
libraries, the separation makes it easier it remove that code
invdidually.
In FIPS mode MD5 is normally forbidden, the TLS1 PRF1 function we
use, makes uses of MD5, which in the past has caused OpenVPN to segfault.
The new implementation for OpenSSL version of our custom implementation
has added the special flags that tell OpenSSL that this specific use
of MD5 is allowed in FIPS mode.
No FIPS conformitiy testing etc has been done, this is only about
allowing OpenVPN on a system where FIPS mode has been enabled system
wide (e.g. on RHEL derivates).
Patch v4: Handle the unlikely case that PRF generation fails. More
formatting
fixes.
Patch v5: v4 with the formatting fixes actually commited. sigh.
Patch v6: More formatting fixes, make OpenSSL fucntion return bool instead
of int.
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Antonio Quartulli <antonio@openvpn.net>
Message-Id: <20210305141352.21847-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21612.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
This code is from another time and has almost no relevance today.
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20201214172407.30451-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21360.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
OpenVPN currently uses its own (based on TLS 1.0) key derivation
mechanism to generate the 256 bytes key data in key2 struct that
are then used used to generate encryption/hmac/iv vectors. While
this mechanism is still secure, it is not state of the art.
Instead of modernising our own approach, this commit implements
key derivation using the Keying Material Exporters API introduced
by RFC 5705.
We also use an opportunistic approach of negotiating the use of
EKM (exported key material) through an IV_PROTO flag and prefer
EKM to our own PRF if both client and server support it. The
use of EKM is pushed to the client as part of NCP as
key-derivation tls-ekm.
We still exchange the random data (112 bytes from client to server
and 64 byte from server to client) for the OpenVPN PRF but
do not use it. Removing that exchange would break the handshake
and make a key-method 3 or similar necessary.
As a side effect, this makes a little bit easier to have a FIPS compatible
version of OpenVPN since we do not rely on calling MD5 anymore.
Side note: this commit breaks the (not yet merged) WolfSSL support as it
claims to support EKM in the OpenSSL compat API but always returns an error
if you try to use it.
Patch v2: rebase/change to V2 of EKM refactoring
Patch v3: add Changes.rst
Patch v4: Rebase on master.
Patch v5: Refuse internal label to be used with --keying-material-exporter,
polishing/fixes suggested by Steffan integrated
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Steffan Karger <steffan.karger@foxcrypto.com>
Message-Id: <20201009115453.4279-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21187.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
This adds a section in the man page that details the various behaviour
of older client/servers when using OpenVPN 2.5.
Patch V2: Include grammar/spelling fixes from
Richard Bonhomme <tincanteksup@gmail.com>
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20200810090032.4220-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20660.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Signed-off-by: David Sommerseth <davids@openvpn.net>
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Patch V5: Fix typos, clarify man page section about deferred client-connect
script. Add section to Changes.rst
Patch V6: Convert manpage to rst
It also incorporates suggested changes from Richard Bonhomme
<tincanteksup@gmail.com> [0]
[0] Message-ID: <82c2d70f-e2f9-f810-2c55-788358a0cb08@gmail.com>
URL:
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20331.h
tml
Patch V7: Re-include the changes of Changes.rst and openvpn-plugin.h
Clarify some parts of the documentation.
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20200720142703.3324-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20511.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
The change in name signals that data-ciphers is the preferred way to
configure data channel (and not --cipher). The data prefix is chosen
to avoid ambiguity and make it distinct from tls-cipher for the TLS
ciphers.
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Steffan Karger <steffan.karger@foxcrypto.com>
Message-Id: <20200717134739.21168-8-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20444.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
The introduction of IV_PROTO_REQUEST_PUSH (c290df55) sometimes causes the
server to reply before we setup the push timer. The push reply will then
clear a timer that has not been setup yet. We then start sending push
request after we have gone through the whole initialisation already.
This patch also clears the connestion_established timer that sets up the
push request timer. This lead to the
management_set_state(management, OPENVPN_STATE_GET_CONFIG, ...)
function not being called. But to display "waiting for configuration..." or
sending a "getting config state" after "initialisation" does not make sense
anyway.
Also add the IV_PROTO_REQUEST_PUSH feature as new feature in Changes.rst
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20200725234803.22058-2-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20589.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
This is a corner case of a corner case option. It only works with tcp,
tap and needs special configuration.
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20200723155937.1867-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20554.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
This removes support for the --client-cert-not-required option. To
avoid starting a server with this option just ignored, which would make
it impossible for existing clients to connect it will exit with
instructions to replace this option with --verify-client-cert none.
Signed-off-by: David Sommerseth <davids@openvpn.net>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20200720113010.10450-1-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20502.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
This option has been deprecated since OpenVPN 2.1 and it has been
highlighted in the documentation and log files since OpenVPN 2.4.4.
Signed-off-by: David Sommerseth <davids@openvpn.net>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20200720115156.13322-1-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20504.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
OpenSSL 1.0.1 was supported until 2016-12-31. Rhel6/Centos6 still
use this version but considering that RHEL7 and RHEL8 are already
out, these versions can also stay with OpenVPN 2.4.
All the supported Debian based distributions also come with at
least 1.0.2.
We (accidently) unconditionally compiled some key exporter code on
OpenSSL 1.0.2+ without problems. So always compile the whole
key exporter feature for OpenSSL.
This also allows the tls groups commit to be applied without
adding ifdefs to disable that functionality on OpenSSL 1.0.1
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Steffan Karger <steffan.karger@foxcrypto.com>
Message-Id: <20200717134739.21168-2-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20441.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
This state is used to handle a corner case when multiple connect
handlers are active and one of them fails. Unfortunately, this state
complicates the state machine a bit without a good benefit.
Current behaviour:
First/all connect handler(s) fail:
- client disconnect handler is not called at all
At least one connect handler succeeds but a subsequent handler fails:
- client disconect is called when we actually
disconnect the client (a few seconds later, max tls timeout)
All connect handlers suceed:
- client disconect is called when we actually
disconnect the client
This patches changes the behaviour in the second to immediately
call disconnect_handler in this case.
This simplifies the logic that already caused a bug and the
behaviour change is very little and affects only a pretty
exotic corner case.
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20200719173436.16431-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20482.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
This finializes the depreacation started in OpenVPN 2.4, where --no-iv
was made into a NOOP option.
Signed-off-by: David Sommerseth <davids@openvpn.net>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20200717171544.21632-1-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20460.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
If OpenVPN signals deferred authentication support (by setting
the internal environment variables "auth_control_file" and
"deferred_auth_pam"), do not wait for PAM stack to finish. Instead,
the privileged PAM process returns RESPONSE_DEFER via the control
socket, which gets turned into OPENVPN_PLUGIN_FUNC_DEFERRED towards
openvpn.
The PAM process will then fork() and handle all the PAM auth in
the new process, signalling success/failure back by means of the
auth_control_file (forking twice, to simplify wait() handling).
With the extra fork(), multiple deferred authentications can run at
the same time - otherwise the first one would block the next auth
call (because the child would not be ready again to read from the
control socket).
Lightly tested on Linux.
Signed-off-by: Gert Doering <gert@greenie.muc.de>
--
v2:
- only do deferred auth if "deferred_auth_pam" is set (env)
- put deferred auth logic into do_deferred_pam_auth()
- line-wrap lines where needed
- close "background end" of socketpair in deferred auth process
- remove leftover /* plugin_log() */ lines from initial testing
- tested over a few hundred "15s delayed" authentication cycles
v3:
- uncrustify new code
- do not abort background process if do_deferred_pam_auth() fails
(this can only happen if fork() fails, which is assumed to be
temporary, or if something is wrong with the socketpair which we
should notice on the next read()) --> change do_deferred_pam_auth()
to "void"
- add documentation to README.auth-pam and Changes.rst
Acked-by: Selva Nair <selva.nair@gmail.com>
Message-Id: <20200715090105.22296-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20361.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
To allow rejecting incoming connections very early in the handshake,
add a --tls-crypt-v2-verify option that allows administators to
run an external command to verify the metadata from the client key.
See doc/tls-crypt-v2.txt for more details.
Because of the extra dependencies, this requires adding a mock
parse_line() to the tls-crypt unit tests. Also, this turns tls_wrap_free
into a static inline function, so that we don't need to compile in ssl.c
(and all of it's dependencies) with the unit tests.
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
Signed-off-by: Steffan Karger <steffan.karger@fox-it.com>
Acked-by: Antonio Quartulli <antonio@openvpn.net>
Message-Id: <1540208715-14044-6-git-send-email-steffan.karger@fox-it.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg17789.html
Signed-off-by: David Sommerseth <davids@openvpn.net>
We explicitly only supported GCM as a valid AEAD mode, change that to also
allow ChaCha20-Poly1305 as an AEAD cipher. That works nicely with our new
(GCM) data channel format, because is has the same 96-bit IV.
Note that we need some tricks to not treat the cipher as insecure, because
we used to only look at the block size of a cipher to determine if find a
cipher insecure. But ChaCha20-Poly1305 is a stream cipher, which
essentially
has a 'block size' of 1 byte and is reported as such. So, special-case
this
cipher to be in the list of secure ciphers.
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Antonio Quartulli <antonio@openvpn.net>
Message-Id: <20181007223035.21179-1-steffan@karger.me>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg17629.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
This allows the user to specify what certificate crypto algorithms to
support. The supported profiles are 'preferred', 'legacy' (default) and
'suiteb', as discussed in <84590a17-1c48-9df2-c48e-4160750b2e33@fox-it.com>
(https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14214.
html).
This fully implements the feature for mbed TLS builds, because for mbed it
is both more easy to implement and the most relevant because mbed TLS 2+
is by default somewhat restrictive by requiring 2048-bit+ for RSA keys.
For OpenSSL, this implements an approximation based on security levels, as
discussed at the hackathon in Karlsruhe.
This patch uses 'legacy' as the default profile following discussion on
the openvpn-devel mailing list. This way this patch can be applied to
both the release/2.4 and master branches. I'll send a follow-up patch for
the master branch to change the default to 'preferred' later.
Signed-off-by: Steffan Karger <steffan.karger@fox-it.com>
Acked-by: Antonio Quartulli <antonio@openvpn.net>
Message-Id: <20171112163636.17434-1-steffan@karger.me>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg15848.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
In commit 59e7e9fce8 the contrib/keychain-mcd
code was completely removed. But it was not removed from Changes.rst.
Signed-off-by: David Sommerseth <davids@openvpn.net>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20171005212223.24694-1-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg15561.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
A simple clean-up where the version references have been unified
all those places I could find now. The versioning scheme used is:
* OpenVPN 2.x
* v2.x
We want to avoid:
* 2.x (2.4 can be just an ordindary decimal number,
OID reference, a version number or anything else)
* OpenVPN v2.x (OpenVPN indicates we're talking about a version)
In addition, several places where it made sense I tried to ensure
the first version reference uses "OpenVPN 2.x" and the following
references in the same section/paragraph uses "v2.x", to set the
context for the version reference.
In Changes.rst modified paragraphs exceeding 80 chars lines where
reformatted as well.
Signed-off-by: David Sommerseth <davids@openvpn.net>
Acked-by: Steffan Karger <steffan@karger.me>
Message-Id: <20170815205301.14542-1-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg15260.html
Signed-off-by: David Sommerseth <davids@openvpn.net>
We have quite a list of deprecated options currently. Ensure this
is highlighted both in documentation and code.
This patch builds on the wiki page [1] enlisting all deprecated features
and their status. There are also some options not listed here, as
there exists patches in release/2.4 which awaits an update for git master.
[1] https://community.openvpn.net/openvpn/wiki/DeprecatedOptions
Signed-off-by: David Sommerseth <davids@openvpn.net>
Acked-by: Steffan Karger <steffan@karger.me>
Message-Id: <20170815215451.21662-1-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg15261.html
Signed-off-by: David Sommerseth <davids@openvpn.net>
The --keysize option can only be used with already deprecated ciphers,
such as CAST5, RC2 or BF. Deviating from the default keysize is
generally not a good idea (see man page text), and otherwise only
complicates our code.
Since we will also remove the support for weak ciphers (ciphers with
cipher block length less than 128 bits) in OpenVPN 2.6 as well, we
start the deprecation of this option instantly.
[DS: Slightly amended the patch, referencing OpenVPN 2.6 and added
a few more details to Changes.rst and the commit message]
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <20170701112951.19119-1-steffan@karger.me>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg15004.html
Signed-off-by: David Sommerseth <davids@openvpn.net>
The note related to the CRL processing was somehow put into
the deprecated section. This is quite confusing.
Since this is a fairly important change, and there have been
a noticable amount of supports questions related to OpenVPN
not starting due to CRL errors, I put this into the
"New features" section labelled as an improvement. Otherwise
I fear this would drown in the list of "User-visible Changes"
later on.
Signed-off-by: David Sommerseth <davids@openvpn.net>
Acked-by: Steffan Karger <steffan.karger@fox-it.com>
Message-Id: <20170628191538.9135-1-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14985.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(Since Changes.rst is mostly synchronized between master and 2.4.3,
and patches flow master->release/2.4, the change is done here even
if this particular commit is not directly part of 2.4.3 release)
General cleanup, whitespace fixes, quoting fixes by David Sommerseth
<davids@openvpn.net>
Signed-off-by: Gert Doering <gert@greenie.muc.de>
We didn't check the return value of ASN1_STRING_to_UTF8() in
extract_x509_extension(). Ignoring such a failure could result in buf
being free'd twice. An error in ASN1_STRING_to_UTF8() can be caused
remotely if the peer can make the local process run out of memory.
The problem can only be triggered for configurations that use the
--x509-alt-username option with an x509 extension (i.e. the option
parameter starts with "ext:").
This issue was discovered, analysed and reported to the OpenVPN team by
Guido Vranken.
Extensive testing by Guido Vranken gives confidence that this function
is very unlikely to fail in real-world usage (using subjectAltName or
issuerAltName extensions) for other reasons than memory exhaustion.
CVE: 2017-7521
Signed-off-by: Steffan Karger <steffan.karger@fox-it.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Acked-by: David Sommerseth <davids@openvpn.net>
Acked-by: Guido Vranken <guidovranken@gmail.com>
Message-Id: <1497864520-12219-6-git-send-email-steffan.karger@fox-it.com>
URL: https://www.mail-archive.com/search?l=mid&q=1497864520-12219-6-git-send-email-steffan.karger@fox-it.com
Signed-off-by: Gert Doering <gert@greenie.muc.de>
The code never supported all extension types. Make this explicit by only
allowing subjectAltName and issuerAltName (for which the current code does
work).
Using unsupported extension fields would most likely cause OpenVPN to crash
as soon as a client connects. This does not have a real-world security
impact, as such a configuration would not be possible to use in practice.
This bug was discovered, analysed and reported to the OpenVPN team by
Guido Vranken.
Signed-off-by: Steffan Karger <steffan.karger@fox-it.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Acked-by: David Sommerseth <davids@openvpn.net>
Acked-by: Guido Vranken <guidovranken@gmail.com>
Message-Id: <1497864520-12219-5-git-send-email-steffan.karger@fox-it.com>
URL: https://www.mail-archive.com/search?l=mid&q=1497864520-12219-5-git-send-email-steffan.karger@fox-it.com
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Several of our OpenSSL-specific certificate-parsing code paths did not
always clear all allocated memory. Since a client can cause a few bytes
of memory to be leaked for each connection attempt, a client can cause a
server to run out of memory and thereby kill the server. That makes this
a (quite inefficient) DoS attack.
When using the --x509-alt-username option on openssl builds with an
extension (argument prefixed with "ext:", e.g. "ext:subjectAltName"), the
code would not free all allocated memory. Fix this by using the proper
free function.
If ASN1_STRING_to_UTF8() returns 0, it didn't fail and *did* allocate
memory. So also free the returned buffer if it returns 0.
These issues were found, analysed and reported to the OpenVPN team by Guido
Vranken.
CVE: 2017-7521
Signed-off-by: Steffan Karger <steffan.karger@fox-it.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Acked-by: David Sommerseth <davids@openvpn.net>
Acked-by: Guido Vranken <guidovranken@gmail.com>
Message-Id: <1497864520-12219-4-git-send-email-steffan.karger@fox-it.com>
URL: https://www.mail-archive.com/search?l=mid&q=1497864520-12219-4-git-send-email-steffan.karger@fox-it.com
Signed-off-by: Gert Doering <gert@greenie.muc.de>
asn1_buf_to_c_string() returned a literal string if the input ASN.1 string
contained a NUL character, while the caller expects a mutable string.
The caller will attempt to change this string, which allows a client to
crash a server by sending a certificate with an embedded NUL character.
(The other way around is not interesting, as servers are allowed to stop
a client by design.)
Impact analysis:
* applies to mbedtls builds only
* introduced in 2.4 (so 2.3 is not affected)
* can only be exploited if the --x509-track option is used
* requires the CA to sign a certificate with an embedded NUL in the
certificate subject
This bug was discovered and reported to the OpenVPN security team by
Guido Vranken.
CVE: 2017-7522
Signed-off-by: Steffan Karger <steffan.karger@fox-it.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1497864520-12219-2-git-send-email-steffan.karger@fox-it.com>
URL: https://www.mail-archive.com/search?l=mid&q=1497864520-12219-2-git-send-email-steffan.karger@fox-it.com
Signed-off-by: Gert Doering <gert@greenie.muc.de>
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>
This enhances --verify-hash with an optional algorithm flag. If not
provided, it defaults to SHA1 to preserve backwards compatbilitity with
existing configurations. The only valid flags are SHA1 and SHA256.
In addition enhance the layout of the --verify-hash section in the man
page.
Signed-off-by: David Sommerseth <davids@openvpn.net>
Acked-by: Steffan Karger <steffan.karger@fox-it.com>
Message-Id: <20170504204201.1257-1-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14538.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Previously, if a mode was selected where packet ids are not allowed to roll
over, but renegotiation does not succeed for some reason (e.g. no password
entered in time, certificate expired or a malicious peer that refuses the
renegotiaion on purpose) we would continue to use the old keys. Until the
packet ID would roll over and we would ASSERT() out.
Given that this can be triggered on purpose by an authenticated peer, this
is a fix for an authenticated remote DoS vulnerability. An attack is
rather inefficient though; a peer would need to get us to send 2^32
packets (min-size packet is IP+UDP+OPCODE+PID+TAG (no payload), results in
(20+8+1+4+16)*2^32 bytes, or approx. 196 GB).
This is a fix for finding 5.2 from the OSTIF / Quarkslab audit.
CVE: 2017-7479
Signed-off-by: Steffan Karger <steffan.karger@fox-it.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <1494358209-4568-3-git-send-email-steffan.karger@fox-it.com>
URL: http://www.mail-archive.com/search?l=mid&q=1494358209-4568-3-git-send-email-steffan.karger@fox-it.com
Signed-off-by: David Sommerseth <davids@openvpn.net>
Commit 3c1b19e0 changed the maximum size of accepted control channel
packets. This was needed for crypto negotiation (which is needed for a
nice transition to a new default cipher), but exposed a DoS
vulnerability. The vulnerability was found during the OpenVPN 2.4 code
audit by Quarkslab (commisioned by OSTIF).
To fix the issue, we should not ASSERT() on external input (in this case
the received packet size), but instead gracefully error out and drop the
invalid packet.
CVE: 2017-7478
Signed-off-by: Steffan Karger <steffan.karger@fox-it.com>
Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <1494358209-4568-2-git-send-email-steffan.karger@fox-it.com>
URL: http://www.mail-archive.com/search?l=mid&q=1494358209-4568-2-git-send-email-steffan.karger@fox-it.com
Signed-off-by: David Sommerseth <davids@openvpn.net>
If keyUsage was only required to be present, but no specific value was
required, we would omit to free the extracted string. This happens as of
2.4.1, if --remote-cert-tls is used. In that case we leak a bit of
memory on each TLS (re)negotiation.
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <1494154878-18403-1-git-send-email-steffan@karger.me>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14563.html
Signed-off-by: David Sommerseth <davids@openvpn.net>
The extra space before each line made the 2.4.1 section stand out from the
other sections.
Signed-off-by: Steffan Karger <steffan.karger@fox-it.com>
Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <1494015286-20368-1-git-send-email-steffan.karger@fox-it.com>
URL: http://www.mail-archive.com/search?l=mid&q=1494015286-20368-1-git-send-email-steffan.karger@fox-it.com
Signed-off-by: David Sommerseth <davids@openvpn.net>
We long recommended users to use --ns-cert-type to distinguish between
client and server certificates, but that extension is long deprecated and
now can even no longer be accurately checked in OpenSSL 1.1+. We support
a more modern alternative, --remote-cert-tls (which expands to
--remote-cert-ku + --remote-cert-eku), but are overly strict in checking
the keyUsage. This patch makes our implementation less picky, so that
correct-but-slightly-weird certicates will not immediately be rejected.
We currently allow users to specify a list of allowed keyUsage values, and
require that the remote certificate matches one of these values exactly.
This is for more strict than keyUsage usually requires; which is that a
certificate is okay to use if it can *at least* be used for our intended
purpose. This patch changes the behaviour to match that, by using the
library-provided mbedtls_x509_crt_check_key_usage() function in mbed TLS
builds, and performing the 'at least bits xyz' check for OpenSSL builds
(OpenSSL unfortunately does not expose a similar function).
Furthermore, this patch adds better error messages when the checking fails;
it now explains that is expects to match either of the supplied values,
and only does so if the check actually failed.
This patch also changes --remote-cert-tls to still require a specific EKU,
but only *some* keyUsage value. Both our supported crypto libraries will
check the keyUsage value for correctness during the handshake, but only if
it is present. So this still enforces a correct keyUsage, but is a bit
less picky about certificates that do not exactly match expectations.
This patch should be applied together with the 'deprecate --ns-cert-type'
patch I sent earlier.
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1489612820-15284-1-git-send-email-steffan@karger.me>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14265.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
The nsCertType x509 extension is very old, and barely used. We already
have had an alternative for a long time: --remote-cert-tls uses the far
more common keyUsage and extendedKeyUsage extensions instead.
OpenSSL 1.1 longer exposes an API to (separately) check the nsCertType x509
extension. Since we want be able to migrate to OpenSSL 1.1, we should
deprecate this option immediately.
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1488653397-2309-1-git-send-email-steffan@karger.me>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14222.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
We will likely refer many people to the Changes.rst file once we've
released 2.4. This commits tries to polish the language a bit, and
adds two real changes:
- Remove duplicate mention of the changes --tls-cipher defaults
- Move the 'redirect-gateway' behavioural change from 'features' to
'behavioural changes'.
v2 - On the fly commit changes, based on comments from Selva Nair.
DS also added a few minor corrections on top of that.
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <1482779743-9548-1-git-send-email-steffan@karger.me>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13732.html
Signed-off-by: David Sommerseth <davids@openvpn.net>
The git master/2.4 code lacked some useful information about
the changes to --reneg-bytes, SWEET32 and weak ciphers (less
than 128-bits cipher blocks)
v2 - Fixed a couple of grammar/typo issues
Signed-off-by: David Sommerseth <davids@openvpn.net>
Acked-by: Steffan Karger <steffan@karger.me>
Message-Id: <1482509264-24550-1-git-send-email-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13682.html
Mention for maintainers that we've moved to build with -std=c99 by
default. Also document that 32-bit RHEL5 builds will need -std=gnu99
to be buildable.
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1481631416-15377-1-git-send-email-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13518.html
Signed-off-by: David Sommerseth <davids@openvpn.net>
There were some reports that the directories mentioned should
have trailing /, to make it clearer they are directories and not
files. Also rephrased that sentence slightly to be even clearer
in this aspect.
Signed-off-by: David Sommerseth <davids@openvpn.net>
