From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: OpenVPN patchset from Erik's input Date: Wed, 22 Feb 2023 16:20:12 +0000 Message-ID: <2E0DC5BA-D756-42A6-9FF7-D95ACB12A699@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0406915310036019273==" List-Id: --===============0406915310036019273== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 22 Feb 2023, at 13:15, Adolf Belka wrote: >=20 > Hi All, >=20 > Followup re the Blake2 question. >=20 > On 22/02/2023 13:54, Adolf Belka wrote: >> Hi Michael, >>=20 >> On 22/02/2023 12:21, Michael Tremer wrote: >>> Hello Adolf, >>>=20 >>>> On 17 Feb 2023, at 11:46, Adolf Belka wrote: >>>>=20 >>>> Hi All, >>>>=20 >>>>=20 >>>> I got Erik's OpenVPN patchset from some time ago and have created an upd= ated 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 = conflicts. >> I had to end up applying all the patches manually. There were enough chang= es 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. >>=20 >> So manual application just seemed the most secure if a bit long winded app= roach. 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. >>>=20 >>>> I applied those changes to ovpnmain.cgi and en.pl and installed them int= o a vm clone on my testbed. >>>>=20 >>>> Here are some images of the changes. Basically the ciphers are moved fro= m the main page to an additional ciphers page. >>>=20 >>> 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 wi= ll be on the same settings. >>>=20 >>> However, I do not understand why there are different options for the cont= rol and data channel. I do not see any reason why I would want different sett= ings because I either support a certain cipher or I don=E2=80=99t. If I consi= der my data channel =E2=80=9Cless important=E2=80=9D or need more throughput = and use AES-128 instead of AES-256, then what is the benefit of keeping the c= ontrol channel on AES-256? >>>=20 >>> Then there is labelling which isn=E2=80=99t clear to me. I suppose it wor= ks as follows: >>>=20 >>> Data Channel is the new setting. It should in theory be possible to selec= t multiple options. >>>=20 >>> Data Channel fallback seems to be what used to be on the front page befor= e and it should only allow to pick one option. If that is the case, then I be= lieve that the UI suggests otherwise. This setting will then also go away wit= h 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. >>>=20 >>> 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. >>>=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 mig= ht be no easy way around it. TLSv1.2 is on its way out, so we won=E2=80=99t n= eed to support this for forever hopefully. >>>=20 >>> Authentication: If there is only one option, the