From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: OpenVPN patchset from Erik's input Date: Wed, 22 Feb 2023 14:15:06 +0100 Message-ID: In-Reply-To: <3e45d933-4ae0-4d82-9154-6eadbe6c342b@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0548935251373326830==" List-Id: --===============0548935251373326830== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hi All, Followup re the Blake2 question. On 22/02/2023 13:54, Adolf Belka wrote: > Hi Michael, > > On 22/02/2023 12:21, Michael Tremer wrote: >> Hello Adolf, >> >>> On 17 Feb 2023, at 11:46, Adolf Belka wrote: >>> >>> Hi All, >>> >>> >>> I got Erik's OpenVPN patchset from some time ago and have created an >>> updated patchset based on the current state of IPFire. >> >> Okay. So I suppose it all applied well or you were able to fix any >> merge conflicts. > I had to end up applying all the patches manually. There were enough > changes with the OTP stuff plus the change to the system commands that > many Hunks failed to apply plus I found one hunk that applied in the > wrong place. > > So manual application just seemed the most secure if a bit long winded > approach. That was why I created the new patch set because that is now > based on next so any changes can be done relative to that patch set. >> >>> I applied those changes to ovpnmain.cgi and en.pl and installed them >>> into a vm clone on my testbed. >>> >>> Here are some images of the changes. Basically the ciphers are moved >>> from the main page to an additional ciphers page. >> >> Yes, this is something the user ideally does not need to change. I >> would actually not hesitate too much to just hardcode something as >> 99% of people will be on the same settings. >> >> However, I do not understand why there are different options for the >> control and data channel. I do not see any reason why I would want >> different settings because I either support a certain cipher or I >> don’t. If I consider my data channel “less important” or need more >> throughput and use AES-128 instead of AES-256, then what is the >> benefit of keeping the control channel on AES-256? >> >> Then there is labelling which isn’t clear to me. I suppose it works >> as follows: >> >> Data Channel is the new setting. It should in theory be possible to >> select multiple options. >> >> Data Channel fallback seems to be what used to be on the front page >> before and it should only allow to pick one option. If that is the >> case, then I believe that the UI suggests otherwise. This setting >> will then also go away with OpenVPN 2.6.0. Is that correct? > That is what I would read it as. I will check if more than one option > can be selected in the fallback set. >> >> On the control channel the options are mislabeled. I suppose TLSv3 >> should be TLSv1.3 and TLSv2 should be TLSv1.2 and possible less?! > That sounds like what is intended. >> >> I don’t really like it that there are two boxes, but since TLSv1.3 >> does not support many of the cipher suites that TLSv1.2 supports, >> there might be no easy way around it. TLSv1.2 is on its way out, so >> we won’t need to support this for forever hopefully. >> >> Authentication: If there is only one option, the