[Openvpn-devel] OpenSSL version(s) officially supported by OpenVPN?

[Jonathan K. Bullard]

Hi.

Inspired by the recent discussion about LibreSSL support:

Can someone clarify which versions of OpenSSL OpenVPN supports (that
is, "works with when linked statically")?

>From what I gather:

 * OpenVPN 2.3.18 supports OpenSSL 1.0.2n
 * OpenVPN 2.4.5 supports OpenSSL 1.0.2n and 1.1.0g
 * OpenVPN 2.5 will support OpenSSL 1.0.2n and 1.1.0g

Is that correct? (I assume OpenVPN 2.5 won't remove support for
OpenSSL 1.0.2, which ends "Long Term Support" on 2019-12-31.)

Thanks in advance,

Jon Bullard (Tunnelblick developer)

PS: Tunnelblick bundles versions of OpenVPN linked with OpenSSL and
LibreSSL. I am considering including versions linked with different
OpenSSLs, too.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Improve management-external-key/cert error handling

[Selva Nair]

Hi,

On Sun, Mar 4, 2018 at 6:17 AM, Steffan Karger  wrote:
> Check the return values of management_query_cert() and
> tls_ctx_use_external_private_key(), and error out with a more descriptive
> error message.  To do so, we make the openssl-backed implementation of
> tls_ctx_use_external_private_key() not throw fatal error anymore.
>
> (And fix line wrapping while touching this code.)
>
> Signed-off-by: Steffan Karger 
> ---
>  src/openvpn/ssl.c | 29 +
>  src/openvpn/ssl_openssl.c |  2 +-
>  2 files changed, 22 insertions(+), 9 deletions(-)
>
> diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
> index 79b985e..25a7085 100644
> --- a/src/openvpn/ssl.c
> +++ b/src/openvpn/ssl.c
> @@ -660,18 +660,31 @@ init_ssl(const struct options *options, struct 
> tls_root_ctx *new_ctx)
>  else if ((options->management_flags & MF_EXTERNAL_KEY)
>   && (options->cert_file || options->management_flags & 
> MF_EXTERNAL_CERT))
>  {
> -if (options->cert_file)
> +if (options->cert_file
> +&& 0 != tls_ctx_use_external_private_key(new_ctx,
> + options->cert_file,
> + 
> options->cert_file_inline))
>  {
> -tls_ctx_use_external_private_key(new_ctx, options->cert_file,
> - options->cert_file_inline);
> +msg(M_WARN, "Failed to initialize management-external-key");

Don't we need a M_FATAL here -- similar to the M_FATAL for the same
failure below?

> +goto err;

Then this could be removed as well.

>  }
>  else
>  {
> -char *external_certificate = management_query_cert(management,
> -   
> options->management_certificate);
> -tls_ctx_use_external_private_key(new_ctx, external_certificate,
> - true);
> -free(external_certificate);
> +char *external_cert = management_query_cert(
> +management, options->management_certificate);
> +
> +if (!external_cert)
> +{
> +msg(M_FATAL, "Failed to initialize 
> management-external-cert");
> +}
> +
> +if (0 != tls_ctx_use_external_private_key(new_ctx, external_cert,
> +  true))
> +{
> +msg(M_FATAL, "Failed to initialize management-external-key");
> +}
> +
> +free(external_cert);
>  }
>  }
>  #endif
> diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
> index 66d98c5..87f6768 100644
> --- a/src/openvpn/ssl_openssl.c
> +++ b/src/openvpn/ssl_openssl.c
> @@ -1327,7 +1327,7 @@ tls_ctx_use_external_private_key(struct tls_root_ctx 
> *ctx,
>  return 0;
>
>  err:
> -crypto_msg(M_FATAL, "Cannot enable SSL external private key capability");
> +crypto_msg(M_WARN, "Cannot enable SSL external private key capability");
>  return 1;
>  }

Selva

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2] Rework OpenVPN auth-token support

[Selva Nair]

Hi,

Based on the commit message this appears to cover all that is wrong
with current auth-token implementation. I haven't carefully reviewed the
code or tested it, but some initial remarks that looks relevant.

