Do not pass struct tls_session* as void* in key_state_ssl_init().

Signed-off-by: Steffan Karger <steffan.karger@fox-it.com>
Acked-by: David Sommerseth <davids@redhat.com>
Message-Id: 51B1DBEF.1090705@fox-it.com
URL: http://article.gmane.org/gmane.network.openvpn.devel/7664
Signed-off-by: David Sommerseth <davids@redhat.com>
(cherry picked from commit b97e2c3c90afdbb1a24bc1357ec6b94d626defcd)
Add support for client-cert-not-required for PolarSSL.

Signed-off-by: Tamas TEVESZ <ice@extreme.hu>
Acked-by: Steffan Karger <steffan.karger@fox-it.com>
Message-Id: alpine.GSO.2.03.1306080732510.23277@extreme.hu
URL: http://article.gmane.org/gmane.network.openvpn.devel/7667
Signed-off-by: David Sommerseth <davids@redhat.com>
(cherry picked from commit a781d6714758489a808b55cdefc1d1623194e318)
Add support of utun devices under Mac OS X

Mac OS X 10.7+ natively supports tun devices (called utun). The "standard"
utun.ko driver is sometimes problematic (e.g. VmWare Fusion 5 and tun.ko
do not work together).

When OpenVPN is compiled with utun support it will if no dev-node is given
first try to use utun and if that is not available will try the
traditional tun devices

v2: Fixed tap support, get device name via ioctl, add manage
v3.1: Fix compiling without if/utun.h, fix manage errors
v4/v5: Don't try open to dynamically open utun0 -255 when early utun
initialization fails, fix fallback to tun, give fatal error message when
utun fails but no tun fallback should be done
v6: add commit message change log, replace strstr with strncmp, move
v7: Throw error if a user does the strange combination of --dev tun
--dev-type tap and --dev-node utun

A lot good input on earlier patches by Jonathan K. Bullard
<jkbullard@gmail.com>

Parts of the patches are inspired from Peter Sagerson's
<psagers@ignorare.net> utun patch
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Tested-by: Jonathan K. Bullard <jkbullard@gmail.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1371811708-8528-1-git-send-email-arne@rfc2549.org>
URL: http://article.gmane.org/gmane.network.openvpn.devel/7739
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit fbc04bedbcce02fc625357b7475ddbc7164cabbf)
man page: Update man page about the tls_digest_{n} environment variable

Signed-off-by: David Sommerseth <davids@redhat.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1370600111-5983-1-git-send-email-dazo@users.sourceforge.net>
URL: http://article.gmane.org/gmane.network.openvpn.devel/7659
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit ace54e9b3c26c4d13fd278fac2d2dc37138270e4)
Remove the --disable-eurephia configure option

This "feature" has been enabled since OpenVPN 2.2 without any reports that
this has been causing issues.  All it does is to add an extra environment
variable 'tls_digest_{n}' with the certificate SHA1 fingerprint/digest
hash.

Lets just simplify things by removing the possibility to disable this
environment variable.

Signed-off-by: David Sommerseth <davids@redhat.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1370600123-6029-1-git-send-email-dazo@users.sourceforge.net>
URL: http://article.gmane.org/gmane.network.openvpn.devel/7660
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit e3d388652f59fd2ddd9c7f470f7ef62ee6b35595)
plugin: Extend the plug-in v3 API to identify the SSL implementation used

OpenVPN would segfault unexpectedly if it would be compiled against
PolarSSL
and the plug-in would expect OpenSSL, or vice-versa.  This segfault would
not appear before the plug-in would try to access functions which would
be available if the plug-in and OpenVPN uses the same SSL implementation.

This patch adds a member to the plug-in initialisation function, which
identifies the SSL implementation.

The log_v3 plug-in is updated accordingly + a simple fix to make it
buildable again using the ./build script.

A minor documentation error in the openvpn-plugin.h was also
corrected, where it mentioned OPENVPN_PLUGIN_VERSION instead of
OPENVPN_PLUGINv3_STRUCTVER.

 v2 - add const ovpnSSLAPI ssl_api at the end of
      struct openvpn_plugin_args_open_in and not in the "middle"

 v3 - fix bug in plug-in init, as the SSLAPI was located wrong in the
      args struct sent to the openvpn_plugin_open_v3() function.

 v4 - Ensure SSLAPI got a sane/known value if SSL is disabled or unknown

Signed-off-by: David Sommerseth <davids@redhat.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1372879030-10576-1-git-send-email-dazo@users.sourceforge.net>
URL: http://article.gmane.org/gmane.network.openvpn.devel/7754
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 587df08abda3c8f1f85ccdba4d8b82a736c11e2d)
autoconf: Fix typo

In config.h, it would state:

      /* Enable systemd support */
      #define ENABLE_PLUGIN 1

instead of

      /* Enable plug-in support */
      #define ENABLE_PLUGIN 1

Signed-off-by: David Sommerseth <davids@redhat.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1370600130-6075-1-git-send-email-dazo@users.sourceforge.net>
URL: http://article.gmane.org/gmane.network.openvpn.devel/7658
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 8065cd1c65273ef05ba2ac66f15224e170a57290)
TLS version negotiation

Updated the TLS negotiation logic to adaptively try to connect using
the highest TLS version supported by both client and server.
Previously, OpenVPN (when linked with OpenSSL) would always connect
using TLS 1.0.

Also added tls-version-min directive to force a higher TLS version
than 1.0:

tls-version-min <version> ['or-highest'] -- sets the minimum
TLS version we will accept from the peer.  Examples for version
include "1.0" (default), "1.1", or "1.2".  If 'or-highest' is
specified and version is not recognized, we will only accept
the highest TLS version supported by the local SSL implementation.

