Re: [Openvpn-devel] [PATCH] Remove --no-replay

[David Sommerseth]

On 16/05/2021 19:14, Arne Schwabe wrote:

First of all, I do like Steffan's proposal:

> Remove the option, and:
>  * if auth != none -> replay prevention is always enabled;
>  * if auth == none -> replay prevention is disabled.

And with "remove the option", if it exists in a config, it should be 
considered a NOOP.


Then on compatibility ...


Given 2, how clear is our timeline on sunsetting non-AEAD ciphers? That
would automatically sunset --no-replay. (I've lost track a bit...)


Heated debate as that is equal to drop compatibility completely with
OpenVPN 2.3. We have already a heated debate if dropping 2.3 config
compatibility is possible or not (e.g. you need to add ciphers to
data-ciphers to still to connect to a 2.3 peer).


Just to be clear, since I have been involved in several of these 
discussions.  I consider 2.3 dead.  I care about 2.4 and upwards, based 
on the agreement we had long time ago about which versions we want to 
support [0].  2.3 is now in git-only support and we have only promised 
that support level until end of June (essentially ~6 more weeks).


[0] 

For me, I care only about 2.4 and newer at this point.  If someone 
desperately need to support 2.3 clients, it is not our task to provide 
such support.  If someone need a 2.6 client to connect to a 2.3 server, 
that is also not our task to provide.  If 2.3 is so badly needed, you 
cannot expect to blend in 2.6 without issues.


We cannot be held hostage due to our users incapability to upgrade, even 
when related to hardware.  Our current support time is quite reasonable, 
where we go from full -> old stable -> git-only -> unsupported which 
takes about 2.5 year.  If a site cares about their VPN setup, that is 
more than long enough time to plan and deploy an upgrade.  *And* it is 
the distributor itself who must carry the main support burden if they 
decide to support versions not supported by the upstream project.  So 
for LTS distributions, it is the LTS distribution providing the packages 
which defines when their LTS distribution goes EOL - and they support 
the packages they provide in that LTS distribution.


That said, we can strive to support older versions, but we should not 
spend lots of time and energy supporting it just for the sake of 
supporting it.



What I do care about is that _client_ configuration files targetted for 
_2.4_ clients can connect to 2.4 and newer servers without modifying the 
configuration files.  But I am at the same time willing to accept that 
DCO will change that game.  Also, if a site has deployed a server 
configuration for 2.5 or 2.6 explicitly and have accordingly scoped 
their client configuration for the same version, supporting older 
clients should _not_ be expected to work.  But for existing 2.4 servers, 
we should not break configurations on 2.4 or newer clients.  So 
basically, 2.4/2.5/2.6 should be able to work out-of-the-box without any 
changes, regardless of versions.


However, if connecting to a *DCO enabled host*, updating client 
configurations *is* acceptable *because* that is a completely new 
technology which is not targetting everything 2.4 supports by design 
*and* _not_ making use of DCO will still work.


For sites wanting to support both DCO and non-DCO, we could consider 
looking into ensuring that connection-blocks can be used where the 
server side will have an openvpn server running with DCO and another one 
without DCO.  This means adding DCO on an already existing server could 
be done using a different port or IP address (--local).  Unless we want 
ovpn-dco to be able to be a simple and passive forwarder of both control 
and data channel packets if the configuration is not DCO compliant.


The challenge is that cipher/auth settings cannot be in a connection 
block, which means the current behaviour in 2.4 need to be preserved, 
unless we can push settings (NCP and related).  It is also acceptable to 
me that clients may ignore local cipher/auth settings which can be 
pushed from the server.


But I also do know NCP is a bit tricky with the current DCO 
implementation, where this needs to be settled on a DCO supported cipher 
before connecting.  Maybe we should consider a similar approach to 
OpenVPN 3, where the tun/DCO interface is setup *after* the connection 
to the server has been established with the PUSH_REPLY received and pass 
UDP/TCP socket to ovpn-dco at that point *if* the server side 
cipher/auth/compression is compliant with DCO?  (Otherwise, use a tun 
interface)




--
kind regards,

David Sommerseth
OpenVPN Inc



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2 10/11] Implement --client-crresponse script options and plugin interface

[Gert Doering]

Hi,

On Mon, Jan 25, 2021 at 01:56:27PM +0100, Arne Schwabe wrote:
> This is allows scripts and pluginsto parse/react to a
> CR_RESPONSE message
> 
> Patch V2: doc fixes, do not put script under ENABLE_PLUGIN

This one was left out to try for too long (sorry), and is no more applying 
in a fairly big way...

