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 18:10:19 +0100 Message-ID: In-Reply-To: <618509F0-367D-419B-93FE-9750132F2C9B@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8222602966656783138==" List-Id: --===============8222602966656783138== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, On 22/02/2023 17:17, Michael Tremer wrote: > Hello Adolf, >=20 >> On 22 Feb 2023, at 12: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 upd= ated 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 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. >> >> 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. >>>> I applied those changes to ovpnmain.cgi and en.pl and installed them int= o a vm clone on my testbed. >>>> >>>> Here are some images of the changes. Basically the ciphers are moved fro= m 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 wi= ll be on the same settings. >>> 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? >>> Then there is labelling which isn=E2=80=99t clear to me. I suppose it wor= ks as follows: >>> Data Channel is the new setting. It should in theory be possible to selec= t multiple options. >>> 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 > Okay. Thank you. In the Data-Channel multiple ciphers can be selected. In the Data-Channel fal= lback only a single one can be selected so the same as we currently have. In the TLSv1.3 and TLSv1.2 boxes multiple options can be selected in both but= interesting results found when I tested out various connections is that if t= he boxes are left unselected then my Android Client negotiated the TLSv1.3 25= 6 bit TLS-AES-GCM cipher. When I looked at the connection logs for the existi= ng OpenVPN server connecting to my Android Phone with its existing connection= profile it negotiated and connected with the same TLSv1.3 cipher on the Cont= rol Channel. So the Control Channel looks to be auto negotiated currently any= way. This makes me wonder if we really need these options provided. If the Control= Channel is auto negotiated to the best available option for both server and = client that seems fine to me. One thing I did find was that once an option in the Control Channel boxes had= been selected then you can not unselect it. That then means that auto negoti= ation no longer takes place but the option selected is chosen. If the TLSv1.3= options are unselected but one of the TLSv1.2 ones is selected then the clie= nt ignored the TLSv1.2 option and still auto negotiated the best cipher for t= he connection. So seems to me that we could remove the control channel cipher option for bot= h TLSv1.3 and 1.2 and leave it auto negotiate. >=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. >>> 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. >>> Authentication: If there is only one option, the