Re: OpenVPN patchset from Erik's input

[Adolf Belka <adolf.belka@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 6006 bytes --]

Hi All,

Followup re the Blake2 question.

On 22/02/2023 13: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 <adolf.belka(a)ipfire.org> 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.
>>
>> 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 <select> tag should 
>> not look like it does currently where it suggests that multiple 
>> options can be selected at the same time.
> I am also not sure if all are needed. I will need to check if TLS-Auth 
> no longer works with the TLSv1.3. TLS-Auth is what is currently 
> working and I haven't seen anything suggesting it is deprecated. SHA2 
> 512 bit seems strong enough for the moment and is not at risk from 
> being broken as far as I am aware. I would just remove the SHA1 has as 
> that is definitely not recommended any more.
> It would be simpler and easier if that stayed just with TLS-Auth if 
> that works with TLSv1.3. I will check into that.
>>
>> What does 64-bit/8-32bit optimised mean for Blake2?
> I have no idea.
>>
Blake2 comes in two formats.

Blake2b which is typically just referred to as Blake2 which has been 
optimised for 64 bit platforms and produces digests of any size between 
1 and 64 bytes.

Blake2s is optimised for 8 to 32 bit platforms and produces digests of 
any size between 1 and 32 bytes.

The above found on the blake2.net website

As far as I understand the fact that Blake2 is optimised for 64 bit 
systems means that it has a 512 bit capability and for Blake2s the 32 
bit max means that it has a 256 bit capability. Therefore it would seem 
we only need Blake2 256bit or Blake2 512 bit and not the remaining words.
>> Why is there an extra button for the encryption settings? Why is this 
>> not part of the advanced options?
> I don't know but putting it all on the advanced options page wouldn't 
> be too difficult ( says he keeping he fingers well crossed).
>>
>>> 1st image is current status of the main page, 2nd image is the 
>>> modified main page and the 3rd is the Advanced Encryption settings 
>>> page.
>>>
>>> I will also upload the updated patches to my ipfire git repo
>>>
>>> https://git.ipfire.org/?p=people/bonnietwin/ipfire-2.x.git;a=summary
>>
>> So this is a good start, but the UI is not making this process easy.
>>
>> I had a brief look at the code and it looks okay. Our CGIs are quite 
>> messy anyways, so I do not think it is worth adding the most polished 
>> code here :) This should not mean that we can just do whatever 
>> because we are just making future changes even more difficult for 
>> ourselves.
>>
>> I didn’t apply this to my system and test. Did you do this? Does it 
>> work with various client version of OpenVPN?
> I put it onto a vm clone on my system to get the screenshots. I 
> haven't tested various options yet as I have been a bit busy with 
> clearing out some bugs but I will do that and report back on it.
> My only problem with that is that all my clients are up to date so I 
> don't have any that would only work with older ciphers but at least I 
> can check that everything works with my Android phone and my Linux 
> laptop with various ciphers etc selected.
>
> Regards,
> Adolf
>>
>> -Michael
>>
>>>
>>>
>>> Regards,
>>>
>>> Adolf.
>>>
>>> <Screenshot - main page.png><Screenshot - modified main 
>>> page.png><Screenshot - advanced encryptions settings page.png>
>>
>

-- 
Sent from my laptop