Hi Nick,
On 17/03/2024 18:31, Nick Howitt wrote:
On 17/03/2024 16:47, Adolf Belka wrote:
Hi Nick,
On 17/03/2024 16:47, Nick Howitt wrote:
What about the idea of using the dropdown to populate --data-ciphers-fallback instead of whatever it populates now. Then you can enable autonegotiation at the same time, if I've read the doc correctly.
From my understanding of data-ciphers-fallback, that is of use if you have a client that doesn't understand negotiation, ie 2.3.x or earlier. With 2.4.0 onwards, even if you have an old cipher specified in the client profile the negotiation will choose the strongest possible between that client and the IPFire server. So negotiation can be implemented and will work and will give the period where the users can change the client profile to remove the old cipher.
That is why I was suggesting it and you can use the current cipher field to populate the --data-ciphers-fallback. Then old and new clients work and the old cipher will work but can be removed when 2.7 comes out. All that is needed is a refresh of the server config.
The users still need to update their clients one at a time and that can be done with just the negotiation in place as long as users are using openvpn-2.4.0 or newer.
I tested that out by downgrading my laptop to 2.4.2 openvpn versions and testing a connection using a profile set up with blowfish cipher and with the changes in that git repo in place on my vm server. The openvpn connection was successfully made with negotiation and that connection used a much stronger cipher than the blowfish specified in the client profile. This showed that clients with older or newer ciphers specified in their profiles were able to connect with the same server setup. Therefore the clients can be updated on a client by client basis.
The addition of the --data-ciphers-fallback option would only add further complexity to the current system and would then need to be removed again in the future.
That has to be done because in 2.7.0 openvpn will no longer recognise any of the old ciphers at all so if they are in the client profile then the negotiation will fail because an unrecognised cipher will be found.
Therefore we go to using negotiation and can then move to openvpn-2.6.x and that time period can then be used by the users to update each client on a client by client basis. That can be a scheduling activity and may take a bit of time but can be completed.
Re compression, you can ignore the settings in the raodwarriors by setting:
compress stub-v2 push "compress stub-v2"in the server. I did that years ago for the ClearOS server. It effectively ignores what is set in the client unless the client uses the settings to disallow pushes but that would not be normal.
That just ignores the compression settings in the clients. It doesn't remove them.
I pushed that with 2.4. If compression settings from the client are ignored, that is fine. No need to remove them.
When the client version goes to the one that no longer recognises the compression options then they would need to be removed on the client, otherwise again all clients will stop working because they include a compression option that is no longer recognised.
Also I would expect the IPFire openvpn server will end up not recognising the compress stub-v2 once it gets to the version that no longer accepts any compress option, so the command will no longer be able to be sent, or maybe even work because of an unrecognised option.
As openvpn-2.5.0 onwards ignores the compression options if set then the push compress option doesn't buy anything additional. IPFire is running currently with 2.5.9 so it ignores the compress options, even if they have been selected.
I didn't know 2.5.9 ignored them totally. ClearOS7/Centos7/EL7 are stick with 2.4.x (currently 2.4.12). Then, again, with 2.5.x there is no need to update the client.
2.5.0 ignores the compress option but still adds the compress header if the compress setting is in place on the server. So it looks like compression is being done but it is only the header that is set. No actual compression is done on the data, which is where the security issue can occur.
With compress set on the server then all clients need to have compress in their profile. With compress turned of on the server then none of the client profiles must use the compress option.
If those compress options are specified do they work both with clients with compress specified and clients with no compress options specified.
In openvpn2.6.0 onwards there is an option that allows a migration path that users can remove the compress option client by client, if they have the compress option turned on on their server. I can't remember of the top of my head,what the command is now but I remember reviewing it 3 or 4 months ago. It will allow the server to work with clients that have the compress option specified as well as those that don't. So again can be dealt with on a client by client basis by the users.
There is a `--compress migrate` option in 2.6 (https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/) but all it does is disallows compression if it is not requested by the client and, if it is requested, it responds with an appropriate reply. I don't see that it actually updates the client's local config.
That was the option I remembered. It allows you to update clients one at a time as it disallows compression on the server if the client does not request it. The clients that still have the compress option will get the traffic with the compress header but no actual compression. None of the commands on the server actually change or update the client profile. That has to be done in all cases by the user, which is why you want to be able to update clients on a one by one basis so that not all roadwarriors stop working when you turn off compression on the server.
I would prefer to be able to move on to the 2.6.x series anyway to not end up falling too far behind.
Agreed.
The compress option needs to be removed from the client profile because openvpn have notified that in the future the compress options will be completely removed. At that time the compress option in the client would become an error due to it being an unrecognised option. That might occur during the 2.7.x series or later but it would be best to deal with the old ciphers and the compress option removal at the same time rather than asking users to modify their clients a second time.
But for the moment you can ask them to remove them but leave in parameters temporarily in the server that allows for them to still be in the client configs and then only remove them from the server when required.
That is what the plan is with the changes already proposed and with the compress migrate option that is still to be added into the changes.
Regards, Adolf.
Regards,
Adolf.
On 17/03/2024 15:25, Adolf Belka wrote:
Hi Nick,
On 17/03/2024 15:56, Nick Howitt wrote:
Crumbs. Still supporting 2.3? That should be a no-no. Anyone with an explicit cipher in their roadwarriors will have problems if they are old, whatever you do. The oldest version at openvpn.net is 2.4.6 dating back to 2018. Even then plenty of water has passed under the bridge e.g SWEET32 etc. Compression should have been disabled and stubbed a long time ago. The minute you allow cipher negotiation, you risk breakage if the client uses a cipher which is not currently supported. Are you going to allow the cipher to be unset (default) in the GUI?
No not now but when the ncp-disable was added 6 years ago when openvpn was at version 2.4.5 things were very different.
There isn't really an upgrade path if you have a number of clients using explicit ciphers, because the minute you upgrade the server, clients will break. If you update the client before the server, the client will break as well. I have not studied the effect of that document, but can you use the fallback cipher (--data-ciphers-fallback) as the parameter you change from the GUI? Then you will have auto negotiation enabled as well. Then you give the users a fixed timeline to update their clients software and/or configs after which you can remove it again. This may work.
There is a migration path now with the move to cipher negotiation on the basis that all clients are 2.4.x or newer, which should now be a reasonable assumption but would not have been 6 years ago. The question would also be is it our role to break users systems because we think they are using too old or too insecure ciphers. I would say that is not our role. So we need to find a path forward that allows users to make that upgrade on a client by client basis.
We also need to ensure that all changes are dealt with in one go and not ask users to update their clients for ciphers now and then later on for compressions settings etc.
The path forward I have looked at would also deal with the changes in compression settings. If people currently have compression set in their clients then compression is not used, just the headers are implemented but no compression. However in future openvpn updates if compression is specified the client will fail to operate because it will be considered an error. So again with the change from openvpn-2.5.x to 2.6.x there is a compression migration path and we need to combine both the compression and cipher migration paths so that users are asked to update their client settings on a client by client basis only once.
Regards,
Adolf.
On 17/03/2024 14:05, Adolf Belka wrote:
Hi Nick,
On 17/03/2024 13:34, Nick Howitt wrote: > Can I ask a question? Why are we playing around with Cipher > strings and hashes? The minute you do that you make things much > harder to get a good connection. The reason is because, if they > are not specified, OpenVPN chooses a good safe set that allows > multiple strong ciphers. This gives a high chance of the remote > end matching you with strong ciphers. If you specify a cipher, > then you restrict all connections to that single cipher as you > don't have any form of multi-select. Then, if you ever want to > change your choice, perhaps because what you have chosen is no > longer recommended, you have a nightmare on your hands because > you will have to update every remote client config where it has > also been specified. > When the cipher negotiation was introduced by OpenVPN it was not backwards compatible. If we had changed to cipher negotiation at that time then users with older clients would have just failed. This was not acceptable, especially as to update every client would have had to been updated at the same time, not acceptable for users with 200 or more clients running with their systems but maybe with older defined ciphers.
Therefore we had to move to a situation where we had the ncp-disable option, so preventing cipher negotiation.
> At a minimum, the dropdowns should have an option which says > "default" when nothing is put in the config, and this should be > the default option. Anyone who then wants to specify an option, > then can, but they are going down their own blind alley. If it > were me, I would not even give the user a choice. If I had to, I > would give them a choice to exclude ciphers, but not set them. > No we are looking at moving from the ncp-disable situation to one where cipher negotiation is enabled. The previous issue with older clients no longer holds as users would have to be still using clients at version 2.3 or older. Cipher negotiation came in with version 2.4
So any users still using version 2.3 will have to update but that should be a very small number now, especially as that older version only worked with openssl-1.0.1x. So anyone still using it must be minimal now and very insecure.
So now we can move to cipher negotiation but we still need to enable cipher selection for those users that have clients with older ciphers. These may be insecure but again we need to allow users to update their clients one at a time, not require them to update all clients at the same time.
Once we have cipher negotiation in place, the users will be able to have a mixed situation of some clients with newer ciphers specified and others still with the older ones so they can update on a client by client basis over time. Currently we are on OpenVPN-2.5.9. With cipher negotiation enabled we would be able to move to the openvpn-2.6.x series. We then would have to stay on OpenVPN-2.6.x for a specified period to allow users to update any clients that are using the much older ciphers.
Once the period is past we could then consider updating to openvpn-2.7 series which is likely to come somewhere during this year but that will actively prevent any older ciphers being used so all users must have updated all clients by that time.
> Also, by specifying the options you get a maintenance issue > where the dropdowns need to be maintained to stay in line with > every update to the underlying openvpn code. > > There is a possibly useful document at > https://community.openvpn.net/openvpn/wiki/CipherNegotiation. > Yes, I am aware of that document and that has been the basis of deciding how to move forward to allow the cipher negotiation to be enabled while making sure we impact existing users the least and move to a position where the users can update their clients one at a time, rather than a big bang update where all clients stop working and all have to be updated at the same time during which no users of the organisation are able to use their roadwarrior connections.
The next challenge is how to make all these changes in the ovpnmain.cgi code, in a way that does allow the existing systems to continue and to be able to test this out in some way, to be sure we are not creating a breaking IPFire for users when the update is released to Testing and then Full Release.
That is where I have been trying to work on, while at the same time trying to understand the code, as I am relatively new into what currently exists and I have found it a big challenge. I have made progress but not quick enough and have been diverted by other things.
Has the non-breaking, backwards compatible approach we have used historically been the best option. I don't know, but it is what has been used and so we now have to find a way to move forward from that current status to the next step, again without creating a breaking, backwards incompatible approach.
Always open to alternative approaches, if they are easier to implement and maintain the non-breaking, backwards compatible policy and give a migration path to move forward on a client by client update basis.
Regards,
Adolf.
> Regards, > > Nick > > On 17/03/2024 11:35, Adolf Belka wrote: >> >> Hi Michael, >> >> I am afraid I don't have a patch set. It is just a single diff >> change. >> >> I took Erik's original patch set and applied it to the latest >> ovpnmain.cgi version at that time and then removed some of the >> items that I decided could wait till later or were not needed. >> >> This created a single diff file, which I was able to apply and >> test out to confirm it did what I expected it to do, which it >> seemed to do. >> >> The next step I then had intended to do was to break that >> single diff into multiple patches but I found this very >> difficult to do as I could not easily figure out which bits >> needed to go together in different patches. Trying to >> understand all the changes and what each were related to I >> struggled to make sense of. >> >> My next step was therefore going to be to go back to an >> unmodified ovpnmain.cgi file and make the changes a step at a >> time, to match what I had previously done and therefore end up >> with a patch set of small self consistent changes. >> >> However to do this I had to go back to the start and figure out >> which of Erik's changes to apply and what parts of those >> changes and every time I did something else in IPFire for a >> week or so I was having to go back to square one in trying to >> remember what I had been going to do next. >> >> The diff patch file I created is at >> >> https://git.ipfire.org/?p=people/bonnietwin/ipfire-2.x.git;a=commit;h=4fbf17... >> >> >> Hopefully you can use this as a basis to extract just the bits >> needed for the cipher negotiation. >> >> I will also go back and start again to work on it but focus on >> it without diverting to anything else, after I have dealt with >> the wsdd patch modification. >> >> Regards, >> >> Adolf. >> >
-- Sent from my laptop
-- Sent from my laptop