error: patch failed: include/openvpn-plugin.h.in:84
error: include/openvpn-plugin.h.in: patch does not apply
error: patch failed: src/openvpn/init.c:2948
error: src/openvpn/init.c: patch does not apply
error: patch failed: src/openvpn/options.c:1284
error: src/openvpn/options.c: patch does not apply
error: patch failed: src/openvpn/options.h:440
error: src/openvpn/options.h: patch does not apply
error: patch failed: src/openvpn/push.c:228
error: src/openvpn/push.c: patch does not apply
error: patch failed: src/openvpn/ssl_common.h:316
error: src/openvpn/ssl_common.h: patch does not apply
error: patch failed: src/openvpn/ssl_verify.c:1232
error: src/openvpn/ssl_verify.c: patch does not apply
error: patch failed: src/openvpn/ssl_verify.h:209
error: src/openvpn/ssl_verify.h: patch does not apply

I assume you have a rebased version in your tree... can you resend
this one, please?

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Remove --no-replay

[Arne Schwabe]

> 
> Given 2, how clear is our timeline on sunsetting non-AEAD ciphers? That
> would automatically sunset --no-replay. (I've lost track a bit...)

Heated debate as that is equal to drop compatibility completely with
OpenVPN 2.3. We have already a heated debate if dropping 2.3 config
compatibility is possible or not (e.g. you need to add ciphers to
data-ciphers to still to connect to a 2.3 peer).

Arne


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Change CTR DRBG update function call to new mbedtls 2.16.0 API

[Steffan Karger]

Hi,

On 06-04-2021 12:55, Maximilian Fillinger wrote:
>> Am 02.04.21 um 15:26 schrieb Max Fillinger:
>>> From: Uipko Berghuis 
>>>
>>> In mbedtls 2.16.0 mbedtls_ctr_drbg_update() changed to
>>> mbedtls_ctr_drbg_update_ret(). Change the function name and handle the
>>> new return value error code.
>>> ---
>>>  src/openvpn/ssl_mbedtls.c | 5 -
>>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/openvpn/ssl_mbedtls.c b/src/openvpn/ssl_mbedtls.c
>>> index 5d7af351..56e9f045 100644
>>> --- a/src/openvpn/ssl_mbedtls.c
>>> +++ b/src/openvpn/ssl_mbedtls.c
>>> @@ -950,7 +950,10 @@ tls_ctx_personalise_random(struct tls_root_ctx
>>> *ctx)
>>>
>>>  if (0 != memcmp(old_sha256_hash, sha256_hash,
>> sizeof(sha256_hash)))
>>>  {
>>> -mbedtls_ctr_drbg_update(cd_ctx, sha256_hash, 32);
>>> +if (!mbed_ok(mbedtls_ctr_drbg_update_ret(cd_ctx,
>> sha256_hash, 32)))
>>> +{
>>> +msg(M_WARN, "WARNING: failed to personalise random,
>> could not update CTR_DRBG");
>>> +}
>>>  memcpy(old_sha256_hash, sha256_hash,
>> sizeof(old_sha256_hash));
>>>  }
>>>  }
>>>
>>
>> This change will break compilation with anything that is < 2.16.0.
> 
> This function is deprecated in 2.16. I don't mind keeping this change to
> OpenVPN-NL for now, but for future reference, what's the best solution
> when a new version of mbedtls removes the function?

I'd say add a compat-wrapper, like we have many for openssl. Possibly in
compat-mbedtls.h (mimicing the openssl code) or just in crypto_mbedtls.h
if we don't have many. Something like (untested/"pseudo"code):

#if MBEDTLS_VERSION < 2.16
static inline int mbedtls_ctr_drbg_update_ret(ctx, h, len)
{
mbedtls_ctr_drbg_update(ctx, h, len);
return 0;
}
#endif

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Remove --no-replay

[Steffan Karger]

Hi,

On 07-04-2021 17:50, Antonio Quartulli wrote:
> On 26/07/2020 15:31, Arne Schwabe wrote:
>> Am 26.07.20 um 02:01 schrieb Arne Schwabe:
>>> Am 17.07.20 um 19:10 schrieb David Sommerseth:
 The --no-replay feature is considered to be a security weakness, which
 was also highlighed during the OpenVPN 2.4 security audit [0].  This
 option was added to the DeprecatedOptions[1] list and has been reported
 as deprecated since OpenVPN 2.4.
>>>
>>> As a side note, removing this feature weakens the ability to use OpenVPN
>>> is a pure tunnel without crypto (--auth none, --cipher none and
>>> no-replay) since this removes the ability to disable replay proctection
>>> when no authentication is enabled. (replay protection without auth is
>>> silly as a attacker can just fake the replay id too.)
>>>
>>> Acked-By: Arne Schwabe
>>
>> I given that a bit of a thought. But we need to decide if we to support
>> unencrypted transport only session or not in future. If we do not want
>> to support them, then applying this patch is fine, otherwise we should
>> restrict disabling no-replay to --auth none and also --auth none to
>> --cipher none basically:
>>
>> --cipher != none => auth none and no-replay forbidden
>>
>> --cipher == none => allows auth none and also no-replay
>>
>> --cipher none and auth none, warn if no-replay is used that it does not
>> prevent replay attacks. But do not fail since we would break a lot of
>> setups.
> 
> I work for the ministry of oversimplification and I think that removing
> user knobs is simply a good thing.
> 
> Following the logic provided by Arne, how about removing the --no-reply
> knob and making this mechanism automatic?
> 
> * if cipher != none -> replay prevention is always enabled;
> * if cipher == none && auth == none -> replay prevention is disabled.
> 
> 
> [allowing or disabling auth=none should be tackled saparately imho]

Before getting into solutions, let me state a few facts:

1. Replay protection only really works when authentication is enabled.

2. Our AEAD modes all require replay protection.

3. Automatically disabling replay protection will cause a config
backward compatibility break.


Given 1, if we were to couple allowing --no-replay to some crypto
settings, I would say it should be coupled to --auth none.

Given 2, how clear is our timeline on sunsetting non-AEAD ciphers? That
would automatically sunset --no-replay. (I've lost track a bit...)

Point 3 should not really be a problem, because --no-replay has been
deprecated since 2.4 (2017), and is an edge use-case anyway. But it
should be a conscious decision.


So, unless we're about to sunset non-AEAD ciphers soon (which would
automatically solve the issue), I would suggest a small variation to
Antonio's approach:

Remove the option, and:
 * if auth != none -> replay prevention is always enabled;
 * if auth == none -> replay prevention is disabled.

(Of course, considering that auth != none for AEAD cipher modes, even
when --auth none is set.)

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH applied] Re: reliable: retransmit if 3 follow-up ACKs are received

