Hi Erik,
On 23/11/2020 20:49, ummeegge 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 ?
All of my experience to date is with RW. If you will use N2N initially I will have to see if I am able to set an N2N system up in my Virtual test bed. I will only be able to test out any OpenVPN changes in N2N if I am successful in setting that up. I will give it a go.
On 22 Nov 2020, at 16:30, ummeegge ummeegge@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...
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).
- 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.
- 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)...
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_...
And the page itself:
https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_...
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 ?
Then I have some questions:
- 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.
- 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 ?
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 ?!
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.
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 ;-) .
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.
- 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
.
- 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...
Everything else would come detached from this.
Some feedback might be nice.
Best,
Erik