Re: OpenVPN-2.5.0 update procedure and idea collector

[Michael Tremer <michael.tremer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 9386 bytes --]

Hi,

> On 23 Nov 2020, at 20:49, ummeegge <ummeegge(a)ipfire.org> wrote:
> 
> Hi Michael,
> 
> Am Montag, den 23.11.2020, 17:58 +0000 schrieb Michael Tremer:
>> Hello everyone,
>> 
>> Good to see that we are moving forward on making OpenVPN on IPFire
>> better.
> Bigger hurdles at this time ;-).
> 
>> 
>> To avoid that the conversation is getting stuck again, can we split
>> the problems into many smaller ones instead of having one massive
>> thread again? I think I suggested that some time before and it would
>> really help us to stay on track with things and ideally merge
>> everything that is done already so that we do not end up with one
>> massive patchset that is getting really difficult to work with later
>> on.
> Might it be an idea to go for the initial post, with the update to
> 2.5.0 new crypto for N2N, nothing changed for RW. In the same or may
> the next core update a "Advanced Cyrpto Section" delivers data-cipher,
> data-cipher-fallback, can but must not be tls-cipher, tls-ciphersuite -
> -> both are new ?

Okay, the update for 2.5.0 has been merged. That should be rolled out now with no backward-compatibility issues.

Let’s see the rest.

>> 
>>> On 22 Nov 2020, at 16:30, ummeegge <ummeegge(a)ipfire.org> wrote:
>>> 
>>> Hi all,
>>> i am currently in the update process of the already realeased
>>> OpenVPN-
>>> 2.5.0 --> https://openvpn.net/community-downloads-2/ . The update
>>> has
>>> been tested and worked so far also with the old default client
>>> configuration (tested with 2.4.9 client). There are two warnings
>>> -->
>> 
>> Which clients to we want to support?
>> 
>> Is it possible and do we want to support OpenVPN 2.3, too?
> Yes it is posible to support <= 2.3.x . Every client needs to be aware
> of the Galois-Counte-Mode otherwise we would need --> '--data-ciper-
> fallback' which is equal to the current --cipher directive in 2.5.0 ...
> Try to sort it in that way…

Adolf had some thoughts about it, and I will reply to his email.

>> 
>> Depending on when the last release has been, it might not be worth
>> it.
> It´s possible but also practical to deliver the chance to migrate via -
> -data-cipher-fallback (only one cipher, taken the already existing
> 'DCIPHER' in that case).

Yes, we should set that directive, if it is that simply for us.

>> 
>>> 1) DEPRECATED OPTION: ncp-disable. Disabling dynamic cipher
>>> negotiation
>>> is a deprecated debug feature that will be removed in OpenVPN 2.6
>> 
>> I think we have a good way to migrate cryptography.
> Me too, question is how.

I thought you were outlining this all along and that this is the path that we are following. We have the wiki page on the OpenVPN wiki which allows us to make some well-informed decisions.

>> 
>>> 2) WARNING: --topology net30 support for server configs with IPv4
>>> pools
>>> will be removed in a future release. Please migrate to --topology
>>> subnet as soon as possible.
>> 
>> This seems to be much trickier.
> Haven´t been there more than one hour ;-) but there seems to be more
> time with that (no 2.6 hint to change it)...

Okay, so lets ignore this entirely then for this time and we come back to it later.

I would assume that this is breaking existing setups, and we do not want to do that.

> 
>> 
>>> in the server log but it nevertheless works flawlessly.
>>> 
>>> Am working currently on an "Advanced Encryption Settings" page
>>> which
>>> includes currently four new directives --data-ciphers (data channel
>>> encryption), --data-ciphers-fallback (data-channel encryption for
>>> clients <= OpenVPN-2.3.9), --tls-ciphers (control channel TLSv2
>>> only)
>>> and --tls-ciphersuites (control channel >= TLSv3) all options are
>>> explained in here --> 
>>> https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html
>>> , which works here currently and looks like this:
>>> 
>>> Button to belong to this page:
>>> 
> https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_encryption_button.png
>>> 
>>> And the page itself:
>>> 
> https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_encryption.png
>> 
>> In order to keep things like this archived for later, you can simply
>> attach them to the email that you send to the list :)
> Ohh didn´t see that :D hope i do not forget it until the next time...
> Best is i deliver the code and more people can go for a checkout ?

