Re: OpenVPN-2.5.0 update procedure and idea collector

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

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

Hi,

> On 23 Nov 2020, at 23:29, Adolf Belka <ahb.ipfire(a)gmail.com> wrote:
> 
> Hi Michael,
> 
> 
> On 23/11/2020 19:00, Michael Tremer wrote:
>> Hi,
>>> On 23 Nov 2020, at 11:41, Adolf Belka <ahb.ipfire(a)gmail.com> wrote:
>>> 
>>> Hi Erik,
>>> 
>>> Thanks for all your work on OpenVPN. Much appreciated, especially in these challenging times of many changes.
>>> 
>>> Am I correct in my presumption that in the advanced encryption settings GUI we will be able to select multiple entries, which will then be made into a list in order that the entries are in the tables.
>>> 
>>> From the advanced encryption settings page I see that you have removed the old insecure options, which is good.
>> It is good to encourage people to use modern cryptography, but I would like to raise the point that if we want to support older clients, we will have to support the old crypto, too. Otherwise it is not worth to add the extra work if it is virtually unusable.
> 
> I understand the need/desire to support older clients but I just wonder how old we should be supporting. Erik's previous page picture showed the older crypto (BF-CBC, CAST etc) which were marked Data-Channel fallback (insecure). If those are going to be left in then I think they should be labelled Data-Channel fallback (insecure/deprecated) so people know they are not secure and/or likely to disappear before too long.

Yes, I would favour a second control for the fallback option, too.

The reason why I think we need to include these awfully broken and old ciphers here is because there are users out there using them. We will have to break their setup at some point, BUT we need to give them some options so that they can migrate away from it first.

That is why we added the labels as a compromise to discourage people from using the old ciphers. I would say that we need cipher negotiation first and then the fallback option for a while. Then, we can remove the older ciphers from the fallback option - or even better - the entire fallback option.

That would be a gradual change and avoid any downtime for people with many clients.

> I also want to be sure that if these unsecure algorithms are listed and selected for fallback I want to be sure that there is no way for my system to fallback to using them by accident or whatever. That is why I would then like to have the ability to not have any fallback algorithm selected. The default can be to have one or more selected but I would like to be able to unselect all fallback algorithms if they are of this type of security.

The default configuration should not longer enable these things. Agreed.

> 
>>> For the Data-Channel fallback do you have to have a default or can you unselect everything. There could be people who only want to connect to systems that have the strongest ciphers and just refuse to connect with weaker ones.
>>> 
>>> For the Control-Channel sections I would suggest swapping the order of TLSv2 and TLSv3 on the screen. The Data-Channel goes from most secure to least secure from left to right. I think that the Control-Channel should do the same.
>>> 
>>> I don't have any comments about the defaults. They seem reasonable to me.
>>> 
>>> Excellent work, it's looking very nice.
>>> 
>>> Regards,
>>> Adolf.
>>> 
>>> 
>>> On 22/11/2020 17:30, ummeegge 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 -->
>>>> 1) DEPRECATED OPTION: ncp-disable. Disabling dynamic cipher negotiation
>>>> is a deprecated debug feature that will be removed in OpenVPN 2.6
>>>> 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.
>>>> 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
>>>> You can see also the default settings, were i need also your ideas and
>>>> comments for may better defaults.
>>>> 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.
>>>> Everything else would come detached from this.
>>>> Some feedback might be nice.
>>>> Best,
>>>> Erik