Hi Michael,
On 23/02/2023 17:16, Michael Tremer wrote:
Hello Adolf,
On 22 Feb 2023, at 17:10, Adolf Belka adolf.belka@ipfire.org wrote:
Hi Michael,
On 22/02/2023 17:17, Michael Tremer wrote:
Hello Adolf,
On 22 Feb 2023, at 12:54, Adolf Belka adolf.belka@ipfire.org 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@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.
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?
Thanks for the suggestion. Control worked to clear the selection.
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.
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 client and server.
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.
If we currently only support TLS-Auth I would like to keep it that way until we have rolled out this stuff as it should have priority.
I tested out 5 different connection profiles with my Android phone. Everyone of them worked. That includes the existing profile which just worked as expected using 256 bit AES-GCM with TLS=Auth with SHA2 512 bit without needing to change anything in the Advanced Encryption Settings page.
I ran the following combinations:-
SHA2 512 bit with TLS-Auth (Existing Connection) SHA2 512 bit with TLS-Crypt SHA2 512 bit with TLS-Crypt-V2 Blake2 512 bit with TLS-Auth Blake2 512 bit with TLS-Crypt-V2 SHA3 512 bit with TLS-Auth
With TLS-Crypt-V2, which gives profile specific Control Channel encryption keys, It looks like the Hash Algorithm may be fixed. At least it was 256 bit (probably SHA3 256 bit) in both cases I tested, i.e. ignoring the hash algorithm selected in the box. Not sure if that is the code or what should happen with Crypt-V2.
So everything works, at least with my Android client, but starting with just TLS-Auth as we currently use seems to make sense and then we can later on add the TLS-Crypt option which encrypts the Control Channel before any communication starts at all.
Okay, this is really good to know.
But did you reload the configuration file from the web UI into your client each time, or are you able to change all these options on the server and the client will automatically negotiate only what you have configured?
I believe that TLS-Auth/-Crypt will require you to change the client configuration as it includes another key?
Yes, for each of the variations with a different TLS Authentication method I had to create a new connection file and upload it to the client. I was just wanting to see if all combinations of hash algorithm worked with all TLS Channel Protection methods. Basically all hash's work with either TLS-Auth or TLS-Crypt.
TLS-Crypt-V2 only had 256 bit hash irrespective of what was selected in the Hash Algorithm box.
I will test a few connection profiles also with my Linux laptop to confirm no differences in how things work.
Luckily, OpenVPN has the same bugs on all platforms as it is the same code base. IPsec has different implementations with different features and bugs.
So hopefully, if it works on one OS, it should be fine on the others. Especially since we are dealing with low-level things and nothing that requires some user interaction like OTP did recently.
Okay, that is good to know.
This is all tedious enough already, so let’s not make it more complicated, but rather roll out incremental changes that we can better build and test.
What does 64-bit/8-32bit optimised mean for Blake2?
I have no idea.
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).
I am sure it is less fun than creating a new clean page, but we cannot outsource all of our problems to the user. A few maybe, but not all :)
If my remaining tests with my laptop don't flag some unexpected issues then I will have a look at the code and the patches and look at moving the encryption options to the Advanced Options page. Also I will look at only having TLS-Auth and, unless I hear back to the contrary, removing the Control Channel cipher selection boxes completely.
That sounds good, but I would vote for keeping the cipher suites. Well, to be honest I don’t know. I don’t see how anyone wants anything else than AES-256-GCM/CBC.
But what is the reason for TLS-Auth going? I think I didn’t get this right.
You have misunderstood me. TLS-Auth would be the only one staying. I could keep TLS-Auth and TLS-Crypt but I think definitely TLS-Crypt-V2 makes sense to not include at this stage.
The key thing I found was that trying to connect to the updated OpenVPN cgi with my existing client connections just worked.
I will do it in stages and test out as I go along. Can't promise it will be very fast but if I hit any roadblocks I will report back for help.
Absolutely come back here for help. The CGI is very fragile and it won’t be a fun job anyways, so get all the help you need and let’s share the pain.
An additional thing I tried today was to create with my CU172 system a client connection profile with the server set to BF-CBC 128 bit. I did a version for my Android phone and one for my Linux Laptop. Basically my clients don't accept Blowfish so I can't test that people with old insecure ciphers will still have their connection made with the updated OpenVPN cgi.
Regards,
Adolf.
-Michael
Regards, Adolf
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.
Okay, I just wanted to get a feeling with where we are at with this all before we talk too much about the UI. -Michael
Regards, Adolf
-Michael
Regards,
Adolf.
<Screenshot - main page.png><Screenshot - modified main page.png><Screenshot - advanced encryptions settings page.png>
-- Sent from my laptop