On Mon, Mar 5, 2018 at 10:50 AM, Arne Schwabe  wrote:
> Auth-token is documented as a token that the client will use instead
> of a auth-token. When using an external auth-token script and OTP
> authentication, it is useful to have this token survive on reconnect
> (e.g. mobile device roaming).  On the other hand if the token does
> expire, the client should fall back to the previous authentication
> methd (e.g. user/pass) or ask for a OTP password again.
>
> Behaviour of OpenVPN client (prior to this patch) is to never fallback
> to the previous authentication method. Depending on auth-retry it
> either quit or tried endlessly with an expired token. Since
> auth-gen-token tokens expire on reconnect, a client will not survive a
> reconnect.

While this is mostly true, there is one point missing here. That being
the main reason for this email, here goes:

While its true that, on SIGUSR1, the client does retry with auth-token
it's only a minor nuisance:  it leads to an AUTH_FAILED and
then the client does go back to prompting for username/password
(assuming auth-retry is enabled). The real sticky problem is when
authentication fails during a TLS reneg due to an expired auth-token.
The client won't realize why the reneg did not complete and will
repeatedly try to renegotiate using the expired (or invalid) token. The
reason for this is that the server does not send back an AUTH_FAILED
message in such cases.

I want to stress this point: when the server sends back AUTH_FAILED,
the client does behave somewhat sanely, but not otherwise. And on that
count this patch appears to be lacking. It teaches the client to forget the
token during SIGUSR1 restarts which is good, but does not teach the server
to send back AUTH_FAILED in all instances of auth failures.

>
> This patch changes the client behaviour:
>
> - Treat a failed auth when using an auth-token as a soft error (USR1)
>   and clean the auth-token falling back to the original auth method

We could be more graceful here by not triggering USR1 -- clearing the
token is enough as that will automatically cause the client to fall
back to auth-user-pass prompting. I say graceful because some failures
do not need a restart, only a re-attempt to authenticate with
a valid username/password.

>
> - Implement a new pushable option forget-token-reconnect that forces
>   to forget an auth-token when reconnecting

I would have liked to see this as the default behaviour: IMO the "right"
way to use auth-token is to expire it on reconnect but if some
existing external scripts want it otherwise, fine...

>
> - Sending IV_PROTO=3 to signal that it is safe to send this client an
>   expiring auth-token

Once the server side auth-failure handling is fixed this will be less
of a concern. But a new IV_PROTO value cant hurt.

>
> The behaviour of the server option auth-gen-token:
>
> - Automatically push forget-token-reconnect to avoid a failed
>   authentication after reconnect

Yes. Unless "forget on reconnect" becomes the only possible client
behaviour :)

>
> - By default only send auth-token to clients that will gracefully
>   handle auth-token to avoid having clients not able to reconnect

I suppose this is regarding expiring tokens, not permanent tokens.

>
> - Add a force option to auth-gen-token that allow to ignore if the
>   client can handle auth-tokens
>
> Patch V2: properly formatted commit message, fix openvpn3 detection

... snipped...

