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: Thu, 23 Feb 2023 16:16:02 +0000 Message-ID: <5FE78B6B-522C-4358-BE7F-31758B888F05@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8287156918442705990==" List-Id: --===============8287156918442705990== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Adolf, > On 22 Feb 2023, at 17:10, Adolf Belka wrote: >=20 > Hi Michael, >=20 > On 22/02/2023 17:17, Michael Tremer wrote: >> Hello Adolf, >>> On 22 Feb 2023, at 12:54, Adolf Belka wrote: >>>=20 >>> Hi Michael, >>>=20 >>> On 22/02/2023 12:21, Michael Tremer wrote: >>>> Hello Adolf, >>>>> 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 up= dated 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 chan= ges 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 ap= proach. 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 in= to a vm clone on my testbed. >>>>>=20 >>>>> Here are some images of the changes. Basically the ciphers are moved fr= om 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 w= ill be on the same settings. >>>> However, I do not understand why there are different options for the con= trol and data channel. I do not see any reason why I would want different set= tings because I either support a certain cipher or I don=E2=80=99t. If I cons= ider 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 = control channel on AES-256? >>>> Then there is labelling which isn=E2=80=99t clear to me. I suppose it wo= rks as follows: >>>> Data Channel is the new setting. It should in theory be possible to sele= ct multiple options. >>>> Data Channel fallback seems to be what used to be on the front page befo= re and it should only allow to pick one option. If that is the case, then I b= elieve that the UI suggests otherwise. This setting will then also go away wi= th 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. >> Okay. Thank you. > In the Data-Channel multiple ciphers can be selected. In the Data-Channel f= allback only a single one can be selected so the same as we currently have. That confirms my assumption. > In the TLSv1.3 and TLSv1.2 boxes multiple options can be selected in both b= ut interesting results found when I tested out various connections is that if= 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 exis= ting OpenVPN server connecting to my Android Phone with its existing connecti= on profile it negotiated and connected with the same TLSv1.3 cipher on the Co= ntrol Channel. So the Control Channel looks to be auto negotiated currently a= nyway. > This makes me wonder if we really need these options provided. If the Contr= ol Channel is auto negotiated to the best available option for both server an= d client that seems fine to me. Yes, I believe this assumption is also true. You could in theory limit what ciphers can be used, and there might be people= who don=E2=80=99t want to use anything with a key length of less than 128 bi= ts or so. > One thing I did find was that once an option in the Control Channel boxes h= ad been selected then you can not unselect it. As in the browser doesn=E2=80=99t allow you, or you get an error when you hit= the save button? On Mac OS, you can hold the Command button if you want to deselect the last e= ntry. If it is the first case, maybe Shift or Ctrl will do the same for you? > 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 TLSv= 1.2 ones is selected then the client ignored the TLSv1.2 option and still aut= o negotiated the best cipher for the connection. >=20 > So seems to me that we could remove the control channel cipher option for b= oth TLSv1.3 and 1.2 and leave it auto negotiate. Hmm, I believe it probably really doesn=E2=80=99t matter what people select h= ere. But since we know that some people might want to choose something other = than the default, we might want to keep it - and it is already built already. >>>> On the control channel the options are mislabeled. I suppose TLSv3 shoul= d 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 mi= ght 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