[Steffan Karger]

Hi,

On 02-04-2021 20:16, Gert Doering wrote:
> Your patch has been applied to the master branch.
> 
> I have never looked into this reliable stuff before, and do not have
> a test environment with a) significant amounts of control plane traffic,
> and b) "just the right amount" of packet loss.  So I've just stared at
> the code a bit (seems reasonable) and tested client side on Linux
> (works).

Thanks!

> I do wonder a bit under which condition this could fire - with the
> larger control channel packets we introduced a few years ago, I do
> not see many scenarios where "more than 3 packets" could be in-flight
> at the same time...  inital TLS handshake with very large DH groups?

This was written in the context of our post-quantum crypto experiments
with OpenVPN. Post-quantum (pub)keys are typically larger than
traditional keys. So yes, large keys / paramters is one example.

Another one would be someone pushing large amounts of routes. I recall
ValikSS had such a use case. I've also seen companies push a lot of
routers to have high-volume traffic (e.g. video conferencing, cloud
storage) bypass the VPN.

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] make --persist-key always-on and remove "off" code path

[Steffan Karger]

Hi,

On 10-04-2021 01:42, Arne Schwabe wrote:
> 
> Am 09.04.2021 um 18:28 schrieb Gert Doering:
>> Hi,
>>
>> there was a big discussion on the IRC channel today about interactions
>> between "--chroot" and "--persist-key" and how and when stuff is reloaded
>> or not.
>>
>> Now, we all seem to agree that OpenVPN has way too many obscure options,
>> so I propose to get rid of another one, namely --persist-key - and I
>> suggest to make it permanently-active ("load the keys at startup, and
>> then do not touch these files again").
>>
>> Unless someone explains to me in simple words what the benefit is of
>> reloading the keys on every new outbound connection...  yes, you *could*
>> put in a new key/cert/CA set while OpenVPN is active, and then trigger
>> a SIGUSR1 restart, having it "seamlessly" move to new credentials...
>>
>> But...
>>
>> How many of you do that?  Instead of just calling "service openvpn
>> restart"?
>>
>> I do not use --persist-key, but I still restart my services after
>> fiddling
>> with configs...
> 
> I am also for removing persist-key option (and ignore it if still
> present) and just always have the same behaviour. I can also not come up
> with a valid scenario where setting/not setting this option is making a
> real desirable difference.

For what it's still worth: I too agree that persist-key should be
always-on and removed as on option.

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel