From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: OpenVPN-2.5.0 update procedure and idea collector
Date: Mon, 14 Dec 2020 15:05:55 +0100
Message-ID: <0D321F70-61E0-4FE7-902C-9C36C110E083@ipfire.org>
In-Reply-To: <bd6e4d4fa0c8f9db26d1fc81a108b0607c828f37.camel@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4552326897784189499=="
List-Id: <development.lists.ipfire.org>

--===============4552326897784189499==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi,

> On 23 Nov 2020, at 20:49, ummeegge <ummeegge(a)ipfire.org> wrote:
>=20
> Hi Michael,
>=20
> Am Montag, den 23.11.2020, 17:58 +0000 schrieb Michael Tremer:
>> Hello everyone,
>>=20
>> Good to see that we are moving forward on making OpenVPN on IPFire
>> better.
> Bigger hurdles at this time ;-).
>=20
>>=20
>> 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 wit=
h no backward-compatibility issues.

Let=E2=80=99s see the rest.

>>=20
>>> On 22 Nov 2020, at 16:30, ummeegge <ummeegge(a)ipfire.org> wrote:
>>>=20
>>> 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
>>> -->
>>=20
>> Which clients to we want to support?
>>=20
>> Is it possible and do we want to support OpenVPN 2.3, too?
> Yes it is posible to support <=3D 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=E2=80=A6

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

>>=20
>> Depending on when the last release has been, it might not be worth
>> it.
> It=C2=B4s 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.

>>=20
>>> 1) DEPRECATED OPTION: ncp-disable. Disabling dynamic cipher
>>> negotiation
>>> is a deprecated debug feature that will be removed in OpenVPN 2.6
>>=20
>> 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.

>>=20
>>> 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.
>>=20
>> This seems to be much trickier.
> Haven=C2=B4t 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 d=
o that.

>=20
>>=20
>>> in the server log but it nevertheless works flawlessly.
>>>=20
>>> 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 <=3D OpenVPN-2.3.9), --tls-ciphers (control channel TLSv2
>>> only)
>>> and --tls-ciphersuites (control channel >=3D TLSv3) all options are
>>> explained in here -->=20
>>> https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html
>>> , which works here currently and looks like this:
>>>=20
>>> Button to belong to this page:
>>>=20
> https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced=
_encryption_button.png
>>>=20
>>> And the page itself:
>>>=20
> https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced=
_encryption.png
>>=20
>> 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=C2=B4t 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 ne=
ed to program some proof-of-concepts, but that is different to me.

>>=20
>> Then I have some questions:
>>=20
>> 1) Does this need to be an extra page? Why didn=E2=80=99t 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 page=
s 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 s=
uck and that are sometimes very slow. So it makes sense to use a stronger cip=
her 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 n=
ot.

I do not see the use-case why someone should choose a different one. Just bec=
ause it is possible isn=E2=80=99t 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 <=3DTLSv1.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 co=
ncern the user.

There should be one selection for all flavours of TLS. IPsec has some functio=
ns that compose the cipher suite out of what the user has selected so that st=
rongSwan can understand it.

>>=20
>> I assume that clients <=3D version 2.3 cannot use cipher negotiation?
>> How is it possible to select multiple options here and this still
>> works?
> That=C2=B4s 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 t=
o not select anything. That way the user can use this, or not.

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

Lets do it now then...

>>=20
>> It must be here on the list somewhere...
> 1000% :-) .
>=20
>>=20
>>> 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.
>>>=20
>>> 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.
>>=20
>> I do not understand how we can split this into two steps because I
>> thought OpenVPN 2.5 won=E2=80=99t 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 ?!=20
> Ater that let=C2=B4s check the warnings, one is here already more or less
> for me comfortably solved :D .

?

>=20
>>=20
>> -Michael
>=20
> Great feedback thanks Michael...

-Michael

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


--===============4552326897784189499==--