From mboxrd@z Thu Jan 1 00:00:00 1970 From: ummeegge To: development@lists.ipfire.org Subject: Re: OpenVPN-2.5.0 update procedure and idea collector Date: Tue, 24 Nov 2020 16:27:45 +0100 Message-ID: <9d9bcb7f4172d000041a465f4f7ceac6e11ca28e.camel@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8150848847649327837==" List-Id: --===============8150848847649327837== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi all, Am Montag, den 23.11.2020, 23:29 +0100 schrieb Adolf Belka: > Hi Michael, >=20 >=20 > On 23/11/2020 19:00, Michael Tremer wrote: > > Hi, > >=20 > > > 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 these challenging times of many changes. > > >=20 > > > 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. > > >=20 > > > =C2=A0From the advanced encryption settings page I see that you have > > > removed the old insecure options, which is good. > >=20 > > 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. >=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 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=C2=B4t we probably mark CBC in general also as 'insecure' ? >=20 > 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 :-) . >=20 > >=20 > > > 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. > > >=20 > > > 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. > > >=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/=C2=A0. 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: > > > > =20 > > > > https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_ad= vanced_encryption_button.png > > > > And the page itself: > > > > =20 > > > > https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_ad= vanced_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 --> > > > > =20 > > > > https://community.ipfire.org/t/openvpn-2-5-development-version/2173 > > > > =C2=A0. > > > > 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 > >=20 --===============8150848847649327837==--