This is basic housekeeping, adding NULL checks to context initialization
of the sample plugin collection which are missing it. Realistically,
this can never happen, but since these are supposed to be "good examples",
not checking calloc() return isn't one.
Trac: #587
Reported-By: Dogbert (in Trac)
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <20200909104837.6123-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20922.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit a61c08a2c80d95dcc2bc30ddcb9a54a462e565ed)
The man page claimed that --client-disconnect "is passed the same
pathname as the corresponding --client-connect command", which is
not what the code does. Fix.
Reported-By: hvenev in Trac
Trac: #884
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Antonio Quartulli <a@unstable.cc>
Message-Id: <20200909122926.9523-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20929.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 50c7700da09a1f83474e18f8709d59dbc4b509e2)
If we connect to a VPN server over IPv6, and the config has a
route like this:
route remote_host default net_gateway
OpenVPN would try to install a route to "255.255.255.255", which
is obviously bogus.
The bug is twofold: init_route_list() should not set RTSA_REMOTE_HOST
for an "IPV4_INVALID_ADDR" remote_host (wrong condition, this is not
a pointer but an integer, and "invalid" is "-1" numerically here),
and init_route() must not ignore "status = false" returns from
get_special_addr().
I have just added the "if (!status)" check, not done refactoring for
init_route() to see whether I could make it "more pretty".
Trac: #1247
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20200911085907.26004-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20958.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit aa34684972eb01bfa5c355d1c8a8a9d384bf0175)
Our code works on "very old Linux" (Fedora-1), but needs a #define
for TUNSETGROUP to compile. Everything else is there.
While at it, fix TUNSETGROUP error message.
Reported-By: noloader on Trac
Trac: #1152
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20200909153725.1158-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20932.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit a4e0ac0604460ea2431acb7481d6ffb7a3fc6298)
Calling "openvpn --inetd" from the CLI (= no socket on stdin) will
lead to endless looping in the accept(4) loop.
Instead of cluttering that function further, detect failure to call
getsockame() in phase2_inetd() already, and trigger a M_FATAL abort
on "errno == ENOTSOCK" ("The argument s is a file, not a socket").
While at it, uncrustify the --bind-dev code (whitespace only).
Trac: #350
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20200908105130.24171-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20897.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit a09a2fadbadb5dc435f6fccc581163e1f637f43f)
It's a long-standing and well-known problem that --push-reset removes
"critical" options from the push list (like "topology subnet") which
will then lead to non-working client configs. This can not be
reasonably fixed, because the list of "critical" options depends on
overall server config.
So just document the fact, and point people towards --push-remove as
a more selective tool.
Trac: #29
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <20200908111511.9271-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20899.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 5fd66510dfdef628fa95f156c5f9d80af9ae1531)
Commit 5fde831c5807 fixed NEXTADDR() for all *BSDs and MacOS.
OpenSolaris has to use a slightly different macro due to lack of
sockaddr->sa_len - but it has the same problem, first rounding up,
then memmove()'ing. Switch order.
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20200813101301.12720-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20731.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 7e65483d1227adfb855844467e4d30894ffc355d)
As it appears commit 767e4c56becbfeea525e4695a810593f373883cd "Log
serial number of revoked certificate" hasn't survive refactoring
of CRL handling.
In most of situations admin of OpenVPN server needs to know which
particular certificate is used by client.
In the case when certificate is valid, environment variable can be
used for that but once it is revoked, no user scripts are invoked
so there is no way to get serial number, only subject is logged.
Let's log certificate serial in case it is revoked and additionally
log certificate depth & subject in crl-verify "dir" mode for better
consistency with crl file (non-dir) mode.
v2: log if serial is not availble, require it in crl-verify dir mode
Signed-off-by: Vladislav Grishenko <themiron@yandex-team.ru>
Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <20200805102333.3109-1-themiron@yandex-team.ru>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20642.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 992e9cec40539a155afa9eae10502aa62f617965)
copy first, then round up the length when adding padding
to the advance.
Found by: GCC 9.3.0 (FreeBSD)
Signed-off-by: Matthias Andree <matthias.andree@gmx.de>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20200717171818.230371-1-matthias.andree@gmx.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20461.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 5fde831c580775aa5c1fe3539b06260d994eee10)
This assertion failure can be hit in production, which causes the
openvpn server process to stop and all clients to be disconnected.
Bug #1270 has been filed for this issue on Trac by another user
who has experienced the issue, and this patch attempts to address it.
Tracing callers, it appears that some callers check ks->authenticated
before calling, but others do not. It may be possible to add the check
for the callers that do not check, but this seems to be a simpler
solution.
To give some background, we hit this assertion failure, with the
following log output:
```
Tue May 19 15:57:05 2020 username/73.135.141.11:1194 PUSH: Received
control message: 'PUSH_REQUEST'
Tue May 19 15:57:05 2020 username/73.135.141.11:1194 SENT CONTROL
[username]: 'PUSH_REPLY,redirect-gateway
def1,comp-lzo,persist-key,persist-tun,route-gateway 10.28.47.1,topology
subnet,ping 10,ping-restart 120,ifconfig 10.28.47.38 255.255.255.0,peer-id
89' (status=1)
Tue May 19 15:57:05 2020 username/73.135.141.11:1194 Assertion failed at
/path/to/openvpn-2.4.7/src/openvpn/ssl.c:1944 (ks->authenticated)
Tue May 19 15:57:05 2020 username/73.135.141.11:1194 Exiting due to fatal
error
Tue May 19 15:57:05 2020 username/73.135.141.11:1194 Closing TUN/TAP
interface
```
using the following OpenVPN server configuration:
```
port 1194
proto udp
dev-type tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
topology subnet
push "redirect-gateway def1"
push "comp-lzo"
push "persist-key"
push "persist-tun"
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
cd /home/openvpn/server
chroot /var/empty
daemon
verb 3
crl-verify crl.pem
tls-auth ta.key 0
cipher AES-256-CBC
tls-version-min 1.2
tls-cipher ECDHE-RSA-AES256-GCM-SHA384
ncp-disable
mute-replay-warnings
script-security 3
auth-user-pass-verify "ldap-auth/ldap-auth" via-env
auth-user-pass-optional
```
and the following command line options:
```
--config openvpn.conf --dev tun1 --local 206.131.72.52 \
--log-append openvpn.log --status openvpn-status.log \
--server 10.28.47.0 255.255.255.0
```
The failed assertion is inside the function
`tls_session_generate_data_channel_keys`, which is called 3 other places
in `ssl.c.`:
* `key_method_2_write`: checks for `ks->authenticated` before calling
* `key_method_2_read`: appears to run in client mode but not in server
mode
* `tls_session_update_crypto_params`: runs in server mode and does not
check before calling
That leads me to believe the problem caller is
`tls_session_update_crypto_params`. There.s three callers of
`tls_session_update_crypto_params`:.
* `incoming_push_message` (`push.c`): Probably this caller, since the
server pushes configuration to clients, and the log shows the
assertion failure right after the push reply.
* `multi_process_file_closed` (`multi.c`): Not this caller. NCP is
disabled in config, and async push was not enabled when compiling.
* `do_deferred_options` (`init.c`): Not this caller. The server
configuration doesn't pull.
Changing the assertion to returning false appears to be the simplest
fix. Another approach would be changing callers to check
`ks->authenticated` before calling, either
`tls_session_update_crypto_params` or `incoming_push_message`.
Signed-off-by: Jeremy Evans <code@jeremyevans.net>
Acked-by: Steffan Karger <steffan.karger@foxcrypto.com>
Message-Id: <20200520183404.54822-1-code@jeremyevans.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19914.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 984bd1e1601e4b9562dbc88b02a8db60b884286f)
Currently this prompt is only output once, not re-written to the
management interface when the management client connects. It is thus
not seen by a client that connects after the prompt is output or one that
disconnects and reconnects. This leads to a deadlock: the daemon waiting
for the "remote" command from the client, the latter not aware of it.
Resolve by adding the ">REMOTE" and ">PROXY" prompt to
man.persist.special_state_msg as done for other persisted prompts such
as ">PASSWORD"
Signed-off-by: Selva Nair <selva.nair@gmail.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1582254028-7763-1-git-send-email-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19497.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 93ba6ccddafcc87f336f50dadde144ea4f6178ad)
In the auth-pam plugin correctly parse the static challenge string
even when password or challenge response is empty.
Whether an empty user input is an error is determined by the PAM
conversation function depending on whether the PAM module queries
for it or not.
Signed-off-by: Selva Nair <selva.nair@gmail.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1533696271-21799-2-git-send-email-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg17382.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 7a8109023f4c345fe12f23421c5fa7e88e1ea85b)
If static challenge is in use, the password passed to the plugin by openvpn
is of the form "SCRV1:base64-pass:base64-response". Parse this string to
separate it into password and response and use them to respond to queries
in the pam conversation function.
On the plugin parameters line the substitution keyword for the static
challenge response is "OTP". For example, for pam config named "test" that
prompts for "user", "password" and "pin", use
plugin openvpn-auth-pam.so "test user USERNAME password PASSWORD pin OTP"
Signed-off-by: Selva Nair <selva.nair@gmail.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1532486093-24793-1-git-send-email-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg17307.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 7369d01bf360bcfa02f26c05b86dde5496d120f6)
In the corner case that the global OpenSSL has an invalid command like
MinProtocol = TLSv1.0
(due to OpenSSL's idiosyncrasies MinProtocol = TLSv1 would be correct)
the SSL_ctx_new function leaves the errors for parsing the config file
on the stack.
OpenSSL: error:14187180:SSL routines:ssl_do_config:bad value
Since the later functions, especially the one of loading the
certificates expected a clean error this error got reported at the
wrong place.
Print the warnings with crypto_msg when we detect that we are in this
situation (this also clears the stack).
Debian Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958296
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20200421101122.24284-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19802.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 75aa88af774abaa168bf72e43e1dbb57be14c044)
There is a time frame between allocating peer-id and initializing data
channel key (which is performed on receiving push request or on async
push-reply) in which the existing peer-id float checks do not work right.
If a "rogue" data channel packet arrives during that time frame from
another address and with same peer-id, this would cause client to float
to that new address. This is because:
- tls_pre_decrypt() sets packet length to zero if
data channel key has not been initialized, which leads to
- openvpn_decrypt() returns true if packet length is zero,
which leads to
- process_incoming_link_part1() returns true, which
calls multi_process_float(), which commits float
Note that problem doesn't happen when data channel key is initialized,
since in this case openvpn_decrypt() returns false.
The net effect of this behaviour is that the VPN session for the
"victim client" is broken. Since the "attacker client" does not have
suitable keys, it can not inject or steal VPN traffic from the other
session. The time window is small and it can not be used to attack
a specific client's session, unless some other way is found to make it
disconnect and reconnect first.
CVE-2020-11810 has been assigned to acknowledge this risk.
Fix illegal float by adding buffer length check ("is this packet still
considered valid") before calling multi_process_float().
Trac: #1272
CVE: 2020-11810
Signed-off-by: Lev Stipakov <lev@openvpn.net>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Antonio Quartulli <antonio@openvpn.net>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20200415073017.22839-1-lstipakov@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19720.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 37bc691e7d26ea4eb61a8a434ebd7a9ae76225ab)
With NCP and deferred auth, we perform cipher negotiation and generate
data channel keys on incoming push request, assuming that auth succeeded.
With async push, when auth succeeds in between push requests, we send
push reply immediately.
The code which generates data channel keys is only called on handling
incoming push requests (incoming_push_message). It might not be called
with NCP, deferred auth and async push, because on incoming push request,
auth might not be complete yet. When auth is complete in between push
requests, push reply is sent and it is assumed that connection is
established. However, since data channel keys are not generated on the
server side, connection doesn't work.
Fix by adding a call to generate data channel keys when async push is
triggered.
Also, all the "session->key[KS_PRIMARY].crypto_options.key_ctx_bi.initialized"
checks have been moved into tls_session_update_crypto_params(), which
is just reducing duplicate code, no actual code change (*all* callers
had this pre-check).
Trac: #1259
Reported-by: smaxfield@duosecurity.com
Signed-off-by: Lev Stipakov <lev@openvpn.net>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20200313165913.12682-1-lstipakov@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19553.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 3b06b57d9f1d972ec16f0893d06697439c1bb1fe)
Currently when the certificate is specified as "SUBJ:foo", the
string foo is assumed to be ascii. Change that and interpret
it as utf-8, convert to a wide string, and flag it as unicode
in CertFindCertifcateInStore().
Signed-off-by: Selva Nair <selva.nair@gmail.com>
Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <1581519967-16950-2-git-send-email-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19405.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit aa6affe6df811db11577847366a569def0a3e314)
Have the cryptoapicert option find the first matching certificate
in store that is valid at the present time. Currently the first
found item, even if expired, is returned.
This makes it possible to update certifiates in store without having
to delete old ones. As a side effect, if only expired certificates are
found, the connection fails.
Also remove some unnecessary casts.
Tested on Windows 10.
Trac #966
v4: Handle the case when an unknown certificate specification is passed
to find_certificate_in_store().
Note: Warnings printed from find_certificate_in_store() could show up
multiple times as its called for each certificate store. This could
be improved in a future patch.
Signed-off-by: Selva Nair <selva.nair@gmail.com>
Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <1581519967-16950-1-git-send-email-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19404.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 7b63984d51a2582ba2d406e46a7debb11df7f478)
Compile time warning for openvpnserv.exe
interactive.c: In function ‘RunOpenvpn’:
interactive.c:160:27: warning: ‘svc_pipe’ may be used uninitialized in
this function [-Wmaybe-uninitialized]
When RunOpenvpn exits early due to errors, uninitialized svc_pipe and
ovpn_pipe vars could get passed to CloseHandleEx(). Fix by initializing
to NULL.
Signed-off-by: Selva Nair <selva.nair@gmail.com>
Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <1582163803-3342-1-git-send-email-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19480.html
Signed-off-by: David Sommerseth <davids@openvpn.net>
(cherry picked from commit 32723d29b2775d63d3fe329d017e7a08e0cdcb72)
Compile time warning for openvpnserv.exe
common.c:90:11: warning: ‘error’ may be used uninitialized in this
function [-Wmaybe-uninitialized];
Uninitialized value gets returned if install-path is not found
in the registry. Fix by setting it to the return value of
GetRegString().
Signed-off-by: Selva Nair <selva.nair@gmail.com>
Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <1582159777-2437-1-git-send-email-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19479.html
Signed-off-by: David Sommerseth <davids@openvpn.net>
(cherry picked from commit e1f7d7885752ac3a0279ecc7e31ccee2af40fbe4)
Commit 8a01147ff attempted to avoid calling the deprecated/noop
operation SSL_CTX_set_ecdh_auto by surrounding it with #ifdef.
Unfortunately, that change also made the return; that would exit
the function no longer being compiled when using OpenSSL 1.1.0+.
As consequence OpenVPN with OpenSSL 1.1.0+ would always set
secp384r1 as ecdh curve unless otherwise specified by ecdh
This patch restores the correct/previous behaviour.
Acked-by: Antonio Quartulli <antonio@openvpn.net>
Message-Id: <20200328040858.16505-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19630.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit d8ac887c6b1b57a1953ab62058b4aed5d8c11f65)
Lack of this led people accepting multiple CAs to use capath,
which already supports multiple CRLs. But capath mode itself
is somewhat ugly: you have to create new file/symlink every time
CRL is updated, and there's no good way to clean them up without
restarting OpenVPN, since any gap in the sequence would cause it
to lose sync (see trac 623).
mbedtls crypto backend already loads multiple CRLs as is, so
it doesn't need this fix.
The patch also includes some logging changes which I think are useful.
Trac: #623
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20200407174436.238933-1-wgh@torlan.ru>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19710.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 05229fb5923f43a502bf0ca731d9ba3106c259e8)
(if available).
When only username is found in the file, redirect the auth-user-pass
query to the management interface if management-query-passwords is
enabled. Otherwise the user is prompted on console, if available,
as before.
This changes the behaviour for those who run from the command line,
with --management-query-passwords, but still expect the prompt
on the console.
Note that the management interface will prompt for both username and
password ignoring the username read from the file. As most GUIs can
save the the username, this is a one-time inconvenience.
Currently, the password is queried on the console (or systemd)
in such cases. This is not sensible when console is not available
(windows GUI, tunnelblick etc.) or when the log is redirected
to a file on Windows (for some reason prompt goes to the log file).
Trac # 757
Signed-off-by: Selva Nair <selva.nair@gmail.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1585591527-23734-2-git-send-email-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19655.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 57578310992d1fbe8eff97049087c5308089acb5)
This helps the next patch. No functionality changes, only
refactoring.
Same as commit 461e566fb274d6f7647dc3aa81c02e4fbf362a23 in master
except for additional ifdef ENABLE_CLIENT_CR
Signed-off-by: Selva Nair <selva.nair@gmail.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1585963064-10311-1-git-send-email-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19697.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Commit f67efa94 exposed that tls_ctx_add_extra_certs will always leave
an error of PEM_R_NO_START_LINE on the stack that will printed the next
time that the error is printed.
Fix this by discarding this error. Also clean up the logic to report
real error on other errors and also the no start line error if no
certificate can be found at all and it is required (--extra-certs
config option)
Patch V2: fix optional flag was flipped betwen --cert and --extra-certs
Patch V3: Make logic more easy to follow, no functional changes
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Antonio Quartulli <antonio@openvpn.net>
Message-Id: <20200402103821.10347-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19685.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 3608d890583549dbdbefc40ed41bf617fa518aa1)
New versions are already available as source/old but old version at
some point disappear from the normal download path. Use the source/old
path for all OpenSSL versions to avoid this problem.
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <20200401124019.10529-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/search?l=mid&q=20200401124019.10529-1-arne@rfc2549.org
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 3e0e169254427c4fdcd667e23b110fb939f9fbde)
When a client disconnects from a server compiled with mbedTLS, the server
cannot process the PUSH_REQUEST from a new connection with the same client
IP and port number. This is the case when the client binds to a static
port.
This behavior is initiated by move_session(), which copies the content of
the tls_session to a new session and re-initializes the old session once the
new session is authenticated.
This tls_session contains, among other things, an mbedtls_ssl_config and
bio_ctx structure. However, the mbedtls context has internal pointers to
the mbedtls_ssl_config and bio_ctx. When the session is moved, these internal
pointers point to the reinitialized session and as a result all received
packets that are stored in the bio_ctx of the moved session can never be
read by the mbedtls session. The PUSH_REQUEST is therefore never seen by the
server.
Since there is no public method to update these internal pointers, this
patch dynamically allocates the mbedtls_ssl_config and bio_ctx and stores
the pointers to those structures in the tls_session instead.
Trac #880
Signed-off-by: Tom van Leeuwen <tom.van.leeuwen@technolution.eu>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20200331071437.12708-1-tom.van.leeuwen@technolution.nl>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19661.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit a59e0754afd37a606d96cf24cea771ace3467289)
This is probably the best description of the rather confusing
capath directory structure OpenSSL manual has to offer.
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20200325122624.3142017-1-wgh@torlan.ru>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19615.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit a2a2132c46dfcac057cb8c50df5d27005e9e40e5)
Clear error stack on successful certificate loading in
tls_ctx_load_cert_file_and_copy() and handle errors also for
PEM_read_bio_PrivateKey() call in tls_ctx_load_priv_file().
Due to certificate loading possibly leaking non-fatal errors on OpenSSL
error stack, and some slight oversights in error handling, the
>PASSWORD:Verification Failed: 'Private Key'
line was never produced on the management channel for PEM formatted keys.
Signed-off-by: Santtu Lakkala <santtu.lakkala@jolla.com>
Acked-by: Steffan Karger <steffan.karger@fox-it.com>
Message-Id: <20191021113506.30377-1-santtu.lakkala@jolla.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18953.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit f67efa9412a62f477aa17c3179b7e9f31ac4b25f)
This option can be used in FreedBSD with devel/libinotify installed.
Detect presence of libinotify with pkgconf and use its word
to compile and link.
Trac: #1256
Signed-off-by: Lev Stipakov <lstipakov@gmail.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20200314052906.28095-1-lstipakov@gmail.com>
URL: https://www.mail-archive.com/search?l=mid&q=20200314052906.28095-1-lstipakov@gmail.com
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit e1eb630df1b3ef5df88afd51003fbec40e5d6d67)
Check the config file location and command line options first
and membership in OpenVPNAdministrators group after that as
the latter could be a slow process for active directory users.
When connection to domain controllers is poor or unavailable, checking
the group membership is slow and causes timeouts in the GUI (Trac
1051). However, in cases where the config is in the global directory,
no group membership check should be required. The re-ordering here
avoids the redundant check in such cases.
In addition to this, its also proposed to improve the timeout handling
in the GUI, but this change is still useful as it should completely
eliminate the timeout issue for many users.
v3: Do not send error message to the client pipe from ValidateOptions().
Instead save the error and send it on only if user authorization also
fails. The error buffer size is increased to 512 wide chars as these
messages could get long in some cases and may get truncated otherwise.
Also see: https://github.com/OpenVPN/openvpn-gui/issues/332
Signed-off-by: Selva Nair <selva.nair@gmail.com>
Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <1582077261-9467-1-git-send-email-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19474.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
57623b4e introduced a print_sockaddr() call in socks.c to print an
openvpn_sockaddr object.
However, this is not correct because print_sockaddr() expects a sockaddr
object as argument instead of openvpn_sockaddr.
This error did not lead to any issue because the two objects are very
similar in regards to the data accessed by print_sockaddr().
Fix this by replacing print_sockaddr() with print_openvpn_sockaddr().
Signed-off-by: Antonio Quartulli <a@unstable.cc>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20191109163714.25506-1-a@unstable.cc>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19073.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 6c39b4dc4766594c6517043af59aeea53ea009d0)
This is the 2.4 backport of master patch (commit d22ba6b).
NCP negotiation replaces worst case crypto overhead
with actual one in data channel frame. That frame
params are used by mssfix. Fragment frame still contains
worst case overhead.
Without this patch, fragmentation logic incorrectly uses
max crypto overhead when calculating packet size. It exceeds
fragment size and openvpn peforms fragmentation:
> sudo tcpdump port 1194
13:59:06.956394 IP server.fi.openvpn > nat2.panoulu.net.openvpn: UDP,
length 652
13:59:06.956489 IP server.fi.openvpn > nat2.panoulu.net.openvpn: UDP,
length 648
This patch fixes fragmentation calculation by
setting actual crypto overhead, and no unnecessary
fragmentation is performed:
> sudo tcpdump port 1194
13:58:08.685915 IP server.fi.openvpn > nat2.panoulu.net.openvpn: UDP,
length 1272
13:58:08.686007 IP server.fi.openvpn > nat2.panoulu.net.openvpn: UDP,
length 1272
Trac #1140
Signed-off-by: Lev Stipakov <lev@openvpn.net>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1572439499-16276-1-git-send-email-lstipakov@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18975.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Commit ("openssl: Fix compilation without deprecated OpenSSL 1.1 APIs")
has removed the cipher_ctx_cleanup() API, as it is not anymore required
to be a distinct call. However, while doing so it also touched the
mbedtls backend in a wrong way causing a systematic segfault upon
connection.
Basically mbedtls_cipher_free(ctx) was moved from the defunct
cipher_ctx_cleanup()
to md_ctx_free(), while it was supposed to go into cipher_ctx_free().
This was clearly wrong as also the type of the ctx variable was not
correct anymore.
Fix this mistake by actually moving mbedtls_cipher_free(ctx) to
cipher_ctx_free().
Signed-off-by: Antonio Quartulli <a@unstable.cc>
Acked-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20190816204945.7937-1-a@unstable.cc>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18781.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 2a74fc3f66bb9f73fc957719d187256922ca003f)
EVP_CIPHER_CTX_init and _cleanup were deprecated in 1.1 and both were
replaced with _reset.
EVP_CIPHER_CTX_free in OpenSSL 1.1 replaces the cleanup/free combo of
earlier OpenSSL version. And OpenSSL 1.0.2 already calls cleanup as part
of _free.
Therefore we can remove the _cleanup calls and use the OpenSSL 1.1. API
everywhere.
Also removed initialisation with OpenSSL 1.1 as it is no longer
needed and causes compilation errors when disabling deprecated APIs.
Same with SSL_CTX_set_ecdh_auto as it got removed.
Patch V3: Use EVP_CIPHER_CTX_reset instead of init/cleanup
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Rosen Penev <rosenp@gmail.com>
Acked-by: Steffan Karger <steffan.karger@fox-it.com>
Message-Id: <20190724152934.9884-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18700.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 8a01147ff77e4ae2e377744b89fbe4b6841b2bb0)
The "route add" code always used "metric 0" on OpenSolaris, because
(on tun interfaces) it was required to make the route work on
"non-ethernet" interfaces (connected, no NDP).
This breaks routes via tap interfaces on recent Solaris versions
(tested on OpenIndiana 2019) - there, routes only work if metric
is != 0 (or just not set). Otherwise it tries to map the gateway
address to a local address and fails.
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Antonio Quartulli <antonio@openvpn.net>
Message-Id: <20191009095200.9337-2-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18906.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 01b3a48c29df6dc4bade3d8fb7903346a3f77887)
Our current socks.c code does not handle IPv6 + UDP mode (socket
negotiated with server is IPv4-only, addresses passed in the
packets are IPv4-only). If this combination is specified, print
an explanatory message and force IPv4-only.
While at it, extend socks.c code to print address+port of auxiliary
UDP connection to SOCKS server (helps debugging).
Trac: #1221
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Antonio Quartulli <antonio@openvpn.net>
Message-Id: <20191020150039.21516-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18952.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 57623b4e40e68de983b9dfd82914dadcbe096f7b)
OpenVPN-GUI (For Windows) currently always adds "--pull-filter"
which is a fatal error when also using "--mode server"
Using "--pull-filter" implicitly requires the use of "--pull".
Using "--mode server" and "--pull" is a fatal error which supercedes
"--pull-filter"
Safely ignore "--pull-filter" for "--mode server"
Trac: #1164
v2: Improve commit message, no functional changes.
Signed-off-by: Richard Bonhomme <tincanteksup@gmail.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20191024214832.22737-1-tincanteksup@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18964.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit bb1ea491cd16d11b448342e8287beacae619f980)
A test run with FreeBSD PR 229925 'Disallow escaping ordinary
characters in regex(3)' reveals one sed expression that uses the
GNU-extension "\s".
Given that this is the only occurrence and it's a trivial fix,
update it to be POSIX-compatible.
Signed-off-by: Matthias Andree <matthias.andree@gmx.de>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20190906174458.14975-2-matthias.andree@gmx.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18806.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 7e4a261cc92a813f9e9ba9ee91c6e08de9d843f8)
For PSS padding, CNG requires the digest to be signed
and the digest algorithm in use, which are not accessible
via the rsa_sign and rsa_priv_enc callbacks of OpenSSL.
This patch uses the EVP_KEY interface to hook to
evp_pkey_sign callback if OpenSSL version is > 1.1.0.
Mapping of OpenSSL hash algorithm types to CNG is moved
to a function for code-reuse.
To test, both the server and client should be built with
OpenSSL 1.1.1 and use TLS version >= 1.2
Tested on Windows 7 client against a Linux server.
Signed-off-by: Selva Nair <selva.nair@gmail.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1564346061-5683-1-git-send-email-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18715.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
OpenVPN 2.4.6 could be compiled with LibreSSL, 2.4.7 cannot. This was
broken
since 9de7fe0a "Add support for tls-ciphersuites for TLS 1.3".
This patch avoids using TLS 1.3 directly, be it that OpenSSL was compiled
without TLS 1.3 support, or LibreSSL was used.
This patch was based on an OpenBSD patch by
Jeremie Courreges-Anglas <jca@openbsd.org>, see
https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/net/openvpn/patches/patch-s
rc_openvpn_ssl_openssl_c
but was revised to be more obvious and check actual feature macros,
do not rely on current LibreSSL implementation details alone.
Franco Fichtner reports that OPNsense has been a long-time user
of LibreSSL without reported breakage, see also:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238382#c10
Signed-off-by: Matthias Andree <matthias.andree@gmx.de>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20190818111811.8853-2-matthias.andree@gmx.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18790.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
For reasons historically unknown, OpenVPN sets the listen() backlog
queue to "1", which signals the kernel "while there is one TCP connect
waiting for OpenVPN to handle it, refuse all others" - which, on
restarting a busy TCP server, will create connection issues.
The exact "best" value of the backlog queue is subject of discussion,
but for a server that is not extremely busy with many connections
coming in in parallel, there is no real difference between "10" or "500",
as long as it's "more than 1".
Found and debugged by "mjo" in Trac.
Trac: #1208
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Antonio Quartulli <antonio@openvpn.net>
Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <20190815155319.28249-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18758.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 6d8380c78bf77766454b93b49ab2ebf713b0be48)
I noticed the .rc-files for programs uses
'FILETYPE 0x2L'. The 0x2L' is for a .DLL (VFT_DLL).
Ref: Win-Kit's 'um/verrsrc.h':
#define VFT_DLL 0x00000002L
Hence these '0x2L' should be replaced with 'VFT_APP':
Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <aa4f4026-a684-f96d-c8cb-d4f8a3468c4c@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18644.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit abf7a2f226a262860f369e0a3c5d0f6124b7f110)
From the pkcs11-helper API documentation about pkcs11h_setForkMode():
> This funciton is releavant if PKCS11H_FEATURE_MASK_THREADING is
> set. If safe mode is on, the child process can use the loaded
> PKCS#11 providers but it cannot use fork(), while it is in one of
> the hooks functions, since locked mutexes cannot be released.
As far as I can tell, pkcs11-helper functionality is not used in a
child process that is created after initialization. Even if OpenVPN is
turned into a daemon, the pkcs11-helper library is only initialized
after calling possibly_become_daemon(), i.e. in the child process. All
other uses of fork() are immediately followed by an exec()
This simple change fixes the symptoms described in both
<https://community.openvpn.net/openvpn/ticket/538> (hang on password
prompt when systemd support is enabled) and
<https://community.openvpn.net/openvpn/ticket/1157> (hang on
initialization with newer versions of pkcs11-helper).
I have successfully tested that this makes the described symptoms go
away. For this, I used a YubiKey NEO on Debian/stable, a rebuild of
OpenVPN 2.4.6 and two versions of libpkcs11-helper:
- libpkcs11-helper 1.21-1 from Debian/stretch
- a backport of libpkcs11-helper 1.25-1 from Debian/buster
Acked-by: Steffan Karger <steffan.karger@fox-it.com>
Message-Id: <20190218153129.3818-1-bengen@hilluzination.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18218.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 59e45a8bbc9084329c683730325bc5b676058e71)
commit 0c1cc8d65539f removed "DWORD len;" from service_enable_dhcp(),
but that variable is far from "unused" - breaking compilation.
The problem here was that it's a larger "cleanup compiler warnings"
patch which was fully correct for master, but this particular function
looks different in release/2.4 because the whole iservice call
refactoring patch isn't in release/2.4 - so master does not need the
DWORD len, but release/2.4 does.
More care needed with "warning cleanup"...
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20190705130001.30741-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18652.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