> diff --git a/src/openvpn/push.c b/src/openvpn/push.c
> index 6a30e479..efe4e5a5 100644
> --- a/src/openvpn/push.c
> +++ b/src/openvpn/push.c
> @@ -53,25 +53,31 @@ receive_auth_failed(struct context *c, const struct 
> buffer *buffer)
>  msg(M_VERB0, "AUTH: Received control message: %s", BSTR(buffer));
>  c->options.no_advance = true;
>
> -if (c->options.pull)
> -{
> -switch (auth_retry_get())
> +if (c->options.pull) {
> +/* Before checking how to react on AUTH_FAILED, first check if the 
> failed authed might be
> + * the result of an expired auth-token */
> +if (ssl_clean_auth_token())
>  {

This is not going to work. The only time the server sends back
AUTH_FAILED is during the initial connection. See that
send_auth_failed() is called only during PUSH request processing[*].
So, failure due to token expiry that normally happens during a reneg[*]
will not trigger AUTH_FAILED and the client will continue trying reneg
until the previous TLS session expires (1 hour?). This is a
basic limitation of the present implementation and I do not see it
being addressed by the patch.

Other than this, the patch is looking good.

Selva
[*] Unless management-client-auth is in use.

--
Check out the vibrant t

Re: [Openvpn-devel] [PATCH] Avoid overflow in wakeup time computation

[Steffan Karger]

Hi,

On 06-03-18 07:09, selva.n...@gmail.com wrote:
> From: Selva Nair 
> 
> Time interval arithmetic can overflow especially when user
> defined intervals are involved. E.g., see Trac #922.
> 
> Avoid this by reordering the arithmetic operation in
> event_timeout_trigger(). Also avoid unnecessary casting of time
> variable to int.
> 
> Time until wakeup is now calculated like:
> 
> time_t wakeup = (last - now) + delay
> 
> Here delay is of type int, but is +ve by construction. Time backtrack
> protection in OpenVPN ensures (last - now) <= 0. Then the above
> expression cannot overflow (provided time_t is at least as large
> as int).
> 
> A similar expression in interval.h is also changed.
> 
> (This patch grew out of patch 168 by Steffan Karger.)
> 
> Signed-off-by: Selva Nair 
> ---
>  src/openvpn/interval.c | 8 +---
>  src/openvpn/interval.h | 2 +-
>  2 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/src/openvpn/interval.c b/src/openvpn/interval.c
> index 00ee627..b728560 100644
> --- a/src/openvpn/interval.c
> +++ b/src/openvpn/interval.c
> @@ -51,11 +51,12 @@ event_timeout_trigger(struct event_timeout *et,
>  
>  if (et->defined)
>  {
> -int wakeup = (int) et->last + et->n - local_now;
> +time_t wakeup = et->last - local_now + et->n;

I would have preferred braces to not have any doubt about associativity,
but can live with this.  (I always forget, so had to look up what C did
again.)

>  if (wakeup <= 0)
>  {
>  #if INTERVAL_DEBUG
> -dmsg(D_INTERVAL, "EVENT event_timeout_trigger (%d) etcr=%d", 
> et->n, et_const_retry);
> +dmsg(D_INTERVAL, "EVENT event_timeout_trigger (%d) etcr=%d", 
> et->n,
> + et_const_retry);
>  #endif
>  if (et_const_retry < 0)
>  {
> @@ -72,7 +73,8 @@ event_timeout_trigger(struct event_timeout *et,
>  if (tv && wakeup < tv->tv_sec)
>  {
>  #if INTERVAL_DEBUG
> -dmsg(D_INTERVAL, "EVENT event_timeout_wakeup (%d/%d) etcr=%d", 
> wakeup, et->n, et_const_retry);
> +dmsg(D_INTERVAL, "EVENT event_timeout_wakeup (%d/%d) etcr=%d",
> + (int) wakeup, et->n, et_const_retry);
>  #endif
>  tv->tv_sec = wakeup;
>  tv->tv_usec = 0;
> diff --git a/src/openvpn/interval.h b/src/openvpn/interval.h
> index 826a08b..5623f3a 100644
> --- a/src/openvpn/interval.h
> +++ b/src/openvpn/interval.h
> @@ -196,7 +196,7 @@ event_timeout_modify_wakeup(struct event_timeout *et, 
> interval_t n)
>  static inline interval_t
>  event_timeout_remaining(struct event_timeout *et)
>  {
> -return (int) et->last + et->n - now;
> +return (interval_t) (et->last - now + et->n);
>  }
>  
>  /*
> 

As discussed, an elegant way of solving the issue (verified manually
with -fsanitize=undefined).

Acked-by: Steffan Karger 

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] Topics for the community meeting (Wed, 7th Mar 2018)

[Samuli Seppänen]

Hi,

We're going to have an IRC meeting starting at 11:30 CET
(10:30 UTC) on #openvpn-meeting  irc.freenode.net. You do not have
to be logged in to Freenode to join the channel.

Current topic list along with basic information is here:



If you have any other things you'd like to bring up, respond to this
mail, send me mail privately or add them to the list yourself.

In case you can't attend the meeting, please feel free to make comments
on the topics by responding to this email or to the summary email sent
after the meeting. Whenever possible, we'll also respond to existing,
related email threads.

--
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel