aboutsummaryrefslogtreecommitdiff
path: root/Changes.rst
AgeCommit message (Collapse)Author
2017-11-19Add --tls-cert-profile option.Steffan Karger
This allows the user to specify what certificate crypto algorithms to support. The supported profiles are 'preferred', 'legacy' (default) and 'suiteb', as discussed in <84590a17-1c48-9df2-c48e-4160750b2e33@fox-it.com> (https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14214. html). This fully implements the feature for mbed TLS builds, because for mbed it is both more easy to implement and the most relevant because mbed TLS 2+ is by default somewhat restrictive by requiring 2048-bit+ for RSA keys. For OpenSSL, this implements an approximation based on security levels, as discussed at the hackathon in Karlsruhe. This patch uses 'legacy' as the default profile following discussion on the openvpn-devel mailing list. This way this patch can be applied to both the release/2.4 and master branches. I'll send a follow-up patch for the master branch to change the default to 'preferred' later. Signed-off-by: Steffan Karger <steffan.karger@fox-it.com> Acked-by: Antonio Quartulli <antonio@openvpn.net> Message-Id: <20171112163636.17434-1-steffan@karger.me> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg15848.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
2017-11-03Remove references to keychain-mcd in Changes.rstDavid Sommerseth
In commit 59e7e9fce8de6ea90d13baeaede83adc0b594e22 the contrib/keychain-mcd code was completely removed. But it was not removed from Changes.rst. Signed-off-by: David Sommerseth <davids@openvpn.net> Acked-by: Gert Doering <gert@greenie.muc.de> Message-Id: <20171005212223.24694-1-davids@openvpn.net> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg15561.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
2017-08-17Use consistent version referencesDavid Sommerseth
A simple clean-up where the version references have been unified all those places I could find now. The versioning scheme used is: * OpenVPN 2.x * v2.x We want to avoid: * 2.x (2.4 can be just an ordindary decimal number, OID reference, a version number or anything else) * OpenVPN v2.x (OpenVPN indicates we're talking about a version) In addition, several places where it made sense I tried to ensure the first version reference uses "OpenVPN 2.x" and the following references in the same section/paragraph uses "v2.x", to set the context for the version reference. In Changes.rst modified paragraphs exceeding 80 chars lines where reformatted as well. Signed-off-by: David Sommerseth <davids@openvpn.net> Acked-by: Steffan Karger <steffan@karger.me> Message-Id: <20170815205301.14542-1-davids@openvpn.net> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg15260.html Signed-off-by: David Sommerseth <davids@openvpn.net>
2017-08-17Highlight deprecated featuresDavid Sommerseth
We have quite a list of deprecated options currently. Ensure this is highlighted both in documentation and code. This patch builds on the wiki page [1] enlisting all deprecated features and their status. There are also some options not listed here, as there exists patches in release/2.4 which awaits an update for git master. [1] https://community.openvpn.net/openvpn/wiki/DeprecatedOptions Signed-off-by: David Sommerseth <davids@openvpn.net> Acked-by: Steffan Karger <steffan@karger.me> Message-Id: <20170815215451.21662-1-davids@openvpn.net> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg15261.html Signed-off-by: David Sommerseth <davids@openvpn.net>
2017-08-15Deprecate --keysizeSteffan Karger
The --keysize option can only be used with already deprecated ciphers, such as CAST5, RC2 or BF. Deviating from the default keysize is generally not a good idea (see man page text), and otherwise only complicates our code. Since we will also remove the support for weak ciphers (ciphers with cipher block length less than 128 bits) in OpenVPN 2.6 as well, we start the deprecation of this option instantly. [DS: Slightly amended the patch, referencing OpenVPN 2.6 and added a few more details to Changes.rst and the commit message] Signed-off-by: Steffan Karger <steffan@karger.me> Acked-by: David Sommerseth <davids@openvpn.net> Message-Id: <20170701112951.19119-1-steffan@karger.me> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg15004.html Signed-off-by: David Sommerseth <davids@openvpn.net>
2017-06-29doc: The CRL processing is not a deprecated featureDavid Sommerseth
The note related to the CRL processing was somehow put into the deprecated section. This is quite confusing. Since this is a fairly important change, and there have been a noticable amount of supports questions related to OpenVPN not starting due to CRL errors, I put this into the "New features" section labelled as an improvement. Otherwise I fear this would drown in the list of "User-visible Changes" later on. Signed-off-by: David Sommerseth <davids@openvpn.net> Acked-by: Steffan Karger <steffan.karger@fox-it.com> Message-Id: <20170628191538.9135-1-davids@openvpn.net> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14985.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
2017-06-20Update Changes.rst with relevant info for 2.4.3 release.Gert Doering
(Since Changes.rst is mostly synchronized between master and 2.4.3, and patches flow master->release/2.4, the change is done here even if this particular commit is not directly part of 2.4.3 release) General cleanup, whitespace fixes, quoting fixes by David Sommerseth <davids@openvpn.net> Signed-off-by: Gert Doering <gert@greenie.muc.de>
2017-06-19Fix potential double-free in --x509-alt-username (CVE-2017-7521)Steffan Karger
We didn't check the return value of ASN1_STRING_to_UTF8() in extract_x509_extension(). Ignoring such a failure could result in buf being free'd twice. An error in ASN1_STRING_to_UTF8() can be caused remotely if the peer can make the local process run out of memory. The problem can only be triggered for configurations that use the --x509-alt-username option with an x509 extension (i.e. the option parameter starts with "ext:"). This issue was discovered, analysed and reported to the OpenVPN team by Guido Vranken. Extensive testing by Guido Vranken gives confidence that this function is very unlikely to fail in real-world usage (using subjectAltName or issuerAltName extensions) for other reasons than memory exhaustion. CVE: 2017-7521 Signed-off-by: Steffan Karger <steffan.karger@fox-it.com> Acked-by: Gert Doering <gert@greenie.muc.de> Acked-by: David Sommerseth <davids@openvpn.net> Acked-by: Guido Vranken <guidovranken@gmail.com> Message-Id: <1497864520-12219-6-git-send-email-steffan.karger@fox-it.com> URL: https://www.mail-archive.com/search?l=mid&q=1497864520-12219-6-git-send-email-steffan.karger@fox-it.com Signed-off-by: Gert Doering <gert@greenie.muc.de>
2017-06-19Restrict --x509-alt-username extension typesSteffan Karger
The code never supported all extension types. Make this explicit by only allowing subjectAltName and issuerAltName (for which the current code does work). Using unsupported extension fields would most likely cause OpenVPN to crash as soon as a client connects. This does not have a real-world security impact, as such a configuration would not be possible to use in practice. This bug was discovered, analysed and reported to the OpenVPN team by Guido Vranken. Signed-off-by: Steffan Karger <steffan.karger@fox-it.com> Acked-by: Gert Doering <gert@greenie.muc.de> Acked-by: David Sommerseth <davids@openvpn.net> Acked-by: Guido Vranken <guidovranken@gmail.com> Message-Id: <1497864520-12219-5-git-send-email-steffan.karger@fox-it.com> URL: https://www.mail-archive.com/search?l=mid&q=1497864520-12219-5-git-send-email-steffan.karger@fox-it.com Signed-off-by: Gert Doering <gert@greenie.muc.de>
2017-06-19Fix remote-triggerable memory leaks (CVE-2017-7521)Steffan Karger
Several of our OpenSSL-specific certificate-parsing code paths did not always clear all allocated memory. Since a client can cause a few bytes of memory to be leaked for each connection attempt, a client can cause a server to run out of memory and thereby kill the server. That makes this a (quite inefficient) DoS attack. When using the --x509-alt-username option on openssl builds with an extension (argument prefixed with "ext:", e.g. "ext:subjectAltName"), the code would not free all allocated memory. Fix this by using the proper free function. If ASN1_STRING_to_UTF8() returns 0, it didn't fail and *did* allocate memory. So also free the returned buffer if it returns 0. These issues were found, analysed and reported to the OpenVPN team by Guido Vranken. CVE: 2017-7521 Signed-off-by: Steffan Karger <steffan.karger@fox-it.com> Acked-by: Gert Doering <gert@greenie.muc.de> Acked-by: David Sommerseth <davids@openvpn.net> Acked-by: Guido Vranken <guidovranken@gmail.com> Message-Id: <1497864520-12219-4-git-send-email-steffan.karger@fox-it.com> URL: https://www.mail-archive.com/search?l=mid&q=1497864520-12219-4-git-send-email-steffan.karger@fox-it.com Signed-off-by: Gert Doering <gert@greenie.muc.de>
2017-06-19mbedtls: fix --x509-track post-authentication remote DoS (CVE-2017-7522)Steffan Karger
asn1_buf_to_c_string() returned a literal string if the input ASN.1 string contained a NUL character, while the caller expects a mutable string. The caller will attempt to change this string, which allows a client to crash a server by sending a certificate with an embedded NUL character. (The other way around is not interesting, as servers are allowed to stop a client by design.) Impact analysis: * applies to mbedtls builds only * introduced in 2.4 (so 2.3 is not affected) * can only be exploited if the --x509-track option is used * requires the CA to sign a certificate with an embedded NUL in the certificate subject This bug was discovered and reported to the OpenVPN security team by Guido Vranken. CVE: 2017-7522 Signed-off-by: Steffan Karger <steffan.karger@fox-it.com> Acked-by: Gert Doering <gert@greenie.muc.de> Message-Id: <1497864520-12219-2-git-send-email-steffan.karger@fox-it.com> URL: https://www.mail-archive.com/search?l=mid&q=1497864520-12219-2-git-send-email-steffan.karger@fox-it.com Signed-off-by: Gert Doering <gert@greenie.muc.de>
2017-06-18Fix mbedtls fingerprint calculationSteffan Karger
Commit 'Migrate to mbed TLS 2.x' (86d8cd68) introduced a bug in mbedtls builds where we would calculate the certificate fingerprint over the (too-short) 'to-be-signed' length of the certificate, rather than over the certificate including the signature. Fix that. The security impact of the incorrect calculation is very minimal; the last few bytes (max 4, typically 4) are not verified by the fingerprint. We expect no real-world impact, because users that used this feature before will notice that it has suddenly stopped working, and users that didn't will notice that connection setup fails. Even if the user managed to somehow extract the incorrect hash (e.g. by reading out the tls_digest_* env vars using a --tls-verify script), the impact is miminal: the last 4 bytes must still be properly signed by the CA, and typically contain extension fields, or the last bytes of the public key (which are hard to choose). The most important bits of the certificate were always checked: the version, serial, signature algorithm, issuer, validity and subject. Signed-off-by: Steffan Karger <steffan@karger.me> Acked-by: Arne Schwabe <arne@rfc2549.org> Message-Id: <1495285075-4957-1-git-send-email-steffan@karger.me> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14711.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
2017-05-18crypto: Enable SHA256 fingerprint checking in --verify-hashDavid Sommerseth
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>
2017-05-11Drop packets instead of assert out if packet id rolls over (CVE-2017-7479)Steffan Karger
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>
2017-05-11Don't assert out on receiving too-large control packets (CVE-2017-7478)Steffan Karger
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>
2017-05-08Fix memory leak in x509_verify_cert_ku()Steffan Karger
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>
2017-05-05Fix Changes.rst layoutSteffan Karger
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>
2017-03-19Be less picky about keyUsage extensionsSteffan Karger
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>
2017-03-19Deprecate --ns-cert-typeSteffan Karger
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>
2016-12-27Textual fixes for Changes.rstSteffan Karger
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>
2016-12-24docs: Further enhance the documentation related to SWEET32David Sommerseth
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
2016-12-14Changes.rst: Mainatiner update on C99David Sommerseth
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>
2016-12-14Further enhance async-push feature descriptionDavid Sommerseth
Signed-off-by: David Sommerseth <davids@openvpn.net> Acked-by: Steffan Karger <steffan.karger@fox-it.com> Message-Id: <1481718210-15673-1-git-send-email-davids@openvpn.net> URL: http://www.mail-archive.com/search?l=mid&q=1481718210-15673-1-git-send-email-davids@openvpn.net
2016-12-09Changes: Further improve systemd unit file updatesDavid Sommerseth
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>
2016-12-07Deprecate --no-ivSteffan Karger
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>
2016-12-07Fix (and cleanup) crypto flags in combination with NCPSteffan Karger
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>
2016-12-07Add "async push" feature to Changes.rstLev Stipakov
[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>
2016-12-02Preparing OpenVPN v2.4_rc1 releasev2.4_rc1David Sommerseth
Signed-off-by: David Sommerseth <davids@openvpn.net>
2016-12-01reload CRL only if file was modifiedAntonio Quartulli
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>
2016-12-01Do not restart dns client service as a part of --register-dns processingSelva Nair
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>
2016-11-30Force 'def1' method when --redirect-gateway is done through serviceSelva Nair
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>
2016-11-28Fix windows path in Changes.rstGert Doering
Escape backslash characters in windows path names. Signed-off-by: Gert Doering <gert@greenie.muc.de> Acked-by: Selva Nair <selva.nair@gmail.com> Message-Id: <1480360012-9479-1-git-send-email-gert@greenie.muc.de> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13274.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
2016-11-24Preparing OpenVPN v2.4_beta2 releasev2.4_beta2David Sommerseth
This also adds a few missing details from Changes.rst Signed-off-by: David Sommerseth <davids@openvpn.net>
2016-11-18Changes.rst: Fixing wrong formattingDavid Sommerseth
Some places tabs had snuck in instead of spaces, making the rendering on GitHub odd. Signed-off-by: David Sommerseth <davids@openvpn.net>
2016-11-16options: Remove --tls-remoteDavid Sommerseth
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 9f0fc745664fd0 (release/2.3: f6e12862cefd054eb1). 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>
2016-11-16Add control channel encryption (--tls-crypt)Steffan Karger
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>
2016-11-16Refactor CRL handlingSteffan Karger
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>
2016-11-14Deprecate key-method 1Steffan Karger
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>
2016-11-04Drop recursively routed packetsLev Stipakov
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>
2016-10-31auth-gen-token: Add --auth-gen-token optionDavid Sommerseth
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
2016-10-28Make Changes.rst nicer for 2.4 releaseArne Schwabe
- 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>
2016-10-14Remove tun-ipv6 Option. Instead assume that IPv6 is always supported.Arne Schwabe
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>
2016-07-25Add server-side support for cipher negotiationSteffan Karger
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>
2016-07-11Exponentially back off on repeated connect retriesSelva Nair
- 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>
2016-06-24Remove http-proxy-retry and socks-proxy-retry.Arne Schwabe
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>
2016-06-20Add documentation for http-proxy-user-pass optionArne Schwabe
Patch V2: fix formatting problems Acked-by: Selva Nair <selva.nair@gmail.com> Message-Id: <1466167786-13748-1-git-send-email-arne@rfc2549.org> URL: http://article.gmane.org/gmane.network.openvpn.devel/11933 Signed-off-by: Gert Doering <gert@greenie.muc.de>
2016-06-11Remove http-proxy-timeout, socks timeout and set default of ↵Arne Schwabe
server-poll-timeout to 120s 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>
2016-06-07Add an option to filter options received from serverSelva Nair
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>
2016-05-16Implement push-remove option to selectively remove pushed options.Gert Doering
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>
2016-05-05mbedtls: improve error reporting in tls verify callbackSteffan Karger
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>
generated by cgit v1.1 at 2024-10-07 02:13:09 +0000