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>
This fixes the bug of supporting --no-iv (since we're only accepting
bugfixes in the current release phase ;) ).
The --no-iv function decreases security if used (CBC *requires*
unpredictable IVs, other modes don't allow --no-iv at all), and even
marginally decreases other user's security by adding unwanted
complexity to our code.
Let's get rid of this.
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <1481138447-6292-1-git-send-email-steffan@karger.me>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13430.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
tls_session_update_crypto_params() did not properly set crypto_flags_or,
but instead set crypto_flags_and twice if a OFB/CFB mode was selected.
Also, the crypto flags in ks->crypto_options.flags were set before
tls_session_update_crypto_params() was called, causing those to not be
adjusted. To fix this, set the crypto flags in
tls_session_generate_data_channel_keys() instead of key_state_init().
While touching that code, remove the to _or and _and variables, which are
not needed at all.
Finally, refuse to accept --no-iv if NCP is enabled (we might otherwise
negotiate invalid combinations and ASSERT out later, and using --no-iv is
a bad idea anyway).
Trac: #784
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1481133684-5325-1-git-send-email-steffan@karger.me>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13428.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
[DS: slightly enhanced the --enable-async-push remark to make it
even more clear it is a build time configuration]
Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <1481104617-3675-1-git-send-email-lstipakov@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13420.html
Signed-off-by: David Sommerseth <davids@openvpn.net>
In order to prevent annoying delays upon client connection,
reload the CRL file only if it was modified since the last
reload operation.
If not, keep on using the already stored CRL.
This change will boost client connection time in instances
where the CRL file is quite large (dropping from several
seconds to few milliseconds).
Cc: Steffan Karger <steffan.karger@fox-it.com>
Signed-off-by: Antonio Quartulli <a@unstable.cc>
Acked-by: Steffan Karger <steffan.karger@fox-it.com>
Message-Id: <20161201104145.23821-1-a@unstable.cc>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13345.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
As reported and discussed on Trac #775, restarting dns service has
unwanted side effects when there are dependent services. And it
appears unnecessary to restart this service to get DNS registered
on Windows.
Resolve by removing two actions from --register-dns:
'net stop dnscache' and 'net start dnscache' run through the service
or directly.
Trac: #775
Signed-off-by: Selva Nair <selva.nair@gmail.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1480542696-7123-1-git-send-email-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13331.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
The service deletes all added routes when the client process (openvpn)
exits, causing the re-instated default route to disappear.
Fix by rewriting "--redirect-gateway" to "--redirect-gateway def1" when
routes are set using interactive service.
Only the behaviour on Windows with intereactive service is affected.
Trac: #778
Signed-off-by: Selva Nair <selva.nair@gmail.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1480466372-2396-1-git-send-email-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13307.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
In OpenVPN 2.3 --tls-remote got deprecated in favour of --verify-x509-name.
The new option solves the same task as --tls-remote but in a more flexible
and improved way. This new option was introduced in commit 9f0fc74566
(release/2.3: f6e12862ce). Removing --tls-remote will only require
a minor configuration file change.
The removal of this option has been documented in the man pages since the
release of OpenVPN v2.3, where also the deprecation of --compat-names and
--no-name-remapping was included. However, those two will first be removed
in OpenVPN v2.5.
The reason not to remove --compat-names and --no-name-remapping now is that
such a change will require TLS verification scripts and plug-ins to be
updated to support the new X.509 subject formatting; which
--verify-x509-name already uses.
Signed-off-by: David Sommerseth <davids@openvpn.net>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1479217256-21298-1-git-send-email-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13070.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
This adds a --tls-crypt option, which uses a pre-shared static key (like
the --tls-auth key) to encrypt control channel packets.
Encrypting control channel packets has three main advantages:
* It provides more privacy by hiding the certificate used for the TLS
connection.
* It is harder to identify OpenVPN traffic as such.
* It provides "poor-man's" post-quantum security, against attackers who
will never know the pre-shared key (i.e. no forward secrecy).
Control channel packet encryption
---------------------------------
We propose to use the following encryption method, based on the SIV
construction [0], to achieve nonce misuse-resistant authenticated
encryption:
msg = control channel plaintext
header = opcode (1 byte) || session_id (8 bytes) || packet_id (8
bytes)
Ka = authentication key (256 bits)
Ke = encryption key (256 bits)
(Ka and Ke are pre-shared keys, like with --tls-auth)
auth_tag = HMAC-SHA256(Ka, header || msg)
IV = 128 most-significant bits of auth_tag
ciph = AES256-CTR(Ke, IV, msg)
output = Header || Tag || Ciph
This boils down to the following on-the-wire packet format:
-opcode- || -session_id- || -packet_id- || auth_tag || * payload *
Where
- XXX - means authenticated, and
* XXX * means authenticated and encrypted.
Which is very similar to the current tls-auth packet format, and has the
same overhead as "--tls-auth" with "--auth SHA256".
The use of a nonce misuse-resistant authenticated encryption scheme
allows us to worry less about the risks of nonce collisions. This is
important, because in contrast with the data channel in TLS mode, we
will not be able to rotate tls-crypt keys often or fully guarantee nonce
uniqueness. For non misuse-resistant modes such as GCM [1], [2], the
data channel in TLS mode only has to ensure that the packet counter
never rolls over, while tls-crypt would have to provide nonce uniqueness
over all control channel packets sent by all clients, for the lifetime
of the tls-crypt key.
Unlike with tls-auth, no --key-direction has to be specified for
tls-crypt. TLS servers always use key direction 1, and TLS clients
always use key direction 2, which means that client->server traffic and
server->client traffic always use different keys, without requiring
configuration.
Using fixed, secure, encryption and authentication algorithms makes both
implementation and configuration easier. If we ever want to, we can
extend this to support other crypto primitives. Since tls-crypt should
provide privacy as well as DoS protection, these should not be made
negotiable.
Security considerations:
------------------------
tls-crypt is a best-effort mechanism that aims to provide as much
privacy and security as possible, while staying as simple as possible.
The following are some security considerations for this scheme.
1. The same tls-crypt key is potentially shared by a lot of peers, so it
is quite likely to get compromised. Once an attacker acquires the
tls-crypt key, this mechanism no longer provides any security against
the attacker.
2. Since many peers potentially use the tls-crypt key for a long time, a
lot of data might be encrypted under the tls-crypt key. This leads
to two potential problems:
* The "opcode || session id || packet id" combination might collide.
This might happen in larger setups, because the session id contains
just 64 bits or random. Using the uniqueness requirement from the
GCM spec [3] (a collision probability of less than 2^(-32)),
uniqueness is achieved when using the tls-crypt key for at most
2^16 (65536) connections per process start. (The packet id
includes the daemon start time in the packet ID, which should be
different after stopping and (re)starting OpenPVN.)
And if a collision happens, an attacker can *only* learn whether
colliding packets contain the same plaintext. Attackers will not
be able to learn anything else about the plaintext (unless the
attacker knows the plaintext of one of these packets, of course).
Since the impact is limited, I consider this an acceptable
remaining risk.
* The IVs used in encryption might collide. When two IVs collide, an
attacker can learn the xor of the two plaintexts by xorring the
ciphertexts. This is a serious loss of confidentiality. The IVs
are 128-bit, so when HMAC-SHA256 is a secure PRF (an assumption
that must also hold for TLS), and we use the same uniqueness
requirement from [3], this limits the total amount of control
channel messages for all peers in the setup to 2^48. Assuming a
large setup of 2^16 (65536) clients, and a (conservative) number of
2^16 control channel packets per connection on average, this means
that clients may set up 2^16 connections on average. I think these
numbers are reasonable.
(I have a follow-up proposal to use client-specific tls-auth/tls-crypt
keys to partially mitigate these issues, but let's tackle this patch
first.)
References:
-----------
[0] Rogaway & Shrimpton, A Provable-Security Treatment of the Key-Wrap
Problem, 2006
(https://www.iacr.org/archive/eurocrypt2006/40040377/40040377.pdf)
[1] Ferguson, Authentication weaknesses in GCM, 2005
(http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Ferg
uson2.pdf)
[2] Joux, Authentication Failures in NIST version of GCM, 2006
(http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/800-38_Serie
s-Drafts/GCM/Joux_comments.pdf)
[3] Dworking, Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC, 2007
(http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf)
Patch history:
--------------
v2 - processed Arne's review comments:
* Error out early with a clear error message when AES-256-CTR or
HMAC-SHA-256 are not supported by the crypto library.
* Clarify that cipher_ctx_reset() sets the IV.
v3 - actually add error messages promised in v2...
Signed-off-by: Steffan Karger <steffan.karger@fox-it.com>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <1479216586-20078-1-git-send-email-steffan.karger@fox-it.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13069.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
This patch refactors the CRL handling to rely more on the implementation
of the crypto library. It will insert the CRL at the correct time to keep
it up to date, but all additional verification logic is removed from
ssl_verify_<backend>.c. "Less code of our own, less bugs of our own."
In practice, this means extra checks will be performed on the CRL, such as
checking it validBefore and validAfter fields.
This patch was originally written by Ivo Manca, and then molded by Steffan
before sending to the list. All bugs are Steffan's fault.
Thanks also go to Antonio Quartulli for useful feedback. He'll send
follow-up patches to improve CRL handling performance.
Signed-off-by: Ivo Manca <ivo.manca@fox-it.com>
Signed-off-by: Steffan Karger <steffan.karger@fox-it.com>
Acked-by: David Sommerseth <davids@openvpn.net>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1477670087-30063-1-git-send-email-steffan.karger@fox-it.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12809.html
Signed-off-by: David Sommerseth <davids@openvpn.net>
Key method 2 has been the default since OpenVPN 2.0, and is both more
functional and secure. Also, key method 1 was only ever supported for
peer-to-peer connections (i.e. not for client-server).
Let's get rid of some legacy and phase out key method 1.
v2: add Changes.rst entry, and update man page
[ DS: Slightly modified patch, rewored the warning message and the
Changes.rst note to encourage not to set --key-method at all ]
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <1479153967-6788-1-git-send-email-steffan@karger.me>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13054.html
Signed-off-by: David Sommerseth <davids@openvpn.net>
v4:
- Account for IP header offset in TAP mode
- Correct handle of non-IP protocols in TAP mode
v3: Use better way of figuring out IP proto version which
does not break TAP mode. Add an option to allow recursive
routing, could be useful when packets sent by openvpn itself
are not subject to the routing tables that would move packets
into the tunnel.
v2: better method naming
On certain OSes (Windows, OS X) when network adapter is
disabled (ethernet cable pulled off, Wi-Fi hardware switch disabled),
operating system starts to use tun as an external interface.
Outgoing packets are routed to tun, UDP encapsulated, given to
routing table and sent to.. tun.
As a consequence, system starts talking to itself on full power,
traffic counters skyrocket and user is not happy.
To prevent that, drop packets which have gateway IP as
destination address.
Tested on Win7/10, OS X, Linux.
Trac #642
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1478208503-25929-1-git-send-email-lstipakov@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12894.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
This sets the flag if the OpenVPN server should create authentication
tokens on-the-fly on successful --auth-user-pass-verify or --plugin with
OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY processing.
If an OpenVPN server is running without this option, it should behave
as before. Next patches will implement the auth-token generation and
passing it on to the clients.
The --auth-gen-token can be given an optional integer argument which
defines the lifetime of generated tokens. The lifetime argument
must be given in number of seconds.
v2 - Update Changes.rst
- Improve man page in regards to lifetime argument
- Rename struct member auth_generate_token to auth_token_generate
to have a consistent naming scheme
Signed-off-by: David Sommerseth <davids@openvpn.net>
Acked-by: Steffan Karger <steffan@karger.me>
Message-Id: <1477684124-26083-2-git-send-email-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12825.html
- Add `` to all options
- Sort and group new features
- Group changes a bit better
- Fix some formatting/formulation
Patch V2:
- add missing quote, noticed by Samuli
- add new windows services
- add ECDH
- add pushable compression
- add Android and AIX platform support
Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <1477060957-6423-1-git-send-email-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12766.html
Signed-off-by: David Sommerseth <davids@openvpn.net>
This option was useful when IPv6 tun support was non standard and was an
internal/user specified flag that tracked the Ipv6 capability of the tun
device.
All supported OS support IPv6. Also tun-ipv6 is pushable by the remote so
not putting tun-ipv6 does not forbid ipv6 addresses.
This commit also clean up a bit of the ipv6 related tun.c. Changes for
most platforms are minimal.
For linux a bit more cleanup is done:
- Remove compatibility defines that were added 2008
- Always use IFF_NO_PI for the linux tun and not only for IPv4 only tun
setups (Android also always IFF_NO_PI works fine with Ipv6).
This commit also remove a non ipv6 fallback for tap driver from OpenVPN
2.2-beta or earlier and only warns.
Patch V2: Integrate Gert's comments
Patch V3: Remove tun_ipv4 option. It only used for MTU discovery and there
it was wrong since it should on the transport protocol if at all
Patch V4: Completely remove support for NetBSD <= 4.0 and remove
NETBSD_MULTI_AF defines
Patch V5: Assume generic OS in tun.c is also IPv6 capable. Add changes to
man page. Fix typos/change message as suggest by David.
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: David Sommerseth <davids@openvpn.net>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1476377656-3150-1-git-send-email-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12695.html
Signed-off-by: David Sommerseth <davids@openvpn.net>
Pushes AES-256-GCM when a connection client advertises IV_NCP=2, and
supports serving connections to clients with different data channel
cipher configuration simultaneously.
v2:
* Update manpage
* Add Changes.rst entry
v3:
* Do not regenerate keys if the client sends a second pull request
* Don't postpone key generation if client has no IV_NCP support
v4:
* rebase on client-side NCP v4
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1467149771-10374-1-git-send-email-steffan@karger.me>
URL: http://article.gmane.org/gmane.network.openvpn.devel/12009
Signed-off-by: Gert Doering <gert@greenie.muc.de>
- When the number of retries per remote exceeds a limit
(hard coded to 5), double the restart pause interval
for each additional retry per remote.
- Trigger a SIGHUP to reset the retry count when the pause
interval exceeds 1024 times the base value of restart pause.
(removed in v2 of the patch)
The base value of restart pause is set using --connect-retry
(5 seconds by default).
v2 changes (based on suggestions from Arne Schwabe <arne@rfc2549.org>)
- Do not throw SIGHUP.
- Add an optional argument to "--connect-retry n [m]" where 'm'
specifies the max value of restart pause interval (default
300 sec).
E.g., "--connect-retry 5 1800" will cause the restart pause to
scale up starting at 5 until it exceeds 1800 seconds at which
point it gets capped at 1800.
- If n == m no slow down will occur.
- While at it, fix typos and clarify the description of connect-retry-max
in the man page and Changes.rst
v3 changes (on further feedback from arne@rfc2549.org):
- Limiting the base value of retry wait interval to 16 bits moved
to options.c
- Apply backoff only in the udp and tcp-client modes. Backing off on
tcp-server could be exploited by a client in p2p-mode to maliciously
slow it down (thanks to Arne Schwabe for pointing this out.
- Fix typo in Changes.rst: "third argument" -> "second argument"
Signed-off-by: Selva Nair <selva.nair@gmail.com>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1467732770-19110-1-git-send-email-selva.nair@gmail.com>
URL: http://article.gmane.org/gmane.network.openvpn.devel/12050
Signed-off-by: Gert Doering <gert@greenie.muc.de>
These options were probably introduced long before we had multiple
remote/connection entries. For all other connection entries, OpenVPN will
go on with the next connection if it fails. For proxies, if it fails in
some ways it works the same, for other failures it completely stops.
Removing the *-proxy-retry and defaulting to retry makes the behavior more
predictiable. Stopping after one try (regardless of reason) can be achieved
with --max-connect-retry 1
V2: Add reason for removing, remove from manpage, give a hint at
--max-connet-retry
V3: Collapse the two ifs in options.c to one block
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1466771230-5266-1-git-send-email-arne@rfc2549.org>
URL: http://article.gmane.org/gmane.network.openvpn.devel/11988
Signed-off-by: Gert Doering <gert@greenie.muc.de>
With this change all timeouts before the first packet from the OpenVPN
server are unified into the server-poll-timeout option.
The default of 120s has been chosen to be a safe value is larger as it is
larger the sums of the old small timeouts.
V3: fix some whitespace/typos problems
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1465656195-12722-1-git-send-email-arne@rfc2549.org>
URL: http://article.gmane.org/gmane.network.openvpn.devel/11899
Signed-off-by: Gert Doering <gert@greenie.muc.de>
v2 changes:
- Add the flag "ignore" and have "reject" trigger a restart.
- Unlimited number of filters: yes, going against the consensus,
but the code looks simpler and cleaner this way.
- New commit message to reflect the changes.
Usage: --pull-filter accept|ignore|reject "option"
Permit a client to selectively accept, ignore or reject options
pushed by the server. May be used multiple times. The filters
are applied in the order specified to each pushed option received.
The filtering stops as soon as a match is found. The action "ignore"
removes the option and continues processing the next option, while
"reject" flags an error and restarts the connection with SIGUSR1.
Prefix matching is used so that all options starting with the
specified "option" string are filtered.
Example:
pull-filter accept "route 192.168."
pull-filter ignore "route "
pull-filter accept "ifconfig 10.9.0."
pull-filter reject "ifconfig "
will ignore all pushed routes except those starting with "192.168."
and reject the assigned ip unless its in the "10.9.0.0/24"
range. A match of the reject filter will trigger a restart. SIGUSR1
restart is used instead of SIGHUP so as to try the next remote
for reconnection.
Note the space at the end of "route " to not reject "route-gateway",
for example. All options not matched by any filter are accepted.
Acknowledges shameless imitation of --push-remove.
Inspired by Trac #682.
Signed-off-by: Selva Nair <selva.nair@gmail.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1465162884-32520-1-git-send-email-selva.nair@gmail.com>
URL: http://article.gmane.org/gmane.network.openvpn.devel/11808
Signed-off-by: Gert Doering <gert@greenie.muc.de>
With this option, the server can remove individual options from the
set pushed to a client (call from --client-config-dir file, or from
--client-connect script or plugin). Options are removed at parse
time, so it is possible to do stuff like:
push-remove route-ipv6
push "route-ipv6 fd00::/8"
to first remove all IPv6 route options set so far, then add something
specific (what "push-reset" does to all the options).
Arguments to push-remove are strncmp()'ed to option string, so partial
matches like
push-remove "route-ipv6 2001:"
are possible ("remove all IPv6 routes starting with 2001:").
Implementation of remove_iroutes_from_push_route_list() had to be changed
slightly to stop it from re-enabling all disabled options again.
v2: documentation (Changes.rst, doc/openvpn.8)
remove surplus gc_arena
implement filtering of "ifconfig-ipv6"
v3: correct quoting in commit message
only handle a single argument per push-remove statement - if multiple
options are to be removed, just use multiple push-remove statements
Trac #29, #614
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <1463393584-8318-1-git-send-email-gert@greenie.muc.de>
URL: http://article.gmane.org/gmane.network.openvpn.devel/11665
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Instead of just printing the contents of the flags variable, try to
convert it to a human-readable error string and print that instead.
This will for example print "The certificate is signed with an
unacceptable key (eg bad curve, RSA too short).", instead of
"flags=10000".
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1462306478-21059-1-git-send-email-steffan@karger.me>
URL: http://article.gmane.org/gmane.network.openvpn.devel/11594
Signed-off-by: Gert Doering <gert@greenie.muc.de>
509_get_sha1_hash() is supposed to return the certificate fingerprint,
which is the hash of the entire certificate - including the signature -
and not just the 'to be signed' data (cert->tbs in polarssl).
This changes externally visible behavior for polarssl builds: it will
change the value of the tls_digest_N values exported to the environment
for scripts.
v2 Steffan Karger: added commit message and Changes.rst entry.
Code unchanged from v1 by James.
Signed-off-by: James Yonan <james@openvpn.net>
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <CAA1AbxL=QYUy6N+jKgxVVuftmF=75mSEz3rYUbisT245UfB5Dg@mail.gmail.com>
URL: http://article.gmane.org/gmane.network.openvpn.devel/11396
Signed-off-by: Gert Doering <gert@greenie.muc.de>
In the past years, the internet has been moving forward wrt deprecating
older and less secure ciphers. Let's follow this example in OpenVPN and
further restrict the default list of negotiable TLS ciphers.
Compared to earlier, this disables the following:
* Ciphers in the LOW and MEDIUM security cipher list of OpenSSL
The LOW suite will be completely removed from OpenSSL in 1.1.0,
the MEDIUM suite contains ciphers like RC4 and SEED.
* Ciphers that do not provide forward secrecy (static DH/ECDH keys)
* DSA private keys (rarely used, and usually restricted to 1024 bits)
v2: added Changes.rst entry.
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <1460917927-31645-1-git-send-email-steffan@karger.me>
URL: http://article.gmane.org/gmane.network.openvpn.devel/11457
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Add Authenticated Encryption with Additional Data (AEAD) support for
ciphers, which removes the need for a separate HMAC step. The MAC is
integrated into the cipher and the MAC tag is prepended to the payload.
This patch is inspired by the patch originally submitted by Kenny Root
on the openvpn-devel mailinglist, but does a number things differently:
* Don't support XTS (makes no sense for VPN)
* Don't support CCM (needs extra code to make it actually work)
* Don't force the user to specify "auth none" (that would break
tls-auth)
* Add support for PolarSSL (and change internal API for this)
* Update openvpn frame size ('link mtu') calculation for AEAD modes
* Use the HMAC key as an implicit part of the IV to save 8 bytes per
data channel network packet.
* Also authenticate the opcode/peer-id as AD in P_DATA_V2 packets.
By using the negotiated HMAC key as an implicit part of the IV for
AEAD-mode ciphers in TLS mode, we can save (at least) 8 bytes on each
packet sent. This is particularly interesting for connections which
transfer many small packets, such as remote desktop or voip connections.
The current AEAD-mode ciphers (for now GCM) are based on CTR-mode cipher
operation, which requires the IV to be unique (but does not require
unpredictability).
IV uniqueness is guaranteed by using a combination of at least 64-bits
of the HMAC key (unique per TLS session), and a 32-bit packet counter.
The last 32-bit word of the 128-bit cipher block is not part of the IV,
but is used as a block counter.
AEAD cipher mode is not available for static key mode, since IV
uniqueness is harder the guarantee over sessions, and I believe
supporting AEAD in static key mode too is not worth the extra
complexity. Modern setups should simply use TLS mode.
OpenSSL 1.0.1-1.0.1c will not work with AEAD mode, because those
versions have an unnecessary check that fails to update the cipher if
the tag was not already set. 1.0.1d, which fixes that, was released in
February 2013. People should have updated, and distros should have
backported the fix by now.
Changes in v2:
* Remove extra code that was just for making OpenSSL 1.0.1-1.0.1c work
in AEAD mode.
* Do not make AEAD support configurable in ./configure.
* Get rid of '12' magic constant in openvpn_encrypt_aead().
* Update manpage to explain that --auth is ignored for the data channel
when using an AEAD cipher.
* Move setting the IV in AEAD cipher modes to the IV generation code.
This is a more natural place and now we can pull iv[] into the IV
generation scope.
* Read packet ID directly from packet buffer instead of from iv buffer,
to remove the need for an extra buffer.
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <CAA1AbxL_S4umZr5Nd0VTvUvXEHjoWmji18GqM6FgmWqntOKqaA@mail.gmail.com>
URL: http://article.gmane.org/gmane.network.openvpn.devel/11162
Signed-off-by: Gert Doering <gert@greenie.muc.de>
This reworks the crypto library configuration, to make it both simpler to
understand and more usable:
* Only check for OpenSSL when building against OpenSSL (and similar for
PolarSSL/mbed TLS).
* Bail out early if a problem with the library is detected.
* Set CRYPTO_{LIBS,FLAGS} immediately after the crypto library checks,
removing the need for an extra switch-case later on.
* We no longer support building openvpn with crypto but without ssl, so
we can also simplify the logic in configure.ac accordingly.
As a 'side effect' (this actually triggered me), this fixes a bug that
would cause a user-specified OPENSSL_{CRYPTO,SSL}_LIBS to be overwritten
by AC_CHECK_LIB if there are openssl headers available in the PATH.
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1452436639-16838-1-git-send-email-steffan@karger.me>
URL: http://article.gmane.org/gmane.network.openvpn.devel/10978
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Also send it with peer-info as IV_PLAT_VER.
Signed-off-by: Lev Stipakov <lstipakov@gmail.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1451422957-23951-1-git-send-email-lstipakov@gmail.com>
URL: http://article.gmane.org/gmane.network.openvpn.devel/10904
Signed-off-by: Gert Doering <gert@greenie.muc.de>
As reported in trac #387, an x509 DN can contain duplicate fields.
Previously, we would overwrite any previous field value with a new one if
we would process a second same-name field. Now, instead, append _$N,
starting at N=1 to the name for each consequent field to export all fields
to the enviroment.
v2 - make better use of const qualifiers in env_set_get(), and use strcpy()
instead of memcpy() in setenv_str_incr()
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Selva Nair <selva.nair@gmail.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <CAA1AbxLoZpanyqfpJuroMeOj_M=gU5JB+pqZqRxYqaiNP754-g@mail.gmail.com>
URL: http://article.gmane.org/gmane.network.openvpn.devel/10654
Signed-off-by: Gert Doering <gert@greenie.muc.de>
This list is proably incomplete but should give a good starting point
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1444920298-5972-1-git-send-email-arne@rfc2549.org>
URL: http://article.gmane.org/gmane.network.openvpn.devel/10283
Signed-off-by: Gert Doering <gert@greenie.muc.de>
