From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: OpenVPN-2.5.0 update procedure and idea collector Date: Mon, 14 Dec 2020 15:09:11 +0100 Message-ID: <497C68CA-0B69-4E68-9415-2B3F5826C15F@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1562683763310436523==" List-Id: --===============1562683763310436523== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, > On 23 Nov 2020, at 23:29, Adolf Belka wrote: >=20 > Hi Michael, >=20 >=20 > On 23/11/2020 19:00, Michael Tremer wrote: >> Hi, >>> On 23 Nov 2020, at 11:41, Adolf Belka wrote: >>>=20 >>> Hi Erik, >>>=20 >>> Thanks for all your work on OpenVPN. Much appreciated, especially in thes= e challenging times of many changes. >>>=20 >>> Am I correct in my presumption that in the advanced encryption settings G= UI 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. >>>=20 >>> From the advanced encryption settings page I see that you have removed th= e old insecure options, which is good. >> It is good to encourage people to use modern cryptography, but I would lik= e to raise the point that if we want to support older clients, we will have t= o support the old crypto, too. Otherwise it is not worth to add the extra wor= k if it is virtually unusable. >=20 > 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 c= rypto (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-Ch= annel fallback (insecure/deprecated) so people know they are not secure and/o= r 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 cipher= s 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 the= y can migrate away from it first. That is why we added the labels as a compromise to discourage people from usi= ng the old ciphers. I would say that we need cipher negotiation first and the= n 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 cl= ients. > I also want to be sure that if these unsecure algorithms are listed and sel= ected for fallback I want to be sure that there is no way for my system to fa= llback to using them by accident or whatever. That is why I would then like t= o have the ability to not have any fallback algorithm selected. The default c= an be to have one or more selected but I would like to be able to unselect al= l fallback algorithms if they are of this type of security. The default configuration should not longer enable these things. Agreed. >=20 >>> For the Data-Channel fallback do you have to have a default or can you un= select 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. >>>=20 >>> For the Control-Channel sections I would suggest swapping the order of TL= Sv2 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 sam= e. >>>=20 >>> I don't have any comments about the defaults. They seem reasonable to me. >>>=20 >>> Excellent work, it's looking very nice. >>>=20 >>> Regards, >>> Adolf. >>>=20 >>>=20 >>> 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 <=3D OpenVPN-2.3.9), --tls-ciphers (control channel TLSv2 only) >>>> and --tls-ciphersuites (control channel >=3D 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_advan= ced_encryption_button.png >>>> And the page itself: >>>> https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advan= ced_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 --===============1562683763310436523==--