OpenSSL 1.1 does not allow us to directly access the internal of
any data type, including X509. We have to use the defined
functions to do so.
In x509_verify_ns_cert_type() in particular, this means that we
cannot directly check for the extended flags to find whether the
certificate should be used as a client or as a server certificate.
We need to leverage the X509_check_purpose() API yet this API is
far stricter than the currently implemented check. So far, I have
not been able to find a situation where this stricter test fails
(although I must admit that I haven't tested that very well).
We double-check the certificate purpose using "direct access" to the
internal of the certificate object (of course, this is not a real
direct access, but we still fetch ASN1 strings within the X509 object
and we check the internal value of these strings). This allow us to
warn the user if there is a discrepancy between the X509_check_purpose()
return value and our internal, less strict check.
We use these changes to make peer_cert a non-const parameter to
x509_verify_ns_cert_type(). The underlying library waits for a
non-const pointer, and forcing it to be a const pointer does not make
much sense (please note that this has an effect on the mbedtls part
too).
Compatibility with OpenSSL 1.0 is kept by defining the corresponding
functions when they are not found in the library.
Signed-off-by: Emmanuel Deloget <logout@free.fr>
Acked-by: Steffan Karger <steffan.karger@fox-it.com>
Message-Id: <20170612134330.20971-2-logout@free.fr>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14792.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
The NCP (data channel crypto negotiation) code on the client side waits
for an incoming PUSH_REPLY before setting up the data channel crypto
parameters, because the PUSH_REPLY could contain a "cipher xxx" setting.
In the particular case of a empty PUSH_REPLY message, the relevant code
bits was not called because "we have not received any options, do not
bother to look into it in more detail" - so, ciphers were not set up,
resulting in an error message like this:
Key [AF_INET]... [0] not initialized (yet), dropping packet.
Remove that check, always init the crypto layer on PUSH_REPLY.
Trac: #903
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Steffan Karger <steffan.karger@fox-it.com>
Message-Id: <20170618092244.8801-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14856.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
As we've had an ugly blunder with the v2.3.15 release, this release
tries to avoid making the same mistake once again. Plus it documents
how we produce the source packages.
Signed-off-by: David Sommerseth <davids@openvpn.net>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20170518132432.22776-1-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14672.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
The COPYRIGHT.GPL file was slightly out-of-sync with the last GPLv2
license from Free Software Foundation, Inc.
The changes are primarily a new address, which required touching almost
all the project files.
Except of that, it is just minor adjustments to formatting, removal of
form-feed characters and referencing "GNU Lesser General Public License"
instead of "GNU Library General Public License".
Signed-off-by: David Sommerseth <davids@openvpn.net>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20170329093648.10156-1-davids@openvpn.net>
URL: https://www.mail-archive.com/search?l=mid&q=20170329093648.10156-1-davids@openvpn.net
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Prevents that the client crashes if the peer does not specify
the 'realm' and/or 'nonce' values. These pointers are
dereferenced in DigestCalcHA1() and DigestCalcResponse();
hence, if not set, a null-pointer dereference would occur.
Signed-off-by: Guido Vranken <guidovranken@gmail.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1497574736-2092-1-git-send-email-gv@guidovranken.nl>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14844.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
The length check in tls_ctx_restrict_ciphers() did not check for overflow,
which could lead to a stack buffer overflow.
This has no real-world impact, because --tls-cipher can only be specified
by entities that are allowed to supply config settings. Since those
entities can also change --script-security and call scripts and/or
plugins, these users already have code execution at the level of the
openvpn process. In other words: the attacker would not gain any
capabilities. Nevertheless, a nasty bug that we should fix.
This bug was discovered and reported to the OpenVPN security team by
Guido Vranken.
Signed-off-by: Steffan Karger <steffan.karger@fox-it.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1495461253-20111-1-git-send-email-steffan.karger@fox-it.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14716.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Instead of failing the test with an unclear error, print that the a
required crypto primitive is not supported and skip the test.
This is for example the case when using the system-supplied openssl on
SLES11, which does not support AES-256-CTR.
Signed-off-by: Steffan Karger <steffan.karger@fox-it.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1494859483-16466-1-git-send-email-steffan.karger@fox-it.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14657.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Add one element (a terminating NULL pointer) to the array into
which parse_line() stores the arguments. This prevents that options
that traverse this array until a terminator is seen (for instance
options that call no_more_than_n_args) will peek beyond buffer bounds.
In the worst case this might lead to a crash (stack overflow, not
likely in practice).
Signed-off-by: Guido Vranken <guidovranken@gmail.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <CAO5O-EKCLjPpdKUH6cCoqoZDAfekSafpc7Ga55H2_5Hs4rBopg@mail.gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14757.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
get_proxy_authenticate() is called with a "gc" parameter which MUST
be NULL, otherwise string_alloc() will allocate memory in the gc_arena
while the caller expects the result to be durable and will do explicit
free() when no longer needed. Remove gc parameter, call string_alloc()
with "NULL" so this is clearly visible.
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Steffan Karger <steffan.karger@fox-it.com>
Message-Id: <20170609205029.11002-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14768.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
The pointer to the packet content doesn't seem to be word-aligned,
resulting in a SIGBUS when accessing it as a pointer to struct ip that
contains bit fields.
Replace with struct openvpn_iphdr and OPENVPN_IPH_GET_VER, which only
does a one byte access and thus isn't affected by alignement.
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <87ink3vpcs.fsf@ritchie.wxcvbn.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14769.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
This patch ensures that if an error occurs while processing
the 'connection' directive of an options specification,
the variable 'struct options sub', which is initialized
with init_options(), is properly freed with uninit_options().
Signed-off-by: Guido Vranken <guidovranken@gmail.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <CAO5O-E+HdfHNAK=--55054AB374U-Ky4q_-3M114makfPdSnBw@mail.gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14764.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Refactor my_strupr such that it will not check and possibly alter bytes
after the string's null terminator for strings of length 0.
Signed-off-by: Guido Vranken <guidovranken@gmail.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <CAO5O-ELXwXgGtRFou=FY1TAhW4W4BHPZF4=rqSY877njtXNMJg@mail.gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14756.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Commit 3d6a4cded2 introduced a maximum limit of possible arguments
for most options, to error out on config lines with too-many args.
Commit 82acf21634 extended the limit for "--plugin" to accept "one
mandatory, one optional" argument.
Both are wrong - "--plugin" can accept an arbitrary number of arguments,
but this is not directly obvious from options.c, one needs to check
plugins.c / plugin_option_list_add() and misc.c / make_extended_arg_array()
to see that.
Thus, remove the max limit for "--plugin" completely.
(Reported by SviMik on IRC)
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Steffan Karger <steffan.karger@fox-it.com>
Message-Id: <20170518191311.4769-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14678.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
When OpenVPN is started using a non-default routing table on OpenBSD
(e.g., with 'route -T10 exec openvpn ...'), it hangs forever trying to
read its default gateway from a PF_ROUTE socket. This is because
rtm_tableid is not being initialised after bzeroing the rt_msghdr we
write to the socket, so we end up asking the kernel for the default
route in routing table 0.
By default, the OpenBSD kernel will not respond to requests for routing
table 0 from a process running in a different routing table, and even
if it did, it would give us the wrong default gateway.
The solution here is to set rtm_tableid to the value returned by
getrtable(2), which always succeeds and returns the calling process's
current routing table.
This patch makes the test suite (without a t_client.rc) pass when run
in a non-default routing table, where it would fail previously. It has
also been successfully tested in client mode against both git master
and OpenVPN 2.4.1 from ports on an OpenBSD -current system.
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20170413173129.87367-1-steven@steven-mcdonald.id.au>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14461.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
This is the equivalent of the 2.3 patch (04c84548c2) by Guido Vranken,
adjusted to code in the master and release/2.4 branches.
Trac: #890
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <143540d4-e8ea-b533-ad1a-8ae33bfd1133@karger.me>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14653.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
If a client reconnects on a hard-restart from the same port (due to --bind
in use on the client), both sides will handle this as a "reconnect" and
not a "full new connect" internally, re-using existing crypto context.
The client will still ask the server for pushed options, and the server
code to handle this refuses to do NCP if a key has already been negotiated
(because there is no way to *change* the cipher after that) - which ends
up in "the client uses the non-negotiated cipher from the config file,
while the server uses the previously-negotiated NCP cipher", and nothing
works.
The easy workaround: if we find us in the situation that we think NCP
has already been done, just re-push "cipher o->ciphername" with the
current cipher for this client context.
All credits for this go to Stefan Behrens <sbehrens@giantdisaster.de>
who found and diagnosed the issue in trac #887, came up with a first
patch to solve the issue quite similar to this (simplified) one, and
helped testing.
Trac: #887
Acked-by: Steffan Karger <steffan.karger@fox-it.com>
Message-Id: <20170518102246.5496-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14666.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>
2.4.2 introduced a declaration that references size_t, so use the C99
way of declaring it, and add #include <stddef.h>.
Note this may break on non-C99-compliant versions of MS Visual Studio.
Signed-off-by: Matthias Andree <matthias.andree@gmx.de>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1494884925-12539-1-git-send-email-matthias.andree@gmx.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14658.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
To make it clear that NCP is in effect, print a log message (at --verb 2)
to show that we selected a cipher using NCP.
Signed-off-by: Steffan Karger <steffan.karger@fox-it.com>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <1494859435-16379-1-git-send-email-steffan.karger@fox-it.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14656.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Windows 10 before Creators Update used to resolve DNS using all
available adapters and IP addresses in parallel. Now it still
resolves addresses using all available adapters but in a round-robin
way, beginning with random adapter.
This behaviour introduces significant delay when block-outside-dns is
in use. Fortunately, setting low metric for the TAP interface solves
this issue, making Windows always pick TAP adapter first and disable
round-robin.
Signed-off-by: ValdikSS <iam@valdikss.org.ru>
Acked-by: Selva Nair <selva.nair@gmail.com>
Message-Id: <20170510184753.27145-1-valdikss@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14624.html
Signed-off-by: David Sommerseth <davids@openvpn.net>
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>
The tls-crypt commit message contained an elaborate discussion on the
function's security properties. This commit adds the gist of that
discussion, "rotate keys periodically" to the man page.
(The 'real' solution will follow later: add support for per-client
tls-crypt keys. That will make tls-crypt useful for VPN providers too.)
Note to non-crypto-geek reviewers: please verify that this text is clear
enough to explain you when you need to replace tls-crypt keys.
Note to crypto-geek reviewers: please check the numbers - see the
--tls-crypt commit message (c6e24fa3) for details.
[DS: Fixed a few typos on-the-fly during commit]
Signed-off-by: Steffan Karger <steffan.karger@fox-it.com>
Acked-by: Selva Nair <selva.nair@gmail.com>
Message-Id: <1494355368-20238-1-git-send-email-steffan.karger@fox-it.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14610.html
Signed-off-by: David Sommerseth <davids@openvpn.net>
v2: Change the plugin open to use v3 API so that secure_memzero()
exported from OpenVPN can be used.
v3: Relaxe API compatibility check: struct version 4 or higher
will have secure_memzero exported.
Note: context is cast as (openvpn_plugin_handle_t *) for consistency
with the current plugin header. If/when the header is fixed, change
this cast as well.
Signed-off-by: Selva Nair <selva.nair@gmail.com>
Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <1494359069-13824-1-git-send-email-selva.nair@gmail.com>
URL: http://www.mail-archive.com/search?l=mid&q=1494359069-13824-1-git-send-email-selva.nair@gmail.com
Signed-off-by: David Sommerseth <davids@openvpn.net>
This issue was found by Quarkslab during the OSTIF-founded security audit
(issue 5.4), we are with their analysis:
"There’s a special case where the client username and password are not
erased when the server is launched without an external script or
authentication plugin. While being invalid, this configuration does not
raise any error. If the client transmits its credentials and the session
is not established (for instance if the certificates chain has not been
verified), these credentials are not erased from memory by the server.
The likelihood of an occurrence of this issue in real life is
exceptionally low since an attacker needs elevated privileges on the
server to exploit this kind of information leak. The severity of this
issue is rated as very low."
Signed-off-by: Steffan Karger <steffan.karger@fox-it.com>
Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <1494354764-19354-1-git-send-email-steffan.karger@fox-it.com>
URL: http://www.mail-archive.com/search?l=mid&q=1494354764-19354-1-git-send-email-steffan.karger@fox-it.com
Signed-off-by: David Sommerseth <davids@openvpn.net>
The provides plug-ins with a safe and secure way to santize sensitive
information such as passwords, by re-using the secure_memzero()
implementation in OpenVPN.
Signed-off-by: David Sommerseth <davids@openvpn.net>
Acked-by: Selva Nair <selva.nair@gmail.com>
Message-Id: <20170505184622.24520-1-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14546.html
Signed-off-by: David Sommerseth <davids@openvpn.net>
As reported in trac #879, as of the introduction of NCP we always adjust
the frame parameters on session negotiations, but do not reset the frame
state for a new session on an existing state instance. That caused the
frame parameters to be reduced for each reconnect, resulting in smaller
and smaller packet size limits until no traffic could go through the
tunnel at all. This patch resolves that omission.
Trac: #879
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: David Sommerseth <davids@openvpn.net>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <1494279878-24601-1-git-send-email-steffan@karger.me>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14589.html
Signed-off-by: David Sommerseth <davids@openvpn.net>
The v3 plug-in API was slightly misleading, as that interface does not
need to use an int pointer to setting the type_mask from the plug-in.
Signed-off-by: David Sommerseth <davids@openvpn.net>
Acked-by: Selva Nair <selva.nair@gmail.com>
Message-Id: <20170508141939.31224-1-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14576.html
Signed-off-by: David Sommerseth <davids@openvpn.net>
mbedtls_x509_dn_gets() would not always return -1 error, which could cause
us to incorrectly continue after the function call failed. To fix this,
just call our own x509_get_subject(), which does all the neccesary error
checking correctly.
pkcs11_certificate_dn() is only called by show_pkcs11_ids(), to list the
certificates on the pkcs11 token. Therefor, this mistake did not have a
security impact.
This issue was found by Quarkslab during the OSTIF-founded security audit
(issue 5.3).
Signed-off-by: Steffan Karger <steffan.karger@fox-it.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1494317563-6303-1-git-send-email-steffan.karger@fox-it.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14591.html
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>
Only fields known to OpenSSL have a NID. OBJ_txt2obj allows specifying
fields by numeric OID.
Signed-off-by: Hristo Venev <hristo@venev.name>
Acked-by: Steffan Karger <steffan@karger.me>
Message-Id: <1493853048.30207.1.camel@venev.name>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14535.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>
Because there is no packet_id in those builds... This fixes 'make check'
for --disable-crypto builds, caught by travis.
Signed-off-by: Steffan Karger <steffan.karger@fox-it.com>
Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <1494014848-20099-1-git-send-email-steffan.karger@fox-it.com>
URL: http://www.mail-archive.com/search?l=mid&q=1494014848-20099-1-git-send-email-steffan.karger@fox-it.com
Signed-off-by: David Sommerseth <davids@openvpn.net>
The functions packet_id_alloc_outgoing() and packet_id_write() were
always called in tandem. Instead of forcing the caller to allocate a
packet_id_net to do so, merge the two functions. This simplifies the API
and reduces the chance on mistakes in the future.
This patch adds unit tests to verify the behaviour of packet_id_write().
Verifying that we assert out correctly required the change to mock_msg.c.
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: <1494006291-3522-1-git-send-email-steffan.karger@fox-it.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14541.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Commit 039a89c331 changed the OpenSSL check slightly, but that
broke ./configure on systems which do not install the openssl.pc
pkg-config support file. This is typically an issue on most of the BSD
platforms, where the OpenSSL package from the base repository does not
provide that file.
We should anyway in this case have a better check of OpenSSL version
available. So in the case pkg-config fails, it will run an additional
test looking for the OpenSSL version number in the opensslv.h header
file and check against that version number.
I did consider to rip out the pkg-config test all together, but decided
to let it stay. If pkg-config works, it provides much more details to
the ./configure script than just the version number check - such as
include and library paths if those are outside the default system paths.
If the user adds OPENSSL_CFLAGS or OPENSSL_LIBS to the ./configure
script, the pkg-config will not be run. But this patch ensures that the
OpenSSL version is also checked in this situation.
This patch have been tested on Scientic Linux 7.3 (RHEL clone) and
FreeBSD 10.3-RELEASE-p11.
v5 - Remove the right OPENSSL_LIBS and preserve the old one
- In PKG_CHECK_MODULES(), check for openssl instead of libssl
+ libcrypto
- Fix tab/space issues once again
v4 - Move the CFLAGS/LDFLAGS declarations before the manual
version test; otherwise we're still testing the system install
version
v3 - Remove not needed and duplicated OPENSSL_LIBS assignment
- Fix tab/space issues in modified lines
v2 - Don't use try to simplify the version matching, use the full
OPENSSL_VERSION_NUMBER
- Fixed typo (OpneSSL -> OpenSSL)
- Improve a few comments
Signed-off-by: David Sommerseth <davids@openvpn.net>
Acked-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Steffan Karger <steffan.karger@fox-it.com>
Message-Id: <20170424143910.20118-1-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14503.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
As RHEL 5 has reached EOL, we no longer need to support OpenSSL v0.9.8.
This also makes it possible to remove a few workaronds which was
needed earlier, as well as some left overs from v0.9.6.
This also makes ./configure really stop running unless a new enough
OpenSSL library is found.
Compile tested on RHEL7.3 and RHEL6.7 (mock chroot build), both shipping
openssl-1.0.1e.
Signed-off-by: David Sommerseth <davids@openvpn.net>
Acked-by: Steffan Karger <steffan.karger@fox-it.com>
Message-Id: <20170411173133.18060-1-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14441.html
Signed-off-by: David Sommerseth <davids@openvpn.net>
The warning provided to --cipher and --auth using the 'none' setting may
not have been too clearly understandable to non-developers or people not
fully understanding encryption and cryptography. This tries to improve
that.
While at it, also break up the long source lines.
Signed-off-by: David Sommerseth <davids@openvpn.net>
Acked-by: Steffan Karger <steffan.karger@fox-it.com>
Message-Id: <20170410222828.23612-1-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14436.html
Signed-off-by: David Sommerseth <davids@openvpn.net>
Running rpmlint against Fedora RPM packages revealed these warnings:
W: manual-page-warning /usr/share/man/man8/openvpn.8.gz 2738:
a special character is not allowed in a name
W: manual-page-warning /usr/share/man/man8/openvpn.8.gz 2740:
a special character is not allowed in a name
This is just a typo mistake in the .B formatting, missing a trailing
space.
Signed-off-by: David Sommerseth <davids@openvpn.net>
Acked-by: Steffan Karger <steffan.karger@fox-it.com>
Message-Id: <20170329094925.25644-1-davids@openvpn.net>
URL: http://www.mail-archive.com/search?l=mid&q=20170329094925.25644-1-davids@openvpn.net
Signed-off-by: David Sommerseth <davids@openvpn.net>
If tls_deauthenticate() was called, it could in some scenarios leave the
authentication token for a session in memory. This change just ensures
auth-tokens are always wiped as soon as a TLS session is considered
broken.
Signed-off-by: David Sommerseth <davids@openvpn.net>
Acked-by: Steffan Karger <steffan@karger.me>
Message-Id: <20170328205346.18844-1-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14344.html
Signed-off-by: David Sommerseth <davids@openvpn.net>
The "prepare IPv6 route message to interactive service" was properly
handing the correct interface index (r->adapter_index) for this case,
but then always overwrote the gateway address with our magic tun/tap
fe80::8 value. Only do this for "on tap adapter" routes.
Pinpointed by Selva Nair.
Trac #850
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Selva Nair <selva.nair@gmail.com>
Message-Id: <20170319191049.23970-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14282.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
The env_set_add_to_environmenti() and env_set_remove_from_environment()
functions where not used in the code at all and they would cause an
ASSERT() in setenv_str_ex() later on, as it would not allow the
struct env_set *es pointer to be NULL (misc.c:807).
Signed-off-by: David Sommerseth <davids@openvpn.net>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20170225020229.17287-1-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14195.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Although it does not make sense to specify remote-random-hostname
when a numeric hostname is provided (being it the remote, the http
proxy or the socks server), this is still a valid configuration.
For this reason, this combination should still work as expected,
which means ignoring the randomization and directly using the
numeric IP.
Signed-off-by: Antonio Quartulli <a@unstable.cc>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20170130152658.15786-1-a@unstable.cc>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13993.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
OpenVPN uses a default plug-in directore, set using PLUGINDIR when
running ./configure. If this is set, it will use $LIBDIR/openvpn/plugin.
When using --plugin, OpenVPN will load plug-ins from this directory with
the only exception if the plug-in filename is based on an absolute path.
Any other relative paths are relative to the PLUGINDIR.
This patch adds a third variant, using plug-in paths starting with '.'
In this case, OpenVPN will use the relative directory of where OpenVPN
was started, or the directory OpenVPN have changed into due to --cd
being used before the actual --plugin option.
Signed-off-by: David Sommerseth <davids@openvpn.net>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20170127142120.10492-1-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13970.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
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>
