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 13:54:29 +0100 Message-ID: <3e45d933-4ae0-4d82-9154-6eadbe6c342b@ipfire.org> In-Reply-To: <32A1D261-0170-4991-9AA3-C8AB59027111@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2978880173482857878==" List-Id: --===============2978880173482857878== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, On 22/02/2023 12:21, Michael Tremer wrote: > Hello Adolf, >=20 >> 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 updat= ed patchset based on the current state of IPFire. >=20 > Okay. So I suppose it all applied well or you were able to fix any merge co= nflicts. I had to end up applying all the patches manually. There were enough=20 changes with the OTP stuff plus the change to the system commands that=20 many Hunks failed to apply plus I found one hunk that applied in the=20 wrong place. So manual application just seemed the most secure if a bit long winded=20 approach. That was why I created the new patch set because that is now=20 based on next so any changes can be done relative to that patch set. >=20 >> 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. >=20 > Yes, this is something the user ideally does not need to change. I would ac= tually not hesitate too much to just hardcode something as 99% of people will= be on the same settings. >=20 > However, I do not understand why there are different options for the contro= l and data channel. I do not see any reason why I would want different settin= gs because I either support a certain cipher or I don=E2=80=99t. If I conside= r my data channel =E2=80=9Cless important=E2=80=9D or need more throughput an= d use AES-128 instead of AES-256, then what is the benefit of keeping the con= trol channel on AES-256? >=20 > Then there is labelling which isn=E2=80=99t clear to me. I suppose it works= as follows: >=20 > Data Channel is the new setting. It should in theory be possible to select = multiple options. >=20 > 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 beli= eve 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=20 can be selected in the fallback set. >=20 > On the control channel the options are mislabeled. I suppose TLSv3 should b= e TLSv1.3 and TLSv2 should be TLSv1.2 and possible less?! That sounds like what is intended. >=20 > I don=E2=80=99t 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=E2=80=99t nee= d to support this for forever hopefully. >=20 > Authentication: If there is only one option, the