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: Thu, 23 Feb 2023 18:29:09 +0100 Message-ID: In-Reply-To: <5FE78B6B-522C-4358-BE7F-31758B888F05@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6668116487709408072==" List-Id: --===============6668116487709408072== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, On 23/02/2023 17:16, Michael Tremer wrote: > Hello Adolf, >=20 >> On 22 Feb 2023, at 17:10, Adolf Belka wrote: >> >> Hi Michael, >> >> On 22/02/2023 17:17, Michael Tremer wrote: >>> Hello Adolf, >>>> 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 u= pdated patchset based on the current state of IPFire. >>>>> Okay. So I suppose it all applied well or you were able to fix any merg= e conflicts. >>>> I had to end up applying all the patches manually. There were enough cha= nges with the OTP stuff plus the change to the system commands that many Hunk= s 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 a= pproach. That was why I created the new patch set because that is now based o= n 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 i= nto a vm clone on my testbed. >>>>>> >>>>>> Here are some images of the changes. Basically the ciphers are moved f= rom the main page to an additional ciphers page. >>>>> Yes, this is something the user ideally does not need to change. I woul= d 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 co= ntrol and data channel. I do not see any reason why I would want different se= ttings because I either support a certain cipher or I don=E2=80=99t. If I con= sider my data channel =E2=80=9Cless important=E2=80=9D or need more throughpu= t 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=E2=80=99t clear to me. I suppose it w= orks as follows: >>>>> Data Channel is the new setting. It should in theory be possible to sel= ect multiple options. >>>>> Data Channel fallback seems to be what used to be on the front page bef= ore 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 w= ith OpenVPN 2.6.0. Is that correct? >>>> That is what I would read it as. I will check if more than one option ca= n be selected in the fallback set. >>> Okay. Thank you. >> In the Data-Channel multiple ciphers can be selected. In the Data-Channel = fallback only a single one can be selected so the same as we currently have. >=20 > That confirms my assumption. >=20 >> 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 i= f the boxes are left unselected then my Android Client negotiated the TLSv1.3= 256 bit TLS-AES-GCM cipher. When I looked at the connection logs for the exi= sting OpenVPN server connecting to my Android Phone with its existing connect= ion profile it negotiated and connected with the same TLSv1.3 cipher on the C= ontrol Channel. So the Control Channel looks to be auto negotiated currently = anyway. >> This makes me wonder if we really need these options provided. If the Cont= rol Channel is auto negotiated to the best available option for both server a= nd client that seems fine to me. >=20 > Yes, I believe this assumption is also true. >=20 > You could in theory limit what ciphers can be used, and there might be peop= le who don=E2=80=99t want to use anything with a key length of less than 128 = bits or so. >=20 >> One thing I did find was that once an option in the Control Channel boxes = had been selected then you can not unselect it. >=20 > As in the browser doesn=E2=80=99t allow you, or you get an error when you h= it the save button? >=20 > On Mac OS, you can hold the Command button if you want to deselect the last= entry. If it is the first case, maybe Shift or Ctrl will do the same for you? Thanks for the suggestion. Control worked to clear the selection. >=20 >> That then means that auto negotiation no longer takes place but the option= selected is chosen. If the TLSv1.3 options are unselected but one of the TLS= v1.2 ones is selected then the client ignored the TLSv1.2 option and still au= to negotiated the best cipher for the connection. >> >> So seems to me that we could remove the control channel cipher option for = both TLSv1.3 and 1.2 and leave it auto negotiate. >=20 > Hmm, I believe it probably really doesn=E2=80=99t matter what people select= here. But since we know that some people might want to choose something othe= r than the default, we might want to keep it - and it is already built alread= y. Okay, then I will keep the Control Channel boxes. The default when nothing is= selected is to negotiate the highest security version that is supported by c= lient and server. >=20 >>>>> On the control channel the options are mislabeled. I suppose TLSv3 shou= ld 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 TLSv= 1.3 does not support many of the cipher suites that TLSv1.2 supports, there m= ight be no easy way around it. TLSv1.2 is on its way out, so we won=E2=80=99t= need to support this for forever hopefully. >>>>> Authentication: If there is only one option, the