OpenVPN currently has a bit of a weakness in its early three way handshake
A single client reset packet (first packet of the handshake) will
- trigger creating a session on the server side leading to potential
ressource exhaustion
- make the server respond with 3 answers trying to get an ACK for its
P_CONTROL_HARD_RESET_SERVER_V2 answer making it an amplification
Instead of allocating a connection for each client on the initial packet
OpenVPN will now calculate a session id based on a HMAC that serves as
verifiable cookie that can be checked for authenticity when the client
responds with it. This eliminates the amplification attack and resource
exhaustion attacks.
For tls-crypt-v2 clients the HMAC based handshake is not used yet (will
be added in one of the next patches).
Patch v2: rebase on master
patch v3: fix unit tests, improve comment/style of code
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Frank Lichtenheld <frank@lichtenheld.com>
Message-Id: <20220502154310.836947-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg24262.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>
There were references in our documentation to the now deprecated PolarSSL
library, which have changed name upstream to mbed TLS.
In addition, where appropriate, the documentation now considers only
mbed TLS 2.0 and newer. This is in accordance with the requirements
./configure sets.
[DS: On-the-fly change - Updated Makefile.am to use README.mbedtls
instead of README.polarssl. This ensures make dist and buildbots
won't explode]
Signed-off-by: David Sommerseth <davids@openvpn.net>
Acked-by: Steffan Karger <steffan.karger@fox-it.com>
Message-Id: <20170822114715.14225-1-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg15309.html
Signed-off-by: David Sommerseth <davids@openvpn.net>
Remove the --disable-ssl configure option and accompanying ENABLE_SSL
defines in the master/2.4 branch, to reduce the code and testing
complexity a bit.
This does not remove to runtime option to run without SSL, just the compile
time option to not include any SSL-related code.
During the community meeting in November 2014 there were no objections
amongst he developers present. Also, this has been announced on the -users
and -devel mailing lists two weeks ago, without any response whatsoever.
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <54A4248A.1090501@karger.me>
URL: http://article.gmane.org/gmane.network.openvpn.devel/9371
Signed-off-by: Gert Doering <gert@greenie.muc.de>