Examples:

tls-version-min 1.1 -- fail the connection unless peer can
  connect at TLS 1.1 or higher.

tls-version-min 1.2 or-highest -- require that the peer
  connect at TLS 1.2 or higher, however if the local SSL
  implementation doesn't support TLS 1.2 (as it wouldn't
  if linked with an older version of OpenSSL), reduce the
  minimum required version to the highest version supported
  by the local SSL implementation (such as TLS 1.0).  This
  is intended to allow client configurations to target higher
  TLS versions that are supported on the server, even if some
  older clients don't support these versions yet.

 [
    This is a merged patch from on the following commits
    on git://github.com/jamesyonan/openvpn.git

    03a5599202bdc3ba07983dc4efdae387fb8fb436
    d23005413b0e0f28a3c48a6342f494763d5c9b40
 ]

Signed-off-by: James Yonan <james@openvpn.net>
Acked-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Arne Schwabe <arne@rfc2549.org>
URL: http://thread.gmane.org/gmane.network.openvpn.devel/7743
URL: http://thread.gmane.org/gmane.network.openvpn.devel/7744
Message-Id: 51C77F12.1090802@openvpn.net
Signed-off-by: David Sommerseth <davids@redhat.com>

(cherry picked from commit 4b67f9849ab3efe89268e01afddc7795f38d0f64)
Signed-off-by: Gert Doering <gert@greenie.muc.de>

Conflicts:
	src/openvpn/ssl_common.h
Added "setenv opt" directive prefix.  If present, and if the
directive that follows is recognized, it will be processed
as if the "setenv opt" prefix was absent.  If present and if
the directive that follows is not recognized, the directive
will be ignored rather than cause a fatal error.

For example, suppose you are distributing a client
configuration file and want to set the minimum TLS version
that the client requires from the server to 1.2.

By using the following directive,

  setenv opt tls-version-min 1.2 or-highest

only newer clients that understand the tls-version-min directive
would process it, while older clients would ignore it.

(cherry picked from commit 27713761e4110bb92f1c6dfe85db291e8c6e0f56)

Signed-off-by: James Yonan <james@openvpn.net>
URL: http://thread.gmane.org/gmane.network.openvpn.devel/7771
URL: http://thread.gmane.org/gmane.network.openvpn.devel/7744
URL: https://github.com/jamesyonan/openvpn/commit/27713761e4110bb92f1c6dfe85db291e8c6e0f56
Acked-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Gert Doering <gert@greenie.muc.de>
Signed-off-by: David Sommerseth <davids@redhat.com>
(cherry picked from commit 2a92fba756d4c1e73300a12ff9e80028a6ab7c09)

Signed-off-by: Gert Doering <gert@greenie.muc.de>
Add support to ignore specific options.

Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1376640664-26379-1-git-send-email-arne@rfc2549.org>
URL: http://article.gmane.org/gmane.network.openvpn.devel/7799

Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit b685a1e6b012682ce7d6fb31960273b8f5213714)
Add a note what setenv opt does for OpenVPN < 2.3.3

Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1376640680-26468-1-git-send-email-arne@rfc2549.org>
URL: http://article.gmane.org/gmane.network.openvpn.devel/7798

Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 39dad37d5b13c4dc0614ab7b19fdae88c23de0a2)
Always load intermediate certificates from a PKCS#12 file

Load intermediate certificates from a PKCS#12 file and place them in the
extra certs chain, when trusted CA certs are loaded from an external PEM
file with the --ca option, and the CA certs in PKCS#12 are not to be trusted.

Required when client PKCS#12 file is provided by a different CA
than the server CA, the PKCS#12 file contains intermediate certificates
required for client auth, but the server CA is not in the PKCS#12 file.

When --ca is set, the PKCS#12 provided CA certs are not trusted. Without
this patch, they were ignored completely - with this patch, they're loaded
in the extra certs chain which makes them available for chain verification
but still does not make them trusted if --ca is set. Unless when, of
course, a trusted root is found from the --ca file.

Acked-by: James Yonan <james@openvpn.net>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Steffan Karger <steffan.karger@fox-it.com>
Message-Id: <alpine.DEB.2.02.1306201400320.10116@jazz.he.fi>
URL: http://article.gmane.org/gmane.network.openvpn.devel/7721

Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 6481f879eb62cafa6ad652801b2b5c45e546ef44)
Correct error text when no Windows TAP device is present

Starting with the 2.3-series, the TAP-Windows driver/utilities and
OpenVPN are separately installed components. The error message given to
users without available TAP devices uses the pre-2.3 path that does not
exist. The path should be listed under the TAP-Windows program group
that the tap-windows project installer uses.

Resolves bug #320

Signed-off-by: Josh Cepek <josh.cepek@usa.net>
Acked-by: David Sommerseth <dazo@users.sourceforge.net>
Message-Id: <kv4ece$s8s$1@ger.gmane.org>
URL: http://article.gmane.org/gmane.network.openvpn.devel/7825
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 2d34628af995676c8ecddb953897c334b96a6a6b)
Fix configure interaction with static OpenSSL libraries

Add "-lcrypto" to configure OpenSSL "-lssl" test (if no pkg-config
found), otherwise linking with static OpenSSL libraries will fail.

Trac ticket #305

Message-Id: <521668C9.5070003@openvpn.net>
URL: http://article.gmane.org/gmane.network.openvpn.devel/7835
URL: https://community.openvpn.net/openvpn/ticket/305
Acked-By: Heiko Hund <heiko.hund@sophos.com>
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 30e358e5de352c8de04a955dc89f33e1710e9b97)