Re: OpenVPN cipher negotiation patch set

Re: OpenVPN cipher negotiation patch set

[Adolf Belka]

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

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=4fbf17f4a10fbf2a0ddeae1aa436cf26f6b3a035
>>
>> 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.
>>
>

Re: OpenVPN cipher negotiation patch set

[Michael Tremer]

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

Hello Nick,

You will have to know that a long long discussion has been preceding this. I appreciate your input, but you are not considering many problems that we sadly have to deal with. In a more perfect world, I am sure we would be able to make better decisions now. However, we have inherited a lot of debt with this feature. OpenVPN has been a huge pain point for many years and has only received patching, but never anything substantial.

> On 17 Mar 2024, at 12:34, Nick Howitt <nick(a)howitts.co.uk> 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.

Exactly. In the past OpenVPN could not negotiate anything. Everything had to be configured on the client and the server side. If anything didn’t match, you might have a connection that considers itself up, but not a single packet can be transferred.

The client configurations that are currently out there might not use cipher negotiation and so we can’t remove this functionality easily. We have people out there with hundreds of OpenVPN connections which would have to be changed on the same day. It’s not going to happen.

> 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.

Nice idea, but not an option in this case.

> 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.

I am very well aware of that.

> 
> 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=4fbf17f4a10fbf2a0ddeae1aa436cf26f6b3a035 
>> 
>> 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. 
>> 
> 

Re: OpenVPN cipher negotiation patch set

[ummeegge]

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

Hi all,
please see this -->
https://patchwork.ipfire.org/project/ipfire/list/?series=4230 as a
first suggestion. All files can be found in here -->
https://people.ipfire.org/~ummeegge/ to come to a testing round or a
fast (might be great for a longer ;) checkout without building it all
beforehand.

Best,

Erik

Re: OpenVPN cipher negotiation patch set

[Michael Tremer]

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

Hello,

> On 18 Mar 2024, at 11:27, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
> 
> Hi Erik,
> 
> On 18/03/2024 08:49, ummeegge wrote:
>> Good morning Adolf,
>> if i know in what chunks you would like to split the diff i can may
>> help you to sort things a little. Am currently not sure what should be
>> in and what not so i can offer you some explanations according to the
>> already written code and you can amend the wanted changes?!
>> So you can write me a PM and include the topics which are not clear and
>> i can try to give an explanation of the already written code.
> 
> Thanks very much. I think that could be useful.
> 
> However I will wait first as Michael is looking at doing an update related negotiation as it looks like the latest Mac OS client is failing to connect for a similar reason as some forum members using windows have been reporting.

Tunnelblick has been updated to 4.0.0 recently and disables a couple of backwards-compatible things in OpenSSL (i.e. the legacy provider). It also ships OpenVPN 2.6.9 and there seem to be problems if users have created a specific configuration.

> Once Michael has merged his changes then I can look again at what is still left as a delta and will then come back to you with my questions.
>> My time is a little less but if needed we can try it.
> I realise that, so thank you very much and I will try and focus my questions to you.
> 
> Regards,
> Adolf.
>> Best,
>> Erik
>> Am Sonntag, dem 17.03.2024 um 12:35 +0100 schrieb Adolf Belka:
>>> 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=4fbf17f4a10fbf2a0ddeae1aa436cf26f6b3a035
>>> 
>>> 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

Re: OpenVPN cipher negotiation patch set

[Michael Tremer]

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



> On 17 Mar 2024, at 15:47, Nick Howitt <nick(a)howitts.co.uk> 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.
> 
> 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.

If I remember correctly we tested that we cannot push “no compression” once the client has any kind of compression configured.

We now totally discourage using compression because it weakens the cryptography. We only have the checkbox to support installations that are old and have it enabled.

> 
> 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=4fbf17f4a10fbf2a0ddeae1aa436cf26f6b3a035 
>>>>>> 
>>>>>> 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
> 

Re: OpenVPN cipher negotiation patch set

[Michael Tremer]

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


> On 17 Mar 2024, at 14:56, Nick Howitt <nick(a)howitts.co.uk> 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, we are not explicitly supporting 2.3 but I believe it should still be working because we currently do not require cipher negotiation. It is not necessarily the version of the client, but the configuration that was generated and loaded into it that is the problem here.

> 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.

Exactly. There isn’t one. We cannot change much about that, but we can have a migration window that is large enough that most people won’t be affected by any of these problems.

> 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.

Exactly. You will find lots of emails on this list about this. It has never been implemented due to lack of time though.

> 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=4fbf17f4a10fbf2a0ddeae1aa436cf26f6b3a035 
>>>> 
>>>> 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. 
>>>> 
>>> 
> 

Re: OpenVPN cipher negotiation patch set

[Michael Tremer]

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

Thank you very much for sending this over.

I will have a look at it shortly.

> On 17 Mar 2024, at 11:35, Adolf Belka <adolf.belka(a)ipfire.org> 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=4fbf17f4a10fbf2a0ddeae1aa436cf26f6b3a035
> 
> 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.
> 

Re: OpenVPN cipher negotiation patch set

[Adolf Belka]

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

Hi Erik,

On 18/03/2024 08:49, ummeegge wrote:
> Good morning Adolf,
> if i know in what chunks you would like to split the diff i can may
> help you to sort things a little. Am currently not sure what should be
> in and what not so i can offer you some explanations according to the
> already written code and you can amend the wanted changes?!
> 
> So you can write me a PM and include the topics which are not clear and
> i can try to give an explanation of the already written code.

Thanks very much. I think that could be useful.

However I will wait first as Michael is looking at doing an update 
related negotiation as it looks like the latest Mac OS client is failing 
to connect for a similar reason as some forum members using windows have 
been reporting.

Once Michael has merged his changes then I can look again at what is 
still left as a delta and will then come back to you with my questions.
> 
> My time is a little less but if needed we can try it.
I realise that, so thank you very much and I will try and focus my 
questions to you.

Regards,
Adolf.
> 
> Best,
> 
> Erik
> 
> Am Sonntag, dem 17.03.2024 um 12:35 +0100 schrieb Adolf Belka:
>> 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=4fbf17f4a10fbf2a0ddeae1aa436cf26f6b3a035
>>
>> 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

Re: OpenVPN cipher negotiation patch set

[ummeegge]

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

Good morning Adolf,
if i know in what chunks you would like to split the diff i can may
help you to sort things a little. Am currently not sure what should be
in and what not so i can offer you some explanations according to the
already written code and you can amend the wanted changes?!

So you can write me a PM and include the topics which are not clear and
i can try to give an explanation of the already written code.

My time is a little less but if needed we can try it.

Best,

Erik

Am Sonntag, dem 17.03.2024 um 12:35 +0100 schrieb Adolf Belka:
> 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=4fbf17f4a10fbf2a0ddeae1aa436cf26f6b3a035
> 
> 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.
> 

OpenVPN cipher negotiation patch set

[Adolf Belka]

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

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=4fbf17f4a10fbf2a0ddeae1aa436cf26f6b3a035

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.