As always, I recommend planning first, and then coding. Obviously we might need to program some proof-of-concepts, but that is different to me.

>> 
>> Then I have some questions:
>> 
>> 1) Does this need to be an extra page? Why didn’t you put this on the
>> advanced server options page?
> Simply too much, i thought the IPSec workflow is the best one i could
> choose.

Too much what?

I absolutely disagree, because we are scattering the settings across two pages already which is entirely unnecessary. We never know where to put a setting, how can we expect our users to find them?

>> 2) What is the use-case for choosing different things for the
>> data/control channel?
> More possibilites equal to IPSec but also more flexibility to the
> existing infrastructure/features. Nevertheless a default can be
> existant like it is in IPsec advanced crypto page. Should we
> enable/disable/delete the control channel crypto section ?

There is a difference between IPsec and OpenVPN here though:

IPsec implementations are ancient and maximum compatibility is very difficult to achieve. There are also many in-hardware implementations out there that suck and that are sometimes very slow. So it makes sense to use a stronger cipher for IKE and probably even no encryption for ESP.

OpenVPN is different. We are dealing with software implementations only and I am not even aware of any other popular implementations than the one that we all use. So either you have a version that supports GCM or not, or TLSv3 or not.

I do not see the use-case why someone should choose a different one. Just because it is possible isn’t enough of a reason for me.

Do you have a use-case?

>> I am asking this because I find this really confusing. Why does
>> OpenVPN need different things selected for TLSv1.3 and <=TLSv1.2?
>> Should we not hide this from the user, because otherwise editing the
>> configuration file is easier?
> Yeah this is confusing. TLSv3 for the control channel is another
> dierctive (--tls-ciphersuites), the channel control with TLSv2 uses the
> --tls-cipher directive. May also not that bad, fututre sound of music,
> TLSv2 will sooner or later go and there is than --tls-ciphersuites ?!

Yes, in the backend it is a different directive, but that does not have to concern the user.

There should be one selection for all flavours of TLS. IPsec has some functions that compose the cipher suite out of what the user has selected so that strongSwan can understand it.

>> 
>> I assume that clients <= version 2.3 cannot use cipher negotiation?
>> How is it possible to select multiple options here and this still
>> works?
> That´s true. 2.3 have no plan how to use the NegotiationCipherProtocol
> . In that case the new directive '--data-ciphers-fallback algo' which
> is simply '--cipher alg' , as we know it, handles this.

I could see this as a simple dropdown as it is now and it would be possible to not select anything. That way the user can use this, or not.

>> 
>>> You can see also the default settings, were i need also your ideas
>>> and
>>> comments for may better defaults.
>> 
>> I am sure we have talked about this somewhere and we even came up
>> with a decision…
> Yes i know it too but we didn´t go into depth in there ;-) .

Lets do it now then...

>> 
>> It must be here on the list somewhere...
> 1000% :-) .
> 
>> 
>>> On the page itself is also more planned but to not overload this
>>> here
>>> now, i wanted to go now a two step procedure with this update.
>>> 
>>> 1) Push OpenVPN-2.5.0 update with the new ciphers and HMACs for
>>> regukar
>>> global settings for RW and N2N. A overview of the new crypto can be
>>> found in here -->
>>> https://community.ipfire.org/t/openvpn-2-5-development-version/2173
> .
>>> 2) I would push the "Advanced Encryption settings" development as
>>> seen
>>> above then as one patch <-- this would also eliminate the first
>>> warning
>>> causing --ncp-disable since we can delete this option then.
>> 
>> I do not understand how we can split this into two steps because I
>> thought OpenVPN 2.5 won’t work with the current settings?!
> For RW are only two warnings (NCP, topology) but it works here, which
> is for N2N not that hard since N2N do not understands
> 'push|SENT_CONTROL' and it works also not with --topology net30. I
> would give N2N all that new stuff for ciphers and HMACs but the RW runs
> for the first without modifications. This could be the second patch ?! 
> Ater that let´s check the warnings, one is here already more or less
> for me comfortably solved :D .

?

> 
>> 
>> -Michael
> 
> Great feedback thanks Michael...

-Michael

> 
>> 
>>> Everything else would come detached from this.
>>> 
>>> Some feedback might be nice.
>>> 
>>> Best,
>>> 
>>> Erik