Re: OpenVPN-2.5.0 update procedure and idea collector

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

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

Hi,

> On 24 Nov 2020, at 16:27, ummeegge <ummeegge(a)ipfire.org> wrote:
> 
> Hi all,
> 
> Am Montag, den 23.11.2020, 23:29 +0100 schrieb Adolf Belka:
>> 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.
> Did that now in the menu 'insecure/broken' for DES, BF and Cast.
> Shouldn´t we probably mark CBC in general also as 'insecure' ?

At least “not recommended”.

It would be bad to introduce more labels, but it is technically not broken.

>> 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.
> Have tested this with a client (2.4.9) which have had AES-256-CBC as --
> cipher configured. The server provided --data-ciphers ChaCha20-
> Poly1305:AES-256-GCM but also --data-ciphers-fallback AES-256-CBC and
> the connection initiated the data channel with AES-256-GCM which i
> think is even better than the existing client configuration provides
> it. May there are also good news :-) .
> 
>> 
>>> 
>>>> 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