Hello Adolf, > 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 updated 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 changes 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 approach. 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 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. >>>> 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 will be on the same settings. >>>> However, I do not understand why there are different options for the control and data channel. I do not see any reason why I would want different settings because I either support a certain cipher or I don’t. If I consider my data channel “less important” 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’t clear to me. I suppose it works as follows: >>>> Data Channel is the new setting. It should in theory be possible to select multiple options. >>>> 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 believe 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 can 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. That confirms my assumption. > 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 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 existing OpenVPN server connecting to my Android Phone with its existing connection profile it negotiated and connected with the same TLSv1.3 cipher on the Control 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 Control Channel is auto negotiated to the best available option for both server and 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’t want to use anything with a key length of less than 128 bits or so. > One thing I did find was that once an option in the Control Channel boxes had been selected then you can not unselect it. As in the browser doesn’t 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 entry. 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 TLSv1.2 ones is selected then the client ignored the TLSv1.2 option and still auto 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. Hmm, I believe it probably really doesn’t matter what people select here. 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 should be TLSv1.3 and TLSv2 should be TLSv1.2 and possible less?! >>> That sounds like what is intended. >>>> I don’t 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’t need to support this for forever hopefully. >>>> Authentication: If there is only one option, the