Hi Adolf,

Am Montag, dem 09.10.2023 um 19:26 +0200 schrieb Adolf Belka:

Hi All,

I thought it was too good to be true.

Before creating a client connection with something like BlowFish I thought I would just test the server settings with selecting BF in the data-ciphers-fallback selection box.

Have disabled all the 64 bit block cipher in my previouse patches since the cipher negotiaton managed the whole thing. I think AEAD ciphers are since OpenSSL-1.0.1 available so if AES-GCM is available in --data- ciphers, the clients will use them even BF-CBC is set in client.ovpn . We have had a conversation about this also with some tests which you can find in here --> https://community.ipfire.org/t/openvpn-2-6-development-version/8603/3

Then pressed Start OpenVPN Server and nothing happened. Checked the logs and there is the openssl error

OpenSSL: error:0308010C:digital envelope routines::unsupported

which occurs because Openssl-3.x doesn't support the older ciphers like BF unless legacy is selected. In this case I think it is the OpenVPN server conf file that requires the

providers legacy default

to be included, rather than the client conf file.

Still it does feel like two steps forward and one backwards so overall still making progress.

Regards,

Adolf.

Best,

Erik

On 09/10/2023 14:05, Adolf Belka wrote:

...

Hi All,

Over the last week I have been working on the openvpn update using Erik's previous patches as my starting point.

My first attempt to try and be able to understand the changes from each patch to figure out what I needed to do proved difficult for me to work with.

What I then did was take the current ovpnmain.cgi and apply all of Erik's patches to it.

Then I have gone through that new version of ovpnmain.cgi and made the changes based on previous discussions with Michael.

So I have removed the b2sum options that were present for the Data and Channel Authentication.

I also moved all the cryptographic options from an additional advanced cryptographic options button into the Advanced Server options button.

I was successful in doing all the above and then tested the ovpnmain.cgi out with a vm using the existing openvpn-2.5.9 version for openvpn.

My old profile for my laptop which had a ciphers entry worked without any problem. My laptop was working withy openvpn-2.6.6

I then created a new profile using the new ovpnmain.cgi using the negotiation option which ended up with a data-ciphers line. That also worked in making a successful openvpn tunnel with my laptop without any issues.

I then downgraded my laptop to openvpn-2.4.8 and had to install openvpn-1.1.1 to make that work.

With that client version on my laptop both the old and new profiles connected with a tunnel with no problems.

I then tried downgrading my laptop to openvpn-2.3.14 but to make this work I would have had to downgrade the laptop to openssl-1.0.0 which I was not willing to do as that is very old and very insecure.

The oldest openvpn version working with openssl-1.1.1 is 2.4.0 which is nearly 7 years old.

That version also worked with both the old and new laptop profiles.

I then tested out the openvpn server on my IPFire vm with a 2.6.0 and 2.6.6 version of openvpn.

Both these openvpn versions worked with both the old and new laptop connection profiles with my laptop on version 2.4.0 and on 2.6.6

All the above was using network manager with its openvpn plugin option on the laptop for making the openvpn tunnel connections.

As far as I can tell everything is working fine when negotiation is specified on the server. Old profiles that just use the cipher option also work fine. Therefore my plan is to only use the negotiation option and not make it selectable for older clients. The data-ciphers-fallback option in the server seems to be doing its job.

The negotiation option on the server was able to connect to a 2.4.0 client on my laptop.

According to the OpenVPN wiki on cipher negotiation the data- ciphers-fallback option will work with 2.4.x and 2.3.x clients. As the 2.3.x clients need to be using openssl-1.0.0 then I think if those clients work then fine but nothing further back.

Overall, I am very happy with what I have succeeded in doing so far. I achieved things much quicker than I had expected.

I will now try and see about creating a profile on a CU 179 based system that uses one of the old insecure ciphers such as Blow Fish and restore that into my evaluation vm and see how that works with my laptop when I have it downgraded to openvpn-2.4.0

I already know that if the laptop is at openvpn-2.6.6 then it will not accept a blowfish cipher (or another weak cipher such as DES) as that is something I tested in the past.

If that also works then my plan will be to take the updated ovpnmain.cgi and split the changes into a new range of patches and then submit them for consideration.

That will probably end up later in November as I will be busy with personal things at the end of October / beginning of November.

Regards,

Adolf.

Hi Erik,

On 11/10/2023 17:53, Adolf Belka wrote:

Hi Erik,

On 11/10/2023 16:20, ummeegge wrote:

...

Hi Adolf,

Am Montag, dem 09.10.2023 um 19:26 +0200 schrieb Adolf Belka:

...

Hi All,

I thought it was too good to be true.

Before creating a client connection with something like BlowFish I thought I would just test the server settings with selecting BF in the data-ciphers-fallback selection box.

Have disabled all the 64 bit block cipher in my previouse patches since the cipher negotiaton managed the whole thing. I think AEAD ciphers are since OpenSSL-1.0.1 available so if AES-GCM is available in --data- ciphers, the clients will use them even BF-CBC is set in client.ovpn . We have had a conversation about this also with some tests which you can find in here --> https://community.ipfire.org/t/openvpn-2-6-development-version/8603/3

Thanks for the feedback and the link to our conversation at the beginning of this year.

So even if the user has BF-CBC set in the client.ovpn, with the server having server negotiation in this update then the client will end up getting connected with an available cipher from the data-ciphers list. I will do a test of that then on my system

Confirmed with my testing, as you predicted, that with a client connection profile having cipher set as BF-CBC running on a client with openvpn-4.0.0 resulted in the negotiation process ignoring the BF-CBC cipher and ending up with AES-GCM being used to successfully create an openvpn tunnel.

Regards, Adolf.

If my understanding is correct, then why do we need to still leave the weak ciphers in the data-fallback list. Those could also be removed, they are blocked anyway.

OpenVPN plan to remove those weak ciphers completely in version 2.7 If a user at that time still had a client with say BF-CBC would the negotiation still work then or would it fail because OpenVPN no longer recognises the old weak cipher?

Regards,

Adolf.

...

...

Then pressed Start OpenVPN Server and nothing happened. Checked the logs and there is the openssl error

OpenSSL: error:0308010C:digital envelope routines::unsupported

which occurs because Openssl-3.x doesn't support the older ciphers like BF unless legacy is selected. In this case I think it is the OpenVPN server conf file that requires the

providers legacy default

to be included, rather than the client conf file.

Still it does feel like two steps forward and one backwards so overall still making progress.

Regards,

Adolf.

Best,

Erik

...

On 09/10/2023 14:05, Adolf Belka wrote:

...

Hi All,

Over the last week I have been working on the openvpn update using Erik's previous patches as my starting point.

My first attempt to try and be able to understand the changes from each patch to figure out what I needed to do proved difficult for me to work with.

What I then did was take the current ovpnmain.cgi and apply all of Erik's patches to it.

Then I have gone through that new version of ovpnmain.cgi and made the changes based on previous discussions with Michael.

So I have removed the b2sum options that were present for the Data and Channel Authentication.

I also moved all the cryptographic options from an additional advanced cryptographic options button into the Advanced Server options button.

I was successful in doing all the above and then tested the ovpnmain.cgi out with a vm using the existing openvpn-2.5.9 version for openvpn.

My old profile for my laptop which had a ciphers entry worked without any problem. My laptop was working withy openvpn-2.6.6

I then created a new profile using the new ovpnmain.cgi using the negotiation option which ended up with a data-ciphers line. That also worked in making a successful openvpn tunnel with my laptop without any issues.

I then downgraded my laptop to openvpn-2.4.8 and had to install openvpn-1.1.1 to make that work.

With that client version on my laptop both the old and new profiles connected with a tunnel with no problems.

I then tried downgrading my laptop to openvpn-2.3.14 but to make this work I would have had to downgrade the laptop to openssl-1.0.0 which I was not willing to do as that is very old and very insecure.

The oldest openvpn version working with openssl-1.1.1 is 2.4.0 which is nearly 7 years old.

That version also worked with both the old and new laptop profiles.

I then tested out the openvpn server on my IPFire vm with a 2.6.0 and 2.6.6 version of openvpn.

Both these openvpn versions worked with both the old and new laptop connection profiles with my laptop on version 2.4.0 and on 2.6.6

All the above was using network manager with its openvpn plugin option on the laptop for making the openvpn tunnel connections.

As far as I can tell everything is working fine when negotiation is specified on the server. Old profiles that just use the cipher option also work fine. Therefore my plan is to only use the negotiation option and not make it selectable for older clients. The data-ciphers-fallback option in the server seems to be doing its job.

The negotiation option on the server was able to connect to a 2.4.0 client on my laptop.

According to the OpenVPN wiki on cipher negotiation the data- ciphers-fallback option will work with 2.4.x and 2.3.x clients. As the 2.3.x clients need to be using openssl-1.0.0 then I think if those clients work then fine but nothing further back.

Overall, I am very happy with what I have succeeded in doing so far. I achieved things much quicker than I had expected.

I will now try and see about creating a profile on a CU 179 based system that uses one of the old insecure ciphers such as Blow Fish and restore that into my evaluation vm and see how that works with my laptop when I have it downgraded to openvpn-2.4.0

I already know that if the laptop is at openvpn-2.6.6 then it will not accept a blowfish cipher (or another weak cipher such as DES) as that is something I tested in the past.

If that also works then my plan will be to take the updated ovpnmain.cgi and split the changes into a new range of patches and then submit them for consideration.

That will probably end up later in November as I will be busy with personal things at the end of October / beginning of November.

Regards,

Adolf.

Am Donnerstag, dem 12.10.2023 um 07:56 +0200 schrieb ummeegge:

...

OpenVPN plan to remove those weak ciphers completely in version 2.7 If a user at that time still had a client with say BF-CBC would the negotiation still work then or would it fail because OpenVPN no longer recognises the old weak cipher?

This is true according to the OpenVPN 'Deprecated Option' wiki --> https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Policy:Migratea... that´s causes, beneath the OpenSSL-3.x decision, to leave the deprecated ciphers out of the Roadwarrior list (N2N is another thing since it do no understands cipher negotiation) but pushed at that time an idea to bring on some warnings for the users before the IPFire decision to leave the broken ciphers out of any list since the server can not see what client configuration is in place.

To correct this statement, mostly users do not see/recognize such warnings in the OpenVPN logs, the server does see it!

This patch can be found in here --> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=dd11f427...

...

Regards,

Adolf.

Best,

Erik

...

...

...

Then pressed Start OpenVPN Server and nothing happened. Checked the logs and there is the openssl error

OpenSSL: error:0308010C:digital envelope routines::unsupported

which occurs because Openssl-3.x doesn't support the older ciphers like BF unless legacy is selected. In this case I think it is the OpenVPN server conf file that requires the

providers legacy default

to be included, rather than the client conf file.

Still it does feel like two steps forward and one backwards so overall still making progress.

Regards,

Adolf.

Best,

Erik

...

On 09/10/2023 14:05, Adolf Belka wrote:

...

Hi All,

Over the last week I have been working on the openvpn update using Erik's previous patches as my starting point.

My first attempt to try and be able to understand the changes from each patch to figure out what I needed to do proved difficult for me to work with.

What I then did was take the current ovpnmain.cgi and apply all of Erik's patches to it.

Then I have gone through that new version of ovpnmain.cgi and made the changes based on previous discussions with Michael.

So I have removed the b2sum options that were present for the Data and Channel Authentication.

I also moved all the cryptographic options from an additional advanced cryptographic options button into the Advanced Server options button.

I was successful in doing all the above and then tested the ovpnmain.cgi out with a vm using the existing openvpn-2.5.9 version for openvpn.

My old profile for my laptop which had a ciphers entry worked without any problem. My laptop was working withy openvpn- 2.6.6

I then created a new profile using the new ovpnmain.cgi using the negotiation option which ended up with a data-ciphers line. That also worked in making a successful openvpn tunnel with my laptop without any issues.

I then downgraded my laptop to openvpn-2.4.8 and had to install openvpn-1.1.1 to make that work.

With that client version on my laptop both the old and new profiles connected with a tunnel with no problems.

I then tried downgrading my laptop to openvpn-2.3.14 but to make this work I would have had to downgrade the laptop to openssl- 1.0.0 which I was not willing to do as that is very old and very insecure.

The oldest openvpn version working with openssl-1.1.1 is 2.4.0 which is nearly 7 years old.

That version also worked with both the old and new laptop profiles.

I then tested out the openvpn server on my IPFire vm with a 2.6.0 and 2.6.6 version of openvpn.

Both these openvpn versions worked with both the old and new laptop connection profiles with my laptop on version 2.4.0 and on 2.6.6

All the above was using network manager with its openvpn plugin option on the laptop for making the openvpn tunnel connections.

As far as I can tell everything is working fine when negotiation is specified on the server. Old profiles that just use the cipher option also work fine. Therefore my plan is to only use the negotiation option and not make it selectable for older clients. The data-ciphers-fallback option in the server seems to be doing its job.

The negotiation option on the server was able to connect to a 2.4.0 client on my laptop.

According to the OpenVPN wiki on cipher negotiation the data- ciphers-fallback option will work with 2.4.x and 2.3.x clients. As the 2.3.x clients need to be using openssl-1.0.0 then I think if those clients work then fine but nothing further back.

Overall, I am very happy with what I have succeeded in doing so far. I achieved things much quicker than I had expected.

I will now try and see about creating a profile on a CU 179 based system that uses one of the old insecure ciphers such as Blow Fish and restore that into my evaluation vm and see how that works with my laptop when I have it downgraded to openvpn-2.4.0

I already know that if the laptop is at openvpn-2.6.6 then it will not accept a blowfish cipher (or another weak cipher such as DES) as that is something I tested in the past.

If that also works then my plan will be to take the updated ovpnmain.cgi and split the changes into a new range of patches and then submit them for consideration.

That will probably end up later in November as I will be busy with personal things at the end of October / beginning of November.

Regards,

Adolf.

Your welcome. If you are in state of completing the blog post you can send it again to overread it so we all can speak about it, as an offer from me.

I would really also recommend to make the cipher renegotiation configurable via WUI. Since the release of 2FA it has been hardcoded  --> https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=html/cgi-bin/ovpnmain.cgi;... to 48 hours which in a practical way or in fact disables the PFS also for users which do not use 2FA whereby the OpenVPN default, also with potential secure ciphers, are configured to 1 hour to renegotiate a new session key.

Best,

Erik

Am Donnerstag, dem 12.10.2023 um 11:36 +0200 schrieb Adolf Belka:

Hi Erik,

On 12/10/2023 08:06, ummeegge wrote:

...

Am Donnerstag, dem 12.10.2023 um 07:56 +0200 schrieb ummeegge:

...

...

OpenVPN plan to remove those weak ciphers completely in version 2.7 If a user at that time still had a client with say BF-CBC would the negotiation still work then or would it fail because OpenVPN no longer recognises the old weak cipher?

This is true according to the OpenVPN 'Deprecated Option' wiki --

...

https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Policy:Migratea...

I had seen that overall page before but obviously not read the details well enough of that specific entry. The entry makes it clear that from openvpn-2.7 onwards the 64 bit ciphers will no longer be accepted even as data-fallback ones.

...

...

that´s causes, beneath the OpenSSL-3.x decision, to leave the deprecated ciphers out of the Roadwarrior list (N2N is another thing since it do no understands cipher negotiation) but pushed at that time an idea to bring on some warnings for the users before the IPFire decision to leave the broken ciphers out of any list since the server can not see what client configuration is in place.

To correct this statement, mostly users do not see/recognize such warnings in the  OpenVPN logs, the server does see it!

I see what you are saying. The users tend not to look at their logs and so will miss the message about the 64 bit BF-CBC etc being removed from 2.7 onwards.

So having the 64 bit ciphers in the data-fallback table but not allowing them to be used and instead giving a warning message about the cipher being removed in the future is a way to make the changes more visible that the user needs to do and the potential timing scenario.

I think I will also need to put together a supporting info blog post on the openvpn changes that will come with the IPFire updates being worked on and the future ones with openvpn-2.7

...

...

This patch can be found in here --> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=dd11f427...

Thanks for the clarification.

Regards, Adolf.

...

...

...

Regards,

Adolf.

Best,

Erik

...

...

...

Then pressed Start OpenVPN Server and nothing happened. Checked the logs and there is the openssl error

OpenSSL: error:0308010C:digital envelope routines::unsupported

which occurs because Openssl-3.x doesn't support the older ciphers like BF unless legacy is selected. In this case I think it is the OpenVPN server conf file that requires the

providers legacy default

to be included, rather than the client conf file.

Still it does feel like two steps forward and one backwards so overall still making progress.

Regards,

Adolf.

Best,

Erik

...

On 09/10/2023 14:05, Adolf Belka wrote: > Hi All, > > > Over the last week I have been working on the openvpn > update > using > Erik's previous patches as my starting point. > > My first attempt to try and be able to understand the > changes > from > each patch to figure out what I needed to do proved > difficult > for > me to work with. > > What I then did was take the current ovpnmain.cgi and > apply > all > of > Erik's patches to it. > > Then I have gone through that new version of ovpnmain.cgi > and > made > the changes based on previous discussions with Michael. > > So I have removed the b2sum options that were present for > the > Data > and Channel Authentication. > > I also moved all the cryptographic options from an > additional > advanced cryptographic options button into the Advanced > Server > options button. > > I was successful in doing all the above and then tested > the > ovpnmain.cgi out with a vm using the existing openvpn- > 2.5.9 > version > for openvpn. > > My old profile for my laptop which had a ciphers entry > worked > without any problem. My laptop was working withy openvpn- > 2.6.6 > > I then created a new profile using the new ovpnmain.cgi > using > the > negotiation option which ended up with a data-ciphers > line. > That > also worked in making a successful openvpn tunnel with my > laptop > without any issues. > > I then downgraded my laptop to openvpn-2.4.8 and had to > install > openvpn-1.1.1 to make that work. > > With that client version on my laptop both the old and > new > profiles > connected with a tunnel with no problems. > > I then tried downgrading my laptop to openvpn-2.3.14 but > to > make > this work I would have had to downgrade the laptop to > openssl- > 1.0.0 > which I was not willing to do as that is very old and > very > insecure. > > The oldest openvpn version working with openssl-1.1.1 is > 2.4.0 > which is nearly 7 years old. > > That version also worked with both the old and new laptop > profiles. > > I then tested out the openvpn server on my IPFire vm with > a > 2.6.0 > and 2.6.6 version of openvpn. > > Both these openvpn versions worked with both the old and > new > laptop > connection profiles with my laptop on version 2.4.0 and > on > 2.6.6 > > All the above was using network manager with its openvpn > plugin > option on the laptop for making the openvpn tunnel > connections. > > As far as I can tell everything is working fine when > negotiation is > specified on the server. Old profiles that just use the > cipher > option also work fine. Therefore my plan is to only use > the > negotiation option and not make it selectable for older > clients. > The data-ciphers-fallback option in the server seems to > be > doing > its job. > > The negotiation option on the server was able to connect > to a > 2.4.0 > client on my laptop. > > According to the OpenVPN wiki on cipher negotiation the > data- > ciphers-fallback option will work with 2.4.x and 2.3.x > clients. > As > the 2.3.x clients need to be using openssl-1.0.0 then I > think > if > those clients work then fine but nothing further back. > > Overall, I am very happy with what I have succeeded in > doing > so > far. I achieved things much quicker than I had expected. > > I will now try and see about creating a profile on a CU > 179 > based > system that uses one of the old insecure ciphers such as > Blow > Fish > and restore that into my evaluation vm and see how that > works > with > my laptop when I have it downgraded to openvpn-2.4.0 > > I already know that if the laptop is at openvpn-2.6.6 > then it > will > not accept a blowfish cipher (or another weak cipher such > as > DES) > as that is something I tested in the past. > > If that also works then my plan will be to take the > updated > ovpnmain.cgi and split the changes into a new range of > patches > and > then submit them for consideration. > > That will probably end up later in November as I will be > busy > with > personal things at the end of October / beginning of > November. > > > Regards, > > Adolf. >

Oh it looks you had the same idea that I had :) Very nice :)

On 13 Oct 2023, at 13:52, Adolf Belka adolf.belka@ipfire.org wrote:

Hi Erik,

On 12/10/2023 13:30, ummeegge wrote:

...

Your welcome. If you are in state of completing the blog post you can send it again to overread it so we all can speak about it, as an offer from me. I would really also recommend to make the cipher renegotiation configurable via WUI. Since the release of 2FA it has been hardcoded --> https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=html/cgi-bin/ovpnmain.cgi;... to 48 hours which in a practical way or in fact disables the PFS also for users which do not use 2FA whereby the OpenVPN default, also with potential secure ciphers, are configured to 1 hour to renegotiate a new session key.

The problem with making it configurable from the WUI is that there is only one value that the server can have so users that have client connections with and without OTP would have to make a choice between one or the other.

I have looked through the OpenVPN info on reneg-sec and found that it can be specified on both the server but also on each client and for a specific client the timer that will time out first is the lower value of the one in both ends.

I have tested this out on my laptop with a direct openvpn cli connection and via the network manager openvpn plugin and also on my android phone via the OpenVPN for Android app.

In all three cases I added reneg-sec 30 to the .ovpn profile and then installed it.

I then was able to successfully make a connection and every 30 secs I saw in the logs that the connection was renegotiated in all three cases.

So the current server value can be left as it is and for clients with the OTP option checked they can have the same reneg-sec as currently in the server and for clients without the OTP checked they can have a reneg-sec value of one hour, which will trigger before the server value.

It could already be that in some cases this is happening anyway as the default value for reneg-sec if not specified is 3600 so it depends what the clients are doing with that default value. I would need to run a test with the three above options where I leave the systems connected via OpenVPN and see what happens after one hour (the default value for reneg-sec) but I am not sure when I will have time for that.

I think it will be good to explicitly specify the reneg-sec on both OTP and non-OTP clients so that the default value doesn't cause unexpected consequences.

Regards, Adolf.

...

Best, Erik Am Donnerstag, dem 12.10.2023 um 11:36 +0200 schrieb Adolf Belka:

...

Hi Erik,

On 12/10/2023 08:06, ummeegge wrote:

...

Am Donnerstag, dem 12.10.2023 um 07:56 +0200 schrieb ummeegge:

...

...

OpenVPN plan to remove those weak ciphers completely in version 2.7 If a user at that time still had a client with say BF-CBC would the negotiation still work then or would it fail because OpenVPN no longer recognises the old weak cipher?

This is true according to the OpenVPN 'Deprecated Option' wiki --

...

https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Policy:Migratea...

I had seen that overall page before but obviously not read the details well enough of that specific entry. The entry makes it clear that from openvpn-2.7 onwards the 64 bit ciphers will no longer be accepted even as data-fallback ones.

...

...

that´s causes, beneath the OpenSSL-3.x decision, to leave the deprecated ciphers out of the Roadwarrior list (N2N is another thing since it do no understands cipher negotiation) but pushed at that time an idea to bring on some warnings for the users before the IPFire decision to leave the broken ciphers out of any list since the server can not see what client configuration is in place.

To correct this statement, mostly users do not see/recognize such warnings in the OpenVPN logs, the server does see it!

I see what you are saying. The users tend not to look at their logs and so will miss the message about the 64 bit BF-CBC etc being removed from 2.7 onwards.

So having the 64 bit ciphers in the data-fallback table but not allowing them to be used and instead giving a warning message about the cipher being removed in the future is a way to make the changes more visible that the user needs to do and the potential timing scenario.

I think I will also need to put together a supporting info blog post on the openvpn changes that will come with the IPFire updates being worked on and the future ones with openvpn-2.7

...

...

This patch can be found in here --> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=dd11f427...

Thanks for the clarification.

Regards, Adolf.

...

...

...

Regards,

Adolf.

Best,

Erik

...

>> Then pressed Start OpenVPN Server and nothing happened. >> Checked >> the >> logs and there is the openssl error >> >> OpenSSL: error:0308010C:digital envelope >> routines::unsupported >> >> which occurs because Openssl-3.x doesn't support the older >> ciphers >> like BF unless legacy is selected. In this case I think it >> is >> the >> OpenVPN server conf file that requires the >> >> providers legacy default >> >> to be included, rather than the client conf file. >> >> Still it does feel like two steps forward and one backwards >> so >> overall still making progress. >> >> >> Regards, >> >> Adolf. > Best, > > Erik >> On 09/10/2023 14:05, Adolf Belka wrote: >>> Hi All, >>> >>> >>> Over the last week I have been working on the openvpn >>> update >>> using >>> Erik's previous patches as my starting point. >>> >>> My first attempt to try and be able to understand the >>> changes >>> from >>> each patch to figure out what I needed to do proved >>> difficult >>> for >>> me to work with. >>> >>> What I then did was take the current ovpnmain.cgi and >>> apply >>> all >>> of >>> Erik's patches to it. >>> >>> Then I have gone through that new version of ovpnmain.cgi >>> and >>> made >>> the changes based on previous discussions with Michael. >>> >>> So I have removed the b2sum options that were present for >>> the >>> Data >>> and Channel Authentication. >>> >>> I also moved all the cryptographic options from an >>> additional >>> advanced cryptographic options button into the Advanced >>> Server >>> options button. >>> >>> I was successful in doing all the above and then tested >>> the >>> ovpnmain.cgi out with a vm using the existing openvpn- >>> 2.5.9 >>> version >>> for openvpn. >>> >>> My old profile for my laptop which had a ciphers entry >>> worked >>> without any problem. My laptop was working withy openvpn- >>> 2.6.6 >>> >>> I then created a new profile using the new ovpnmain.cgi >>> using >>> the >>> negotiation option which ended up with a data-ciphers >>> line. >>> That >>> also worked in making a successful openvpn tunnel with my >>> laptop >>> without any issues. >>> >>> I then downgraded my laptop to openvpn-2.4.8 and had to >>> install >>> openvpn-1.1.1 to make that work. >>> >>> With that client version on my laptop both the old and >>> new >>> profiles >>> connected with a tunnel with no problems. >>> >>> I then tried downgrading my laptop to openvpn-2.3.14 but >>> to >>> make >>> this work I would have had to downgrade the laptop to >>> openssl- >>> 1.0.0 >>> which I was not willing to do as that is very old and >>> very >>> insecure. >>> >>> The oldest openvpn version working with openssl-1.1.1 is >>> 2.4.0 >>> which is nearly 7 years old. >>> >>> That version also worked with both the old and new laptop >>> profiles. >>> >>> I then tested out the openvpn server on my IPFire vm with >>> a >>> 2.6.0 >>> and 2.6.6 version of openvpn. >>> >>> Both these openvpn versions worked with both the old and >>> new >>> laptop >>> connection profiles with my laptop on version 2.4.0 and >>> on >>> 2.6.6 >>> >>> All the above was using network manager with its openvpn >>> plugin >>> option on the laptop for making the openvpn tunnel >>> connections. >>> >>> As far as I can tell everything is working fine when >>> negotiation is >>> specified on the server. Old profiles that just use the >>> cipher >>> option also work fine. Therefore my plan is to only use >>> the >>> negotiation option and not make it selectable for older >>> clients. >>> The data-ciphers-fallback option in the server seems to >>> be >>> doing >>> its job. >>> >>> The negotiation option on the server was able to connect >>> to a >>> 2.4.0 >>> client on my laptop. >>> >>> According to the OpenVPN wiki on cipher negotiation the >>> data- >>> ciphers-fallback option will work with 2.4.x and 2.3.x >>> clients. >>> As >>> the 2.3.x clients need to be using openssl-1.0.0 then I >>> think >>> if >>> those clients work then fine but nothing further back. >>> >>> Overall, I am very happy with what I have succeeded in >>> doing >>> so >>> far. I achieved things much quicker than I had expected. >>> >>> I will now try and see about creating a profile on a CU >>> 179 >>> based >>> system that uses one of the old insecure ciphers such as >>> Blow >>> Fish >>> and restore that into my evaluation vm and see how that >>> works >>> with >>> my laptop when I have it downgraded to openvpn-2.4.0 >>> >>> I already know that if the laptop is at openvpn-2.6.6 >>> then it >>> will >>> not accept a blowfish cipher (or another weak cipher such >>> as >>> DES) >>> as that is something I tested in the past. >>> >>> If that also works then my plan will be to take the >>> updated >>> ovpnmain.cgi and split the changes into a new range of >>> patches >>> and >>> then submit them for consideration. >>> >>> That will probably end up later in November as I will be >>> busy >>> with >>> personal things at the end of October / beginning of >>> November. >>> >>> >>> Regards, >>> >>> Adolf. >>>

-- Sent from my laptop

Hi all,

Am Freitag, dem 13.10.2023 um 14:52 +0200 schrieb Adolf Belka:

Hi Erik,

On 12/10/2023 13:30, ummeegge wrote:

...

Your welcome. If you are in state of completing the blog post you can send it again to overread it so we all can speak about it, as an offer from me.

I would really also recommend to make the cipher renegotiation configurable via WUI. Since the release of 2FA it has been hardcoded --> https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=html/cgi-bin/ovpnmain.cgi;... to 48 hours which in a practical way or in fact disables the PFS also for users which do not use 2FA whereby the OpenVPN default, also with potential secure ciphers, are configured to 1 hour to renegotiate a new session key.

The problem with making it configurable from the WUI is that there is only one value that the server can have so users that have client connections with and without OTP would have to make a choice between one or the other.

Client and server can have different '--reneg-sec' values but it makes no sense to configure it in such way since the earlier value triggers the renegotiation of the session key and will never reach the later one cause it starts then again with 0.

I have looked through the OpenVPN info on reneg-sec and found that it can be specified on both the server but also on each client and for a specific client the timer that will time out first is the lower value of the one in both ends.

Yes, and the counter starts then from the beginning.

I have tested this out on my laptop with a direct openvpn cli connection and via the network manager openvpn plugin and also on my android phone via the OpenVPN for Android app.

In all three cases I added reneg-sec 30 to the .ovpn profile and then installed it.

I then was able to successfully make a connection and every 30 secs I saw in the logs that the connection was renegotiated in all three cases.

It can also be used with pkts [n] and bytes [n] which OpenVPN is using if 64 bit block ciphers are configured and renegotiates after 64 MB of transfered data. This was the consequences after the SWEET32 birthday attacks --> https://sweet32.info . But if '--reneg-*' has been configured the internal OpenVPN defaults won´t be used.

So the current server value can be left as it is and for clients with the OTP option checked they can have the same reneg-sec as currently in the server and for clients without the OTP checked they can have a reneg-sec value of one hour, which will trigger before the server value.

I think this won´t work since whichever (server or client) uses the lower value will be the one who triggers the renegotiation and the counter starts then by 0 again. So this is a kind of a global setting and can not be triggered ealier for some and ater for others in my opinion --> https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/ .

It could already be that in some cases this is happening anyway as the default value for reneg-sec if not specified is 3600 so it depends what the clients are doing with that default value. I would need to run a test with the three above options where I leave the systems connected via OpenVPN and see what happens after one hour (the default value for reneg-sec) but I am not sure when I will have time for that.

Adolf, i would test also the '--auth-(gen-)token' directive --> https://github.com/OpenVPN/openvpn3/blob/master/doc/webauth.md#auth-token-us... (very old discussion!) may this can be a solution to bypass the whole reneg-sec discussion around 2FA and leave the server to 3600 sec´s or make it even configuerable cause 2FA users uses it, i think, for mostly clients. I can not test this sinec 2FA on IPFire never works for me!

I think it will be good to explicitly specify the reneg-sec on both OTP and non-OTP clients so that the default value doesn't cause unexpected consequences.

Please check also the OpenVPN manpage --

https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/

in section "Data Channel Renegotiation" according the above questions and potential testing scenarios.

Regards, Adolf.

...

Best,

Erik

Best,

Erik

...

Am Donnerstag, dem 12.10.2023 um 11:36 +0200 schrieb Adolf Belka:

...

Hi Erik,

On 12/10/2023 08:06, ummeegge wrote:

...

Am Donnerstag, dem 12.10.2023 um 07:56 +0200 schrieb ummeegge:

...

...

OpenVPN plan to remove those weak ciphers completely in version 2.7 If a user at that time still had a client with say BF-CBC would the negotiation still work then or would it fail because OpenVPN no longer recognises the old weak cipher?

This is true according to the OpenVPN 'Deprecated Option' wiki --

...

https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Policy:Migratea...

I had seen that overall page before but obviously not read the details well enough of that specific entry. The entry makes it clear that from openvpn-2.7 onwards the 64 bit ciphers will no longer be accepted even as data-fallback ones.

...

...

that´s causes, beneath the OpenSSL-3.x decision, to leave the deprecated ciphers out of the Roadwarrior list (N2N is another thing since it do no understands cipher negotiation) but pushed at that time an idea to bring on some warnings for the users before the IPFire decision to leave the broken ciphers out of any list since the server can not see what client configuration is in place.

To correct this statement, mostly users do not see/recognize such warnings in the  OpenVPN logs, the server does see it!

I see what you are saying. The users tend not to look at their logs and so will miss the message about the 64 bit BF-CBC etc being removed from 2.7 onwards.

So having the 64 bit ciphers in the data-fallback table but not allowing them to be used and instead giving a warning message about the cipher being removed in the future is a way to make the changes more visible that the user needs to do and the potential timing scenario.

I think I will also need to put together a supporting info blog post on the openvpn changes that will come with the IPFire updates being worked on and the future ones with openvpn-2.7

...

...

This patch can be found in here --> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=dd11f427...

Thanks for the clarification.

Regards, Adolf.

...

...

...

Regards,

Adolf.

Best,

Erik

...

> > Then pressed Start OpenVPN Server and nothing happened. > > Checked > > the > > logs and there is the openssl error > > > > OpenSSL: error:0308010C:digital envelope > > routines::unsupported > > > > which occurs because Openssl-3.x doesn't support the > > older > > ciphers > > like BF unless legacy is selected. In this case I think > > it > > is > > the > > OpenVPN server conf file that requires the > > > > providers legacy default > > > > to be included, rather than the client conf file. > > > > Still it does feel like two steps forward and one > > backwards > > so > > overall still making progress. > > > > > > Regards, > > > > Adolf. > Best, > > Erik > > On 09/10/2023 14:05, Adolf Belka wrote: > > > Hi All, > > > > > > > > > Over the last week I have been working on the openvpn > > > update > > > using > > > Erik's previous patches as my starting point. > > > > > > My first attempt to try and be able to understand the > > > changes > > > from > > > each patch to figure out what I needed to do proved > > > difficult > > > for > > > me to work with. > > > > > > What I then did was take the current ovpnmain.cgi and > > > apply > > > all > > > of > > > Erik's patches to it. > > > > > > Then I have gone through that new version of > > > ovpnmain.cgi > > > and > > > made > > > the changes based on previous discussions with > > > Michael. > > > > > > So I have removed the b2sum options that were present > > > for > > > the > > > Data > > > and Channel Authentication. > > > > > > I also moved all the cryptographic options from an > > > additional > > > advanced cryptographic options button into the > > > Advanced > > > Server > > > options button. > > > > > > I was successful in doing all the above and then > > > tested > > > the > > > ovpnmain.cgi out with a vm using the existing > > > openvpn- > > > 2.5.9 > > > version > > > for openvpn. > > > > > > My old profile for my laptop which had a ciphers > > > entry > > > worked > > > without any problem. My laptop was working withy > > > openvpn- > > > 2.6.6 > > > > > > I then created a new profile using the new > > > ovpnmain.cgi > > > using > > > the > > > negotiation option which ended up with a data-ciphers > > > line. > > > That > > > also worked in making a successful openvpn tunnel > > > with my > > > laptop > > > without any issues. > > > > > > I then downgraded my laptop to openvpn-2.4.8 and had > > > to > > > install > > > openvpn-1.1.1 to make that work. > > > > > > With that client version on my laptop both the old > > > and > > > new > > > profiles > > > connected with a tunnel with no problems. > > > > > > I then tried downgrading my laptop to openvpn-2.3.14 > > > but > > > to > > > make > > > this work I would have had to downgrade the laptop to > > > openssl- > > > 1.0.0 > > > which I was not willing to do as that is very old and > > > very > > > insecure. > > > > > > The oldest openvpn version working with openssl-1.1.1 > > > is > > > 2.4.0 > > > which is nearly 7 years old. > > > > > > That version also worked with both the old and new > > > laptop > > > profiles. > > > > > > I then tested out the openvpn server on my IPFire vm > > > with > > > a > > > 2.6.0 > > > and 2.6.6 version of openvpn. > > > > > > Both these openvpn versions worked with both the old > > > and > > > new > > > laptop > > > connection profiles with my laptop on version 2.4.0 > > > and > > > on > > > 2.6.6 > > > > > > All the above was using network manager with its > > > openvpn > > > plugin > > > option on the laptop for making the openvpn tunnel > > > connections. > > > > > > As far as I can tell everything is working fine when > > > negotiation is > > > specified on the server. Old profiles that just use > > > the > > > cipher > > > option also work fine. Therefore my plan is to only > > > use > > > the > > > negotiation option and not make it selectable for > > > older > > > clients. > > > The data-ciphers-fallback option in the server seems > > > to > > > be > > > doing > > > its job. > > > > > > The negotiation option on the server was able to > > > connect > > > to a > > > 2.4.0 > > > client on my laptop. > > > > > > According to the OpenVPN wiki on cipher negotiation > > > the > > > data- > > > ciphers-fallback option will work with 2.4.x and > > > 2.3.x > > > clients. > > > As > > > the 2.3.x clients need to be using openssl-1.0.0 then > > > I > > > think > > > if > > > those clients work then fine but nothing further > > > back. > > > > > > Overall, I am very happy with what I have succeeded > > > in > > > doing > > > so > > > far. I achieved things much quicker than I had > > > expected. > > > > > > I will now try and see about creating a profile on a > > > CU > > > 179 > > > based > > > system that uses one of the old insecure ciphers such > > > as > > > Blow > > > Fish > > > and restore that into my evaluation vm and see how > > > that > > > works > > > with > > > my laptop when I have it downgraded to openvpn-2.4.0 > > > > > > I already know that if the laptop is at openvpn-2.6.6 > > > then it > > > will > > > not accept a blowfish cipher (or another weak cipher > > > such > > > as > > > DES) > > > as that is something I tested in the past. > > > > > > If that also works then my plan will be to take the > > > updated > > > ovpnmain.cgi and split the changes into a new range > > > of > > > patches > > > and > > > then submit them for consideration. > > > > > > That will probably end up later in November as I will > > > be > > > busy > > > with > > > personal things at the end of October / beginning of > > > November. > > > > > > > > > Regards, > > > > > > Adolf. > > >

Hi all,

On 18/10/2023 20:48, Michael Tremer wrote:

Hello,

...

On 18 Oct 2023, at 10:05, ummeegge ummeegge@ipfire.org wrote:

Hi all,

Am Freitag, dem 13.10.2023 um 14:52 +0200 schrieb Adolf Belka:

...

Hi Erik,

On 12/10/2023 13:30, ummeegge wrote:

...

Your welcome. If you are in state of completing the blog post you can send it again to overread it so we all can speak about it, as an offer from me.

I would really also recommend to make the cipher renegotiation configurable via WUI. Since the release of 2FA it has been hardcoded --> https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=html/cgi-bin/ovpnmain.cgi;... to 48 hours which in a practical way or in fact disables the PFS also for users which do not use 2FA whereby the OpenVPN default, also with potential secure ciphers, are configured to 1 hour to renegotiate a new session key.

The problem with making it configurable from the WUI is that there is only one value that the server can have so users that have client connections with and without OTP would have to make a choice between one or the other.

Client and server can have different '--reneg-sec' values but it makes no sense to configure it in such way since the earlier value triggers the renegotiation of the session key and will never reach the later one cause it starts then again with 0.

Ah okay, I think I overlooked the aspect here that the default comes even for the client.

It is potentially a bad design choice then that the protocol cannot rekey without reauthentication.

We could try to push this from the server side maybe? That would at least indicate some SHOULD value. If the client does not honour it, we cannot do anything about that.

I disagree that this will not work as I have tested it and it worked.

I had a standard system with the server set to 86400 secs.

I then added into the client profile for my laptop reneg-sec 30.

So server with 86400 client with 30

Result the server renegotiated every 30 secs. I had the reneg occur 5 times. This is what is wanted.

Alternative would be another client with reneg-sec set to 86400 to be used for OTP connection.

So server with 86400 client set to 86400 This should result in renegotiation somewhere between 77760 secs (90% 86400 secs) and 86400 secs, randomly selected.

I didn't test this as I didn't have a spare 48 hours to test and also I have not found an openvpn client that I use that works with OTP.

Regards,

Adolf.

...

...

I have looked through the OpenVPN info on reneg-sec and found that it can be specified on both the server but also on each client and for a specific client the timer that will time out first is the lower value of the one in both ends.

Yes, and the counter starts then from the beginning.

...

I have tested this out on my laptop with a direct openvpn cli connection and via the network manager openvpn plugin and also on my android phone via the OpenVPN for Android app.

In all three cases I added reneg-sec 30 to the .ovpn profile and then installed it.

I then was able to successfully make a connection and every 30 secs I saw in the logs that the connection was renegotiated in all three cases.

It can also be used with pkts [n] and bytes [n] which OpenVPN is using if 64 bit block ciphers are configured and renegotiates after 64 MB of transfered data. This was the consequences after the SWEET32 birthday attacks --> https://sweet32.info . But if '--reneg-*' has been configured the internal OpenVPN defaults won´t be used.

I am not aware that anyone has ever reported that they need to re-enter the OTP after hitting a certain amount of data.

If so, we need to disable this for OTP-enabled clients. The rationale would be that because we have stronger authentication, we can afford to have fewer rekeys - which I personally disagree with.

...

...

So the current server value can be left as it is and for clients with the OTP option checked they can have the same reneg-sec as currently in the server and for clients without the OTP checked they can have a reneg-sec value of one hour, which will trigger before the server value.

I think this won´t work since whichever (server or client) uses the lower value will be the one who triggers the renegotiation and the counter starts then by 0 again. So this is a kind of a global setting and can not be triggered ealier for some and ater for others in my opinion --> https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/ .

That is a correct statement.

...

...

It could already be that in some cases this is happening anyway as the default value for reneg-sec if not specified is 3600 so it depends what the clients are doing with that default value. I would need to run a test with the three above options where I leave the systems connected via OpenVPN and see what happens after one hour (the default value for reneg-sec) but I am not sure when I will have time for that.

Adolf, i would test also the '--auth-(gen-)token' directive --> https://github.com/OpenVPN/openvpn3/blob/master/doc/webauth.md#auth-token-us... (very old discussion!) may this can be a solution to bypass the whole reneg-sec discussion around 2FA and leave the server to 3600 sec´s or make it even configuerable cause 2FA users uses it, i think, for mostly clients. I can not test this sinec 2FA on IPFire never works for me!

Why not?

...

...

I think it will be good to explicitly specify the reneg-sec on both OTP and non-OTP clients so that the default value doesn't cause unexpected consequences.

Please check also the OpenVPN manpage --

...

https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/

in section "Data Channel Renegotiation" according the above questions and potential testing scenarios.

...

Regards, Adolf.

...

Best,

Erik

Best,

Erik

...

...

Am Donnerstag, dem 12.10.2023 um 11:36 +0200 schrieb Adolf Belka:

...

Hi Erik,

On 12/10/2023 08:06, ummeegge wrote:

...

Am Donnerstag, dem 12.10.2023 um 07:56 +0200 schrieb ummeegge: >> OpenVPN plan to remove those weak ciphers completely in >> version >> 2.7 >> If a user at that time still had a client with say BF-CBC >> would >> the >> negotiation still work then or would it fail because >> OpenVPN no >> longer >> recognises the old weak cipher? > This is true according to the OpenVPN 'Deprecated Option' > wiki -- >> > https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Policy:Migratea...

I had seen that overall page before but obviously not read the details well enough of that specific entry. The entry makes it clear that from openvpn-2.7 onwards the 64 bit ciphers will no longer be accepted even as data-fallback ones.

...

> that´s causes, beneath the OpenSSL-3.x decision, to leave the > deprecated ciphers out of the Roadwarrior list (N2N is > another > thing > since it do no understands cipher negotiation) but pushed at > that > time > an idea to bring on some warnings for the users before the > IPFire > decision to leave the broken ciphers out of any list since > the > server > can not see what client configuration is in place. To correct this statement, mostly users do not see/recognize such warnings in the OpenVPN logs, the server does see it!

I see what you are saying. The users tend not to look at their logs and so will miss the message about the 64 bit BF-CBC etc being removed from 2.7 onwards.

So having the 64 bit ciphers in the data-fallback table but not allowing them to be used and instead giving a warning message about the cipher being removed in the future is a way to make the changes more visible that the user needs to do and the potential timing scenario.

I think I will also need to put together a supporting info blog post on the openvpn changes that will come with the IPFire updates being worked on and the future ones with openvpn-2.7

...

> This patch can be found in here --> > https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=dd11f427...

Thanks for the clarification.

Regards, Adolf.

...

>> Regards, >> >> Adolf. > Best, > > Erik > >>>> Then pressed Start OpenVPN Server and nothing happened. >>>> Checked >>>> the >>>> logs and there is the openssl error >>>> >>>> OpenSSL: error:0308010C:digital envelope >>>> routines::unsupported >>>> >>>> which occurs because Openssl-3.x doesn't support the >>>> older >>>> ciphers >>>> like BF unless legacy is selected. In this case I think >>>> it >>>> is >>>> the >>>> OpenVPN server conf file that requires the >>>> >>>> providers legacy default >>>> >>>> to be included, rather than the client conf file. >>>> >>>> Still it does feel like two steps forward and one >>>> backwards >>>> so >>>> overall still making progress. >>>> >>>> >>>> Regards, >>>> >>>> Adolf. >>> Best, >>> >>> Erik >>>> On 09/10/2023 14:05, Adolf Belka wrote: >>>>> Hi All, >>>>> >>>>> >>>>> Over the last week I have been working on the openvpn >>>>> update >>>>> using >>>>> Erik's previous patches as my starting point. >>>>> >>>>> My first attempt to try and be able to understand the >>>>> changes >>>>> from >>>>> each patch to figure out what I needed to do proved >>>>> difficult >>>>> for >>>>> me to work with. >>>>> >>>>> What I then did was take the current ovpnmain.cgi and >>>>> apply >>>>> all >>>>> of >>>>> Erik's patches to it. >>>>> >>>>> Then I have gone through that new version of >>>>> ovpnmain.cgi >>>>> and >>>>> made >>>>> the changes based on previous discussions with >>>>> Michael. >>>>> >>>>> So I have removed the b2sum options that were present >>>>> for >>>>> the >>>>> Data >>>>> and Channel Authentication. >>>>> >>>>> I also moved all the cryptographic options from an >>>>> additional >>>>> advanced cryptographic options button into the >>>>> Advanced >>>>> Server >>>>> options button. >>>>> >>>>> I was successful in doing all the above and then >>>>> tested >>>>> the >>>>> ovpnmain.cgi out with a vm using the existing >>>>> openvpn- >>>>> 2.5.9 >>>>> version >>>>> for openvpn. >>>>> >>>>> My old profile for my laptop which had a ciphers >>>>> entry >>>>> worked >>>>> without any problem. My laptop was working withy >>>>> openvpn- >>>>> 2.6.6 >>>>> >>>>> I then created a new profile using the new >>>>> ovpnmain.cgi >>>>> using >>>>> the >>>>> negotiation option which ended up with a data-ciphers >>>>> line. >>>>> That >>>>> also worked in making a successful openvpn tunnel >>>>> with my >>>>> laptop >>>>> without any issues. >>>>> >>>>> I then downgraded my laptop to openvpn-2.4.8 and had >>>>> to >>>>> install >>>>> openvpn-1.1.1 to make that work. >>>>> >>>>> With that client version on my laptop both the old >>>>> and >>>>> new >>>>> profiles >>>>> connected with a tunnel with no problems. >>>>> >>>>> I then tried downgrading my laptop to openvpn-2.3.14 >>>>> but >>>>> to >>>>> make >>>>> this work I would have had to downgrade the laptop to >>>>> openssl- >>>>> 1.0.0 >>>>> which I was not willing to do as that is very old and >>>>> very >>>>> insecure. >>>>> >>>>> The oldest openvpn version working with openssl-1.1.1 >>>>> is >>>>> 2.4.0 >>>>> which is nearly 7 years old. >>>>> >>>>> That version also worked with both the old and new >>>>> laptop >>>>> profiles. >>>>> >>>>> I then tested out the openvpn server on my IPFire vm >>>>> with >>>>> a >>>>> 2.6.0 >>>>> and 2.6.6 version of openvpn. >>>>> >>>>> Both these openvpn versions worked with both the old >>>>> and >>>>> new >>>>> laptop >>>>> connection profiles with my laptop on version 2.4.0 >>>>> and >>>>> on >>>>> 2.6.6 >>>>> >>>>> All the above was using network manager with its >>>>> openvpn >>>>> plugin >>>>> option on the laptop for making the openvpn tunnel >>>>> connections. >>>>> >>>>> As far as I can tell everything is working fine when >>>>> negotiation is >>>>> specified on the server. Old profiles that just use >>>>> the >>>>> cipher >>>>> option also work fine. Therefore my plan is to only >>>>> use >>>>> the >>>>> negotiation option and not make it selectable for >>>>> older >>>>> clients. >>>>> The data-ciphers-fallback option in the server seems >>>>> to >>>>> be >>>>> doing >>>>> its job. >>>>> >>>>> The negotiation option on the server was able to >>>>> connect >>>>> to a >>>>> 2.4.0 >>>>> client on my laptop. >>>>> >>>>> According to the OpenVPN wiki on cipher negotiation >>>>> the >>>>> data- >>>>> ciphers-fallback option will work with 2.4.x and >>>>> 2.3.x >>>>> clients. >>>>> As >>>>> the 2.3.x clients need to be using openssl-1.0.0 then >>>>> I >>>>> think >>>>> if >>>>> those clients work then fine but nothing further >>>>> back. >>>>> >>>>> Overall, I am very happy with what I have succeeded >>>>> in >>>>> doing >>>>> so >>>>> far. I achieved things much quicker than I had >>>>> expected. >>>>> >>>>> I will now try and see about creating a profile on a >>>>> CU >>>>> 179 >>>>> based >>>>> system that uses one of the old insecure ciphers such >>>>> as >>>>> Blow >>>>> Fish >>>>> and restore that into my evaluation vm and see how >>>>> that >>>>> works >>>>> with >>>>> my laptop when I have it downgraded to openvpn-2.4.0 >>>>> >>>>> I already know that if the laptop is at openvpn-2.6.6 >>>>> then it >>>>> will >>>>> not accept a blowfish cipher (or another weak cipher >>>>> such >>>>> as >>>>> DES) >>>>> as that is something I tested in the past. >>>>> >>>>> If that also works then my plan will be to take the >>>>> updated >>>>> ovpnmain.cgi and split the changes into a new range >>>>> of >>>>> patches >>>>> and >>>>> then submit them for consideration. >>>>> >>>>> That will probably end up later in November as I will >>>>> be >>>>> busy >>>>> with >>>>> personal things at the end of October / beginning of >>>>> November. >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Adolf.

Hi,

On 19/10/2023 10:02, ummeegge wrote:

Hi all,

Am Mittwoch, dem 18.10.2023 um 21:39 +0200 schrieb Adolf Belka:

...

Hi all,

On 18/10/2023 20:48, Michael Tremer wrote:

...

Hello,

...

On 18 Oct 2023, at 10:05, ummeegge ummeegge@ipfire.org wrote:

Hi all,

Am Freitag, dem 13.10.2023 um 14:52 +0200 schrieb Adolf Belka:

...

Hi Erik,

On 12/10/2023 13:30, ummeegge wrote:

...

Your welcome. If you are in state of completing the blog post you can send it again to overread it so we all can speak about it, as an offer from me.

I would really also recommend to make the cipher renegotiation configurable via WUI. Since the release of 2FA it has been hardcoded --> https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=html/cgi-bin/ovpnmain.cgi;... to 48 hours which in a practical way or in fact disables the PFS also for users which do not use 2FA whereby the OpenVPN default, also with potential secure ciphers, are configured to 1 hour to renegotiate a new session key.

The problem with making it configurable from the WUI is that there is only one value that the server can have so users that have client connections with and without OTP would have to make a choice between one or the other.

Client and server can have different '--reneg-sec' values but it makes no sense to configure it in such way since the earlier value triggers the renegotiation of the session key and will never reach the later one cause it starts then again with 0.

Ah okay, I think I overlooked the aspect here that the default comes even for the client.

It is potentially a bad design choice then that the protocol cannot rekey without reauthentication.

We could try to push this from the server side maybe? That would at least indicate some SHOULD value. If the client does not honour it, we cannot do anything about that.

I disagree that this will not work as I have tested it and it worked.

This statement above was according the server have not the capabilities to trigger different reneg-sec values via CCD or push option for different clients. If the server is e.g. configured with 'reneg-sec 0' (disabled) you can configure all clients with different values that´s no problem but i would say more then 90% of all IPFire Roadwarriors out there does not have a reneg-sec configuration in client.ovpn cause it was simply not given by the server before 2FA so they use the time values from the server. To change the client configuration afterwards are only possible from user side so we run in the same problems to communicate this but also stresses admins with several hundreds may thousands of clients.

Looking at the ref manual on the reneg-sec, I get the impression that if the client does not have reneg-sec defined then the default value is applied.

If this is the case then I would expect that the client would renegotiate first as the default reneg-sec value is 3600 secs, even if the server has 86400 secs set. Some clients look like they defined reneg-secs to 0 by default, such as network-manager with the openvpn plugin, so those would take the server value.

I haven't tested the above with a client with no reneg-sec defined and see if the renegotiation takes place at an hour or not. I will try and find some time to do this later.

You are right that users that have large numbers of clients won't want to go and change all their client settings, if they have reneg-sec defined already at 0 or if the client as standard turns off reneg-sec by setting at 0 but if their clients are working okay then there will be no requirement to make them change their client.

My suggestion for the change to reneg-sec was for all new connections made. All existing connections would continue running as they have been.

Adolf.

...

I had a standard system with the server set to 86400 secs.

I then added into the client profile for my laptop reneg-sec 30.

So server with 86400 client with 30

Result the server renegotiated every 30 secs. I had the reneg occur 5 times. This is what is wanted.

Alternative would be another client with reneg-sec set to 86400 to be used for OTP connection.

So server with 86400 client set to 86400 This should result in renegotiation somewhere between 77760 secs (90% 86400 secs) and 86400 secs, randomly selected.

I didn't test this as I didn't have a spare 48 hours to test and also I have not found an openvpn client that I use that works with OTP.

Regards,

Adolf.

...

...

...

I have looked through the OpenVPN info on reneg-sec and found that it can be specified on both the server but also on each client and for a specific client the timer that will time out first is the lower value of the one in both ends.

Yes, and the counter starts then from the beginning.

...

I have tested this out on my laptop with a direct openvpn cli connection and via the network manager openvpn plugin and also on my android phone via the OpenVPN for Android app.

In all three cases I added reneg-sec 30 to the .ovpn profile and then installed it.

I then was able to successfully make a connection and every 30 secs I saw in the logs that the connection was renegotiated in all three cases.

It can also be used with pkts [n] and bytes [n] which OpenVPN is using if 64 bit block ciphers are configured and renegotiates after 64 MB of transfered data. This was the consequences after the SWEET32 birthday attacks --> https://sweet32.info%C2%A0. But if '--reneg-*' has been configured the internal OpenVPN defaults won´t be used.

I am not aware that anyone has ever reported that they need to re- enter the OTP after hitting a certain amount of data.

If so, we need to disable this for OTP-enabled clients. The rationale would be that because we have stronger authentication, we can afford to have fewer rekeys - which I personally disagree with.

...

...

So the current server value can be left as it is and for clients with the OTP option checked they can have the same reneg-sec as currently in the server and for clients without the OTP checked they can have a reneg-sec value of one hour, which will trigger before the server value.

I think this won´t work since whichever (server or client) uses the lower value will be the one who triggers the renegotiation and the counter starts then by 0 again. So this is a kind of a global setting and can not be triggered ealier for some and ater for others in my opinion --> https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/ .

That is a correct statement.

...

...

It could already be that in some cases this is happening anyway as the default value for reneg-sec if not specified is 3600 so it depends what the clients are doing with that default value. I would need to run a test with the three above options where I leave the systems connected via OpenVPN and see what happens after one hour (the default value for reneg-sec) but I am not sure when I will have time for that.

Adolf, i would test also the '--auth-(gen-)token' directive --> https://github.com/OpenVPN/openvpn3/blob/master/doc/webauth.md#auth-token-us... (very old discussion!) may this can be a solution to bypass the whole reneg-sec discussion around 2FA and leave the server to 3600 sec´s or make it even configuerable cause 2FA users uses it, i think, for mostly clients. I can not test this sinec 2FA on IPFire never works for me!

Why not?

...

...

I think it will be good to explicitly specify the reneg-sec on both OTP and non-OTP clients so that the default value doesn't cause unexpected consequences.

Please check also the OpenVPN manpage --

...

https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/

in section "Data Channel Renegotiation" according the above questions and potential testing scenarios.

...

Regards, Adolf.

...

Best,

Erik

Best,

Erik

...

...

Am Donnerstag, dem 12.10.2023 um 11:36 +0200 schrieb Adolf Belka: > Hi Erik, > > On 12/10/2023 08:06, ummeegge wrote: >> Am Donnerstag, dem 12.10.2023 um 07:56 +0200 schrieb >> ummeegge: >>>> OpenVPN plan to remove those weak ciphers completely >>>> in >>>> version >>>> 2.7 >>>> If a user at that time still had a client with say >>>> BF-CBC >>>> would >>>> the >>>> negotiation still work then or would it fail because >>>> OpenVPN no >>>> longer >>>> recognises the old weak cipher? >>> This is true according to the OpenVPN 'Deprecated >>> Option' >>> wiki -- >>>> >>> https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Policy:Migratea... > I had seen that overall page before but obviously not read > the > details > well enough of that specific entry. The entry makes it > clear that > from > openvpn-2.7 onwards the 64 bit ciphers will no longer be > accepted > even > as data-fallback ones. >>> that´s causes, beneath the OpenSSL-3.x decision, to >>> leave the >>> deprecated ciphers out of the Roadwarrior list (N2N is >>> another >>> thing >>> since it do no understands cipher negotiation) but >>> pushed at >>> that >>> time >>> an idea to bring on some warnings for the users before >>> the >>> IPFire >>> decision to leave the broken ciphers out of any list >>> since >>> the >>> server >>> can not see what client configuration is in place. >> To correct this statement, mostly users do not >> see/recognize >> such >> warnings in the  OpenVPN logs, the server does see it! > I see what you are saying. The users tend not to look at > their > logs > and > so will miss the message about the 64 bit BF-CBC etc being > removed > from > 2.7 onwards. > > So having the 64 bit ciphers in the data-fallback table but > not > allowing > them to be used and instead giving a warning message about > the > cipher > being removed in the future is a way to make the changes > more > visible > that the user needs to do and the potential timing > scenario. > > I think I will also need to put together a supporting info > blog > post > on > the openvpn changes that will come with the IPFire updates > being > worked > on and the future ones with openvpn-2.7 >>> This patch can be found in here --> >>> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=dd11f427... > Thanks for the clarification. > > Regards, > Adolf. >>>> Regards, >>>> >>>> Adolf. >>> Best, >>> >>> Erik >>> >>>>>> Then pressed Start OpenVPN Server and nothing >>>>>> happened. >>>>>> Checked >>>>>> the >>>>>> logs and there is the openssl error >>>>>> >>>>>> OpenSSL: error:0308010C:digital envelope >>>>>> routines::unsupported >>>>>> >>>>>> which occurs because Openssl-3.x doesn't support >>>>>> the >>>>>> older >>>>>> ciphers >>>>>> like BF unless legacy is selected. In this case I >>>>>> think >>>>>> it >>>>>> is >>>>>> the >>>>>> OpenVPN server conf file that requires the >>>>>> >>>>>> providers legacy default >>>>>> >>>>>> to be included, rather than the client conf file. >>>>>> >>>>>> Still it does feel like two steps forward and one >>>>>> backwards >>>>>> so >>>>>> overall still making progress. >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Adolf. >>>>> Best, >>>>> >>>>> Erik >>>>>> On 09/10/2023 14:05, Adolf Belka wrote: >>>>>>> Hi All, >>>>>>> >>>>>>> >>>>>>> Over the last week I have been working on the >>>>>>> openvpn >>>>>>> update >>>>>>> using >>>>>>> Erik's previous patches as my starting point. >>>>>>> >>>>>>> My first attempt to try and be able to >>>>>>> understand the >>>>>>> changes >>>>>>> from >>>>>>> each patch to figure out what I needed to do >>>>>>> proved >>>>>>> difficult >>>>>>> for >>>>>>> me to work with. >>>>>>> >>>>>>> What I then did was take the current >>>>>>> ovpnmain.cgi and >>>>>>> apply >>>>>>> all >>>>>>> of >>>>>>> Erik's patches to it. >>>>>>> >>>>>>> Then I have gone through that new version of >>>>>>> ovpnmain.cgi >>>>>>> and >>>>>>> made >>>>>>> the changes based on previous discussions with >>>>>>> Michael. >>>>>>> >>>>>>> So I have removed the b2sum options that were >>>>>>> present >>>>>>> for >>>>>>> the >>>>>>> Data >>>>>>> and Channel Authentication. >>>>>>> >>>>>>> I also moved all the cryptographic options from >>>>>>> an >>>>>>> additional >>>>>>> advanced cryptographic options button into the >>>>>>> Advanced >>>>>>> Server >>>>>>> options button. >>>>>>> >>>>>>> I was successful in doing all the above and >>>>>>> then >>>>>>> tested >>>>>>> the >>>>>>> ovpnmain.cgi out with a vm using the existing >>>>>>> openvpn- >>>>>>> 2.5.9 >>>>>>> version >>>>>>> for openvpn. >>>>>>> >>>>>>> My old profile for my laptop which had a >>>>>>> ciphers >>>>>>> entry >>>>>>> worked >>>>>>> without any problem. My laptop was working >>>>>>> withy >>>>>>> openvpn- >>>>>>> 2.6.6 >>>>>>> >>>>>>> I then created a new profile using the new >>>>>>> ovpnmain.cgi >>>>>>> using >>>>>>> the >>>>>>> negotiation option which ended up with a data- >>>>>>> ciphers >>>>>>> line. >>>>>>> That >>>>>>> also worked in making a successful openvpn >>>>>>> tunnel >>>>>>> with my >>>>>>> laptop >>>>>>> without any issues. >>>>>>> >>>>>>> I then downgraded my laptop to openvpn-2.4.8 >>>>>>> and had >>>>>>> to >>>>>>> install >>>>>>> openvpn-1.1.1 to make that work. >>>>>>> >>>>>>> With that client version on my laptop both the >>>>>>> old >>>>>>> and >>>>>>> new >>>>>>> profiles >>>>>>> connected with a tunnel with no problems. >>>>>>> >>>>>>> I then tried downgrading my laptop to openvpn- >>>>>>> 2.3.14 >>>>>>> but >>>>>>> to >>>>>>> make >>>>>>> this work I would have had to downgrade the >>>>>>> laptop to >>>>>>> openssl- >>>>>>> 1.0.0 >>>>>>> which I was not willing to do as that is very >>>>>>> old and >>>>>>> very >>>>>>> insecure. >>>>>>> >>>>>>> The oldest openvpn version working with >>>>>>> openssl-1.1.1 >>>>>>> is >>>>>>> 2.4.0 >>>>>>> which is nearly 7 years old. >>>>>>> >>>>>>> That version also worked with both the old and >>>>>>> new >>>>>>> laptop >>>>>>> profiles. >>>>>>> >>>>>>> I then tested out the openvpn server on my >>>>>>> IPFire vm >>>>>>> with >>>>>>> a >>>>>>> 2.6.0 >>>>>>> and 2.6.6 version of openvpn. >>>>>>> >>>>>>> Both these openvpn versions worked with both >>>>>>> the old >>>>>>> and >>>>>>> new >>>>>>> laptop >>>>>>> connection profiles with my laptop on version >>>>>>> 2.4.0 >>>>>>> and >>>>>>> on >>>>>>> 2.6.6 >>>>>>> >>>>>>> All the above was using network manager with >>>>>>> its >>>>>>> openvpn >>>>>>> plugin >>>>>>> option on the laptop for making the openvpn >>>>>>> tunnel >>>>>>> connections. >>>>>>> >>>>>>> As far as I can tell everything is working fine >>>>>>> when >>>>>>> negotiation is >>>>>>> specified on the server. Old profiles that just >>>>>>> use >>>>>>> the >>>>>>> cipher >>>>>>> option also work fine. Therefore my plan is to >>>>>>> only >>>>>>> use >>>>>>> the >>>>>>> negotiation option and not make it selectable >>>>>>> for >>>>>>> older >>>>>>> clients. >>>>>>> The data-ciphers-fallback option in the server >>>>>>> seems >>>>>>> to >>>>>>> be >>>>>>> doing >>>>>>> its job. >>>>>>> >>>>>>> The negotiation option on the server was able >>>>>>> to >>>>>>> connect >>>>>>> to a >>>>>>> 2.4.0 >>>>>>> client on my laptop. >>>>>>> >>>>>>> According to the OpenVPN wiki on cipher >>>>>>> negotiation >>>>>>> the >>>>>>> data- >>>>>>> ciphers-fallback option will work with 2.4.x >>>>>>> and >>>>>>> 2.3.x >>>>>>> clients. >>>>>>> As >>>>>>> the 2.3.x clients need to be using openssl- >>>>>>> 1.0.0 then >>>>>>> I >>>>>>> think >>>>>>> if >>>>>>> those clients work then fine but nothing >>>>>>> further >>>>>>> back. >>>>>>> >>>>>>> Overall, I am very happy with what I have >>>>>>> succeeded >>>>>>> in >>>>>>> doing >>>>>>> so >>>>>>> far. I achieved things much quicker than I had >>>>>>> expected. >>>>>>> >>>>>>> I will now try and see about creating a profile >>>>>>> on a >>>>>>> CU >>>>>>> 179 >>>>>>> based >>>>>>> system that uses one of the old insecure >>>>>>> ciphers such >>>>>>> as >>>>>>> Blow >>>>>>> Fish >>>>>>> and restore that into my evaluation vm and see >>>>>>> how >>>>>>> that >>>>>>> works >>>>>>> with >>>>>>> my laptop when I have it downgraded to openvpn- >>>>>>> 2.4.0 >>>>>>> >>>>>>> I already know that if the laptop is at >>>>>>> openvpn-2.6.6 >>>>>>> then it >>>>>>> will >>>>>>> not accept a blowfish cipher (or another weak >>>>>>> cipher >>>>>>> such >>>>>>> as >>>>>>> DES) >>>>>>> as that is something I tested in the past. >>>>>>> >>>>>>> If that also works then my plan will be to take >>>>>>> the >>>>>>> updated >>>>>>> ovpnmain.cgi and split the changes into a new >>>>>>> range >>>>>>> of >>>>>>> patches >>>>>>> and >>>>>>> then submit them for consideration. >>>>>>> >>>>>>> That will probably end up later in November as >>>>>>> I will >>>>>>> be >>>>>>> busy >>>>>>> with >>>>>>> personal things at the end of October / >>>>>>> beginning of >>>>>>> November. >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Adolf.

Hi all,

Am Mittwoch, dem 18.10.2023 um 19:48 +0100 schrieb Michael Tremer:

Hello,

...

On 18 Oct 2023, at 10:05, ummeegge ummeegge@ipfire.org wrote:

Hi all,

Am Freitag, dem 13.10.2023 um 14:52 +0200 schrieb Adolf Belka:

...

Hi Erik,

On 12/10/2023 13:30, ummeegge wrote:

...

Your welcome. If you are in state of completing the blog post you can send it again to overread it so we all can speak about it, as an offer from me.

I would really also recommend to make the cipher renegotiation configurable via WUI. Since the release of 2FA it has been hardcoded --> https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=html/cgi-bin/ovpnmain.cgi;... to 48 hours which in a practical way or in fact disables the PFS also for users which do not use 2FA whereby the OpenVPN default, also with potential secure ciphers, are configured to 1 hour to renegotiate a new session key.

The problem with making it configurable from the WUI is that there is only one value that the server can have so users that have client connections with and without OTP would have to make a choice between one or the other.

Client and server can have different '--reneg-sec' values but it makes no sense to configure it in such way since the earlier value triggers the renegotiation of the session key and will never reach the later one cause it starts then again with 0.

Ah okay, I think I overlooked the aspect here that the default comes even for the client.

It is potentially a bad design choice then that the protocol cannot rekey without reauthentication.

We could try to push this from the server side maybe? That would at least indicate some SHOULD value. If the client does not honour it, we cannot do anything about that.

...

...

I have looked through the OpenVPN info on reneg-sec and found that it can be specified on both the server but also on each client and for a specific client the timer that will time out first is the lower value of the one in both ends.

Yes, and the counter starts then from the beginning.

...

I have tested this out on my laptop with a direct openvpn cli connection and via the network manager openvpn plugin and also on my android phone via the OpenVPN for Android app.

In all three cases I added reneg-sec 30 to the .ovpn profile and then installed it.

I then was able to successfully make a connection and every 30 secs I saw in the logs that the connection was renegotiated in all three cases.

It can also be used with pkts [n] and bytes [n] which OpenVPN is using if 64 bit block ciphers are configured and renegotiates after 64 MB of transfered data. This was the consequences after the SWEET32 birthday attacks --> https://sweet32.info%C2%A0. But if '--reneg-*' has been configured the internal OpenVPN defaults won´t be used.

I am not aware that anyone has ever reported that they need to re- enter the OTP after hitting a certain amount of data.

If so, we need to disable this for OTP-enabled clients. The rationale would be that because we have stronger authentication, we can afford to have fewer rekeys - which I personally disagree with.

...

...

So the current server value can be left as it is and for clients with the OTP option checked they can have the same reneg-sec as currently in the server and for clients without the OTP checked they can have a reneg-sec value of one hour, which will trigger before the server value.

I think this won´t work since whichever (server or client) uses the lower value will be the one who triggers the renegotiation and the counter starts then by 0 again. So this is a kind of a global setting and can not be triggered ealier for some and ater for others in my opinion --> https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/ .

That is a correct statement.

...

...

It could already be that in some cases this is happening anyway as the default value for reneg-sec if not specified is 3600 so it depends what the clients are doing with that default value. I would need to run a test with the three above options where I leave the systems connected via OpenVPN and see what happens after one hour (the default value for reneg-sec) but I am not sure when I will have time for that.

Adolf, i would test also the '--auth-(gen-)token' directive --> https://github.com/OpenVPN/openvpn3/blob/master/doc/webauth.md#auth-token-us... (very old discussion!) may this can be a solution to bypass the whole reneg-sec discussion around 2FA and leave the server to 3600 sec´s or make it even configuerable cause 2FA users uses it, i think, for mostly clients. I can not test this sinec 2FA on IPFire never works for me!

Why not?

We tried to debug this from community side since a lot of users reported problems to configure 2FA for their systems whereby for some others it worked. You can find in here --> https://community.ipfire.org/t/two-openvpn-problems-2fa-support-and-perfect-... a community conversation but a bugzilla entry is also available --> https://bugzilla.ipfire.org/show_bug.cgi?id=13097

...

...

I think it will be good to explicitly specify the reneg-sec on both OTP and non-OTP clients so that the default value doesn't cause unexpected consequences.

Please check also the OpenVPN manpage --

...

https://openvpn.net/community-resources/reference-manual-for-openv pn-2-6/

in section "Data Channel Renegotiation" according the above questions and potential testing scenarios.

...

Regards, Adolf.

...

Best,

Erik

Best,

Erik

...

...

Am Donnerstag, dem 12.10.2023 um 11:36 +0200 schrieb Adolf Belka:

...

Hi Erik,

On 12/10/2023 08:06, ummeegge wrote:

...

Am Donnerstag, dem 12.10.2023 um 07:56 +0200 schrieb ummeegge: > > OpenVPN plan to remove those weak ciphers completely in > > version > > 2.7 > > If a user at that time still had a client with say BF- > > CBC > > would > > the > > negotiation still work then or would it fail because > > OpenVPN no > > longer > > recognises the old weak cipher? > This is true according to the OpenVPN 'Deprecated Option' > wiki -- > > > https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Policy:Migratea...

I had seen that overall page before but obviously not read the details well enough of that specific entry. The entry makes it clear that from openvpn-2.7 onwards the 64 bit ciphers will no longer be accepted even as data-fallback ones.

...

> that´s causes, beneath the OpenSSL-3.x decision, to leave > the > deprecated ciphers out of the Roadwarrior list (N2N is > another > thing > since it do no understands cipher negotiation) but pushed > at > that > time > an idea to bring on some warnings for the users before > the > IPFire > decision to leave the broken ciphers out of any list > since > the > server > can not see what client configuration is in place. To correct this statement, mostly users do not see/recognize such warnings in the  OpenVPN logs, the server does see it!

I see what you are saying. The users tend not to look at their logs and so will miss the message about the 64 bit BF-CBC etc being removed from 2.7 onwards.

So having the 64 bit ciphers in the data-fallback table but not allowing them to be used and instead giving a warning message about the cipher being removed in the future is a way to make the changes more visible that the user needs to do and the potential timing scenario.

I think I will also need to put together a supporting info blog post on the openvpn changes that will come with the IPFire updates being worked on and the future ones with openvpn-2.7

...

> This patch can be found in here --> > https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=dd11f427...

Thanks for the clarification.

Regards, Adolf.

...

> > Regards, > > > > Adolf. > Best, > > Erik > > > > > Then pressed Start OpenVPN Server and nothing > > > > happened. > > > > Checked > > > > the > > > > logs and there is the openssl error > > > > > > > > OpenSSL: error:0308010C:digital envelope > > > > routines::unsupported > > > > > > > > which occurs because Openssl-3.x doesn't support > > > > the > > > > older > > > > ciphers > > > > like BF unless legacy is selected. In this case I > > > > think > > > > it > > > > is > > > > the > > > > OpenVPN server conf file that requires the > > > > > > > > providers legacy default > > > > > > > > to be included, rather than the client conf file. > > > > > > > > Still it does feel like two steps forward and one > > > > backwards > > > > so > > > > overall still making progress. > > > > > > > > > > > > Regards, > > > > > > > > Adolf. > > > Best, > > > > > > Erik > > > > On 09/10/2023 14:05, Adolf Belka wrote: > > > > > Hi All, > > > > > > > > > > > > > > > Over the last week I have been working on the > > > > > openvpn > > > > > update > > > > > using > > > > > Erik's previous patches as my starting point. > > > > > > > > > > My first attempt to try and be able to understand > > > > > the > > > > > changes > > > > > from > > > > > each patch to figure out what I needed to do > > > > > proved > > > > > difficult > > > > > for > > > > > me to work with. > > > > > > > > > > What I then did was take the current ovpnmain.cgi > > > > > and > > > > > apply > > > > > all > > > > > of > > > > > Erik's patches to it. > > > > > > > > > > Then I have gone through that new version of > > > > > ovpnmain.cgi > > > > > and > > > > > made > > > > > the changes based on previous discussions with > > > > > Michael. > > > > > > > > > > So I have removed the b2sum options that were > > > > > present > > > > > for > > > > > the > > > > > Data > > > > > and Channel Authentication. > > > > > > > > > > I also moved all the cryptographic options from > > > > > an > > > > > additional > > > > > advanced cryptographic options button into the > > > > > Advanced > > > > > Server > > > > > options button. > > > > > > > > > > I was successful in doing all the above and then > > > > > tested > > > > > the > > > > > ovpnmain.cgi out with a vm using the existing > > > > > openvpn- > > > > > 2.5.9 > > > > > version > > > > > for openvpn. > > > > > > > > > > My old profile for my laptop which had a ciphers > > > > > entry > > > > > worked > > > > > without any problem. My laptop was working withy > > > > > openvpn- > > > > > 2.6.6 > > > > > > > > > > I then created a new profile using the new > > > > > ovpnmain.cgi > > > > > using > > > > > the > > > > > negotiation option which ended up with a data- > > > > > ciphers > > > > > line. > > > > > That > > > > > also worked in making a successful openvpn tunnel > > > > > with my > > > > > laptop > > > > > without any issues. > > > > > > > > > > I then downgraded my laptop to openvpn-2.4.8 and > > > > > had > > > > > to > > > > > install > > > > > openvpn-1.1.1 to make that work. > > > > > > > > > > With that client version on my laptop both the > > > > > old > > > > > and > > > > > new > > > > > profiles > > > > > connected with a tunnel with no problems. > > > > > > > > > > I then tried downgrading my laptop to openvpn- > > > > > 2.3.14 > > > > > but > > > > > to > > > > > make > > > > > this work I would have had to downgrade the > > > > > laptop to > > > > > openssl- > > > > > 1.0.0 > > > > > which I was not willing to do as that is very old > > > > > and > > > > > very > > > > > insecure. > > > > > > > > > > The oldest openvpn version working with openssl- > > > > > 1.1.1 > > > > > is > > > > > 2.4.0 > > > > > which is nearly 7 years old. > > > > > > > > > > That version also worked with both the old and > > > > > new > > > > > laptop > > > > > profiles. > > > > > > > > > > I then tested out the openvpn server on my IPFire > > > > > vm > > > > > with > > > > > a > > > > > 2.6.0 > > > > > and 2.6.6 version of openvpn. > > > > > > > > > > Both these openvpn versions worked with both the > > > > > old > > > > > and > > > > > new > > > > > laptop > > > > > connection profiles with my laptop on version > > > > > 2.4.0 > > > > > and > > > > > on > > > > > 2.6.6 > > > > > > > > > > All the above was using network manager with its > > > > > openvpn > > > > > plugin > > > > > option on the laptop for making the openvpn > > > > > tunnel > > > > > connections. > > > > > > > > > > As far as I can tell everything is working fine > > > > > when > > > > > negotiation is > > > > > specified on the server. Old profiles that just > > > > > use > > > > > the > > > > > cipher > > > > > option also work fine. Therefore my plan is to > > > > > only > > > > > use > > > > > the > > > > > negotiation option and not make it selectable for > > > > > older > > > > > clients. > > > > > The data-ciphers-fallback option in the server > > > > > seems > > > > > to > > > > > be > > > > > doing > > > > > its job. > > > > > > > > > > The negotiation option on the server was able to > > > > > connect > > > > > to a > > > > > 2.4.0 > > > > > client on my laptop. > > > > > > > > > > According to the OpenVPN wiki on cipher > > > > > negotiation > > > > > the > > > > > data- > > > > > ciphers-fallback option will work with 2.4.x and > > > > > 2.3.x > > > > > clients. > > > > > As > > > > > the 2.3.x clients need to be using openssl-1.0.0 > > > > > then > > > > > I > > > > > think > > > > > if > > > > > those clients work then fine but nothing further > > > > > back. > > > > > > > > > > Overall, I am very happy with what I have > > > > > succeeded > > > > > in > > > > > doing > > > > > so > > > > > far. I achieved things much quicker than I had > > > > > expected. > > > > > > > > > > I will now try and see about creating a profile > > > > > on a > > > > > CU > > > > > 179 > > > > > based > > > > > system that uses one of the old insecure ciphers > > > > > such > > > > > as > > > > > Blow > > > > > Fish > > > > > and restore that into my evaluation vm and see > > > > > how > > > > > that > > > > > works > > > > > with > > > > > my laptop when I have it downgraded to openvpn- > > > > > 2.4.0 > > > > > > > > > > I already know that if the laptop is at openvpn- > > > > > 2.6.6 > > > > > then it > > > > > will > > > > > not accept a blowfish cipher (or another weak > > > > > cipher > > > > > such > > > > > as > > > > > DES) > > > > > as that is something I tested in the past. > > > > > > > > > > If that also works then my plan will be to take > > > > > the > > > > > updated > > > > > ovpnmain.cgi and split the changes into a new > > > > > range > > > > > of > > > > > patches > > > > > and > > > > > then submit them for consideration. > > > > > > > > > > That will probably end up later in November as I > > > > > will > > > > > be > > > > > busy > > > > > with > > > > > personal things at the end of October / beginning > > > > > of > > > > > November. > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Adolf.

Hello Michael,

Am Samstag, dem 14.10.2023 um 13:19 +0100 schrieb Michael Tremer:

Hello,

Although not ideal, I think it is acceptable for a RW client to renegotiate once every 24 hours. It is simply not practical to do this more often than once a day when using OTP.

But we would potentially set the default back to 1hr, and check if we can set reneg-sec to 24h in the CCD for connections that have OTP enabled?!

I think this is not possibl, refering to the reference manual from OpenVPN https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/ CCD works only with --push, --push-reset, --push-remove, --iroute, -- ifconfig-push, --vlan-pvid and --config but misses --reneg-sec .

According to some topics e.g. --> https://forums.openvpn.net/viewtopic.php?t=26132 '--auth-(gen-)token' might be a solutions for this but since 2FA never worked for me i wasn´t able to test this.

-Michael

Best,

Erik

...

On 12 Oct 2023, at 12:30, ummeegge ummeegge@ipfire.org wrote:

Your welcome. If you are in state of completing the blog post you can send it again to overread it so we all can speak about it, as an offer from me.

I would really also recommend to make the cipher renegotiation configurable via WUI. Since the release of 2FA it has been hardcoded --> https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=html/cgi-bin/ovpnmain.cgi;... to 48 hours which in a practical way or in fact disables the PFS also for users which do not use 2FA whereby the OpenVPN default, also with potential secure ciphers, are configured to 1 hour to renegotiate a new session key.

Best,

Erik

Am Donnerstag, dem 12.10.2023 um 11:36 +0200 schrieb Adolf Belka:

...

Hi Erik,

On 12/10/2023 08:06, ummeegge wrote:

...

Am Donnerstag, dem 12.10.2023 um 07:56 +0200 schrieb ummeegge:

...

...

OpenVPN plan to remove those weak ciphers completely in version 2.7 If a user at that time still had a client with say BF-CBC would the negotiation still work then or would it fail because OpenVPN no longer recognises the old weak cipher?

This is true according to the OpenVPN 'Deprecated Option' wiki --

...

https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Policy:Migratea...

I had seen that overall page before but obviously not read the details well enough of that specific entry. The entry makes it clear that from openvpn-2.7 onwards the 64 bit ciphers will no longer be accepted even as data-fallback ones.

...

...

that´s causes, beneath the OpenSSL-3.x decision, to leave the deprecated ciphers out of the Roadwarrior list (N2N is another thing since it do no understands cipher negotiation) but pushed at that time an idea to bring on some warnings for the users before the IPFire decision to leave the broken ciphers out of any list since the server can not see what client configuration is in place.

To correct this statement, mostly users do not see/recognize such warnings in the  OpenVPN logs, the server does see it!

I see what you are saying. The users tend not to look at their logs and so will miss the message about the 64 bit BF-CBC etc being removed from 2.7 onwards.

So having the 64 bit ciphers in the data-fallback table but not allowing them to be used and instead giving a warning message about the cipher being removed in the future is a way to make the changes more visible that the user needs to do and the potential timing scenario.

I think I will also need to put together a supporting info blog post on the openvpn changes that will come with the IPFire updates being worked on and the future ones with openvpn-2.7

...

...

This patch can be found in here --> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=dd11f427...

Thanks for the clarification.

Regards, Adolf.

...

...

...

Regards,

Adolf.

Best,

Erik

...

> > Then pressed Start OpenVPN Server and nothing happened. > > Checked > > the > > logs and there is the openssl error > > > > OpenSSL: error:0308010C:digital envelope > > routines::unsupported > > > > which occurs because Openssl-3.x doesn't support the > > older > > ciphers > > like BF unless legacy is selected. In this case I think > > it > > is > > the > > OpenVPN server conf file that requires the > > > > providers legacy default > > > > to be included, rather than the client conf file. > > > > Still it does feel like two steps forward and one > > backwards > > so > > overall still making progress. > > > > > > Regards, > > > > Adolf. > Best, > > Erik > > On 09/10/2023 14:05, Adolf Belka wrote: > > > Hi All, > > > > > > > > > Over the last week I have been working on the openvpn > > > update > > > using > > > Erik's previous patches as my starting point. > > > > > > My first attempt to try and be able to understand the > > > changes > > > from > > > each patch to figure out what I needed to do proved > > > difficult > > > for > > > me to work with. > > > > > > What I then did was take the current ovpnmain.cgi and > > > apply > > > all > > > of > > > Erik's patches to it. > > > > > > Then I have gone through that new version of > > > ovpnmain.cgi > > > and > > > made > > > the changes based on previous discussions with > > > Michael. > > > > > > So I have removed the b2sum options that were present > > > for > > > the > > > Data > > > and Channel Authentication. > > > > > > I also moved all the cryptographic options from an > > > additional > > > advanced cryptographic options button into the > > > Advanced > > > Server > > > options button. > > > > > > I was successful in doing all the above and then > > > tested > > > the > > > ovpnmain.cgi out with a vm using the existing > > > openvpn- > > > 2.5.9 > > > version > > > for openvpn. > > > > > > My old profile for my laptop which had a ciphers > > > entry > > > worked > > > without any problem. My laptop was working withy > > > openvpn- > > > 2.6.6 > > > > > > I then created a new profile using the new > > > ovpnmain.cgi > > > using > > > the > > > negotiation option which ended up with a data-ciphers > > > line. > > > That > > > also worked in making a successful openvpn tunnel > > > with my > > > laptop > > > without any issues. > > > > > > I then downgraded my laptop to openvpn-2.4.8 and had > > > to > > > install > > > openvpn-1.1.1 to make that work. > > > > > > With that client version on my laptop both the old > > > and > > > new > > > profiles > > > connected with a tunnel with no problems. > > > > > > I then tried downgrading my laptop to openvpn-2.3.14 > > > but > > > to > > > make > > > this work I would have had to downgrade the laptop to > > > openssl- > > > 1.0.0 > > > which I was not willing to do as that is very old and > > > very > > > insecure. > > > > > > The oldest openvpn version working with openssl-1.1.1 > > > is > > > 2.4.0 > > > which is nearly 7 years old. > > > > > > That version also worked with both the old and new > > > laptop > > > profiles. > > > > > > I then tested out the openvpn server on my IPFire vm > > > with > > > a > > > 2.6.0 > > > and 2.6.6 version of openvpn. > > > > > > Both these openvpn versions worked with both the old > > > and > > > new > > > laptop > > > connection profiles with my laptop on version 2.4.0 > > > and > > > on > > > 2.6.6 > > > > > > All the above was using network manager with its > > > openvpn > > > plugin > > > option on the laptop for making the openvpn tunnel > > > connections. > > > > > > As far as I can tell everything is working fine when > > > negotiation is > > > specified on the server. Old profiles that just use > > > the > > > cipher > > > option also work fine. Therefore my plan is to only > > > use > > > the > > > negotiation option and not make it selectable for > > > older > > > clients. > > > The data-ciphers-fallback option in the server seems > > > to > > > be > > > doing > > > its job. > > > > > > The negotiation option on the server was able to > > > connect > > > to a > > > 2.4.0 > > > client on my laptop. > > > > > > According to the OpenVPN wiki on cipher negotiation > > > the > > > data- > > > ciphers-fallback option will work with 2.4.x and > > > 2.3.x > > > clients. > > > As > > > the 2.3.x clients need to be using openssl-1.0.0 then > > > I > > > think > > > if > > > those clients work then fine but nothing further > > > back. > > > > > > Overall, I am very happy with what I have succeeded > > > in > > > doing > > > so > > > far. I achieved things much quicker than I had > > > expected. > > > > > > I will now try and see about creating a profile on a > > > CU > > > 179 > > > based > > > system that uses one of the old insecure ciphers such > > > as > > > Blow > > > Fish > > > and restore that into my evaluation vm and see how > > > that > > > works > > > with > > > my laptop when I have it downgraded to openvpn-2.4.0 > > > > > > I already know that if the laptop is at openvpn-2.6.6 > > > then it > > > will > > > not accept a blowfish cipher (or another weak cipher > > > such > > > as > > > DES) > > > as that is something I tested in the past. > > > > > > If that also works then my plan will be to take the > > > updated > > > ovpnmain.cgi and split the changes into a new range > > > of > > > patches > > > and > > > then submit them for consideration. > > > > > > That will probably end up later in November as I will > > > be > > > busy > > > with > > > personal things at the end of October / beginning of > > > November. > > > > > > > > > Regards, > > > > > > Adolf. > > >

Hi Michael,

On 14/10/2023 14:13, Michael Tremer wrote:

To sum this up, we should add the deprecation warning as suggested by Erik.

But we should at the same time have the UI for NCP available so that people don’t have to touch their configuration more than once.

We also need to include the changes for the LZO and also include the update of openvpn to at least 2.6.0 to allow the Compression removal migration path to make sure we only ask people to update client configs once. See the comments about LZO in one of my earlier replies.

Regards,

Adolf.

-Michael

...

On 12 Oct 2023, at 10:36, Adolf Belka adolf.belka@ipfire.org wrote:

Hi Erik,

On 12/10/2023 08:06, ummeegge wrote:

...

Am Donnerstag, dem 12.10.2023 um 07:56 +0200 schrieb ummeegge:

...

...

OpenVPN plan to remove those weak ciphers completely in version 2.7 If a user at that time still had a client with say BF-CBC would the negotiation still work then or would it fail because OpenVPN no longer recognises the old weak cipher?

This is true according to the OpenVPN 'Deprecated Option' wiki --> https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Policy:Migratea...

I had seen that overall page before but obviously not read the details well enough of that specific entry. The entry makes it clear that from openvpn-2.7 onwards the 64 bit ciphers will no longer be accepted even as data-fallback ones.

...

...

that´s causes, beneath the OpenSSL-3.x decision, to leave the deprecated ciphers out of the Roadwarrior list (N2N is another thing since it do no understands cipher negotiation) but pushed at that time an idea to bring on some warnings for the users before the IPFire decision to leave the broken ciphers out of any list since the server can not see what client configuration is in place.

To correct this statement, mostly users do not see/recognize such warnings in the OpenVPN logs, the server does see it!

I see what you are saying. The users tend not to look at their logs and so will miss the message about the 64 bit BF-CBC etc being removed from 2.7 onwards.

So having the 64 bit ciphers in the data-fallback table but not allowing them to be used and instead giving a warning message about the cipher being removed in the future is a way to make the changes more visible that the user needs to do and the potential timing scenario.

I think I will also need to put together a supporting info blog post on the openvpn changes that will come with the IPFire updates being worked on and the future ones with openvpn-2.7

...

...

This patch can be found in here --> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=dd11f427...

Thanks for the clarification.

Regards, Adolf.

...

...

...

Regards,

Adolf.

Best,

Erik

...

...

> Then pressed Start OpenVPN Server and nothing happened. Checked > the > logs and there is the openssl error > > OpenSSL: error:0308010C:digital envelope routines::unsupported > > which occurs because Openssl-3.x doesn't support the older > ciphers > like BF unless legacy is selected. In this case I think it is > the > OpenVPN server conf file that requires the > > providers legacy default > > to be included, rather than the client conf file. > > Still it does feel like two steps forward and one backwards so > overall still making progress. > > > Regards, > > Adolf. Best,

Erik > On 09/10/2023 14:05, Adolf Belka wrote: >> Hi All, >> >> >> Over the last week I have been working on the openvpn update >> using >> Erik's previous patches as my starting point. >> >> My first attempt to try and be able to understand the changes >> from >> each patch to figure out what I needed to do proved difficult >> for >> me to work with. >> >> What I then did was take the current ovpnmain.cgi and apply >> all >> of >> Erik's patches to it. >> >> Then I have gone through that new version of ovpnmain.cgi and >> made >> the changes based on previous discussions with Michael. >> >> So I have removed the b2sum options that were present for the >> Data >> and Channel Authentication. >> >> I also moved all the cryptographic options from an additional >> advanced cryptographic options button into the Advanced >> Server >> options button. >> >> I was successful in doing all the above and then tested the >> ovpnmain.cgi out with a vm using the existing openvpn-2.5.9 >> version >> for openvpn. >> >> My old profile for my laptop which had a ciphers entry worked >> without any problem. My laptop was working withy openvpn- >> 2.6.6 >> >> I then created a new profile using the new ovpnmain.cgi using >> the >> negotiation option which ended up with a data-ciphers line. >> That >> also worked in making a successful openvpn tunnel with my >> laptop >> without any issues. >> >> I then downgraded my laptop to openvpn-2.4.8 and had to >> install >> openvpn-1.1.1 to make that work. >> >> With that client version on my laptop both the old and new >> profiles >> connected with a tunnel with no problems. >> >> I then tried downgrading my laptop to openvpn-2.3.14 but to >> make >> this work I would have had to downgrade the laptop to >> openssl- >> 1.0.0 >> which I was not willing to do as that is very old and very >> insecure. >> >> The oldest openvpn version working with openssl-1.1.1 is >> 2.4.0 >> which is nearly 7 years old. >> >> That version also worked with both the old and new laptop >> profiles. >> >> I then tested out the openvpn server on my IPFire vm with a >> 2.6.0 >> and 2.6.6 version of openvpn. >> >> Both these openvpn versions worked with both the old and new >> laptop >> connection profiles with my laptop on version 2.4.0 and on >> 2.6.6 >> >> All the above was using network manager with its openvpn >> plugin >> option on the laptop for making the openvpn tunnel >> connections. >> >> As far as I can tell everything is working fine when >> negotiation is >> specified on the server. Old profiles that just use the >> cipher >> option also work fine. Therefore my plan is to only use the >> negotiation option and not make it selectable for older >> clients. >> The data-ciphers-fallback option in the server seems to be >> doing >> its job. >> >> The negotiation option on the server was able to connect to a >> 2.4.0 >> client on my laptop. >> >> According to the OpenVPN wiki on cipher negotiation the data- >> ciphers-fallback option will work with 2.4.x and 2.3.x >> clients. >> As >> the 2.3.x clients need to be using openssl-1.0.0 then I think >> if >> those clients work then fine but nothing further back. >> >> Overall, I am very happy with what I have succeeded in doing >> so >> far. I achieved things much quicker than I had expected. >> >> I will now try and see about creating a profile on a CU 179 >> based >> system that uses one of the old insecure ciphers such as Blow >> Fish >> and restore that into my evaluation vm and see how that works >> with >> my laptop when I have it downgraded to openvpn-2.4.0 >> >> I already know that if the laptop is at openvpn-2.6.6 then it >> will >> not accept a blowfish cipher (or another weak cipher such as >> DES) >> as that is something I tested in the past. >> >> If that also works then my plan will be to take the updated >> ovpnmain.cgi and split the changes into a new range of >> patches >> and >> then submit them for consideration. >> >> That will probably end up later in November as I will be busy >> with >> personal things at the end of October / beginning of >> November. >> >> >> Regards, >> >> Adolf. >>

-- Sent from my laptop

Hello,

On 12 Oct 2023, at 06:56, ummeegge ummeegge@ipfire.org wrote:

Good morning Adolf,

Am Mittwoch, dem 11.10.2023 um 17:53 +0200 schrieb Adolf Belka:

...

Hi Erik,

On 11/10/2023 16:20, ummeegge wrote:

...

Hi Adolf,

Am Montag, dem 09.10.2023 um 19:26 +0200 schrieb Adolf Belka:

...

Hi All,

I thought it was too good to be true.

Before creating a client connection with something like BlowFish I thought I would just test the server settings with selecting BF in the data-ciphers-fallback selection box.

Have disabled all the 64 bit block cipher in my previouse patches since the cipher negotiaton managed the whole thing. I think AEAD ciphers are since OpenSSL-1.0.1 available so if AES-GCM is available in --data- ciphers, the clients will use them even BF-CBC is set in client.ovpn . We have had a conversation about this also with some tests which you can find in here --> https://community.ipfire.org/t/openvpn-2-6-development-version/8603/3

Thanks for the feedback and the link to our conversation at the beginning of this year.

So even if the user has BF-CBC set in the client.ovpn, with the server having server negotiation in this update then the client will end up getting connected with an available cipher from the data-ciphers list. I will do a test of that then on my system

If my understanding is correct, then why do we need to still leave the weak ciphers in the data-fallback list. Those could also be removed, they are blocked anyway.

As mentioned, have removed all 64-Bit block Ciphers and left the 128- Bit CBC ones in the 'Data-Channel fallback' list to prevent warnings from the OpenVPN logs. You can find in the same above linked topic a respective message which points out to this configuration by using the 'data-cipher fallback' directive. So even if Blowfish, the variations of DES and CAST5 are out of the list, AES-CBC is still there and can therefor prevent warnings in the logs via '--data-ciphers-fallback' if AES-CBC is used on client.ovpn.

...

OpenVPN plan to remove those weak ciphers completely in version 2.7 If a user at that time still had a client with say BF-CBC would the negotiation still work then or would it fail because OpenVPN no longer recognises the old weak cipher?

This is true according to the OpenVPN 'Deprecated Option' wiki --> https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Policy:Migratea... that´s causes, beneath the OpenSSL-3.x decision, to leave the deprecated ciphers out of the Roadwarrior list (N2N is another thing since it do no understands cipher negotiation) but pushed at that time an idea to bring on some warnings for the users before the IPFire decision to leave the broken ciphers out of any list since the server can not see what client configuration is in place. This patch can be found in here --> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=dd11f427...

This patch looks good to me.

We just need to tame down the warning message a little bit :)

...

Regards,

Adolf.

Best,

Erik

...

...

...

Then pressed Start OpenVPN Server and nothing happened. Checked the logs and there is the openssl error

OpenSSL: error:0308010C:digital envelope routines::unsupported

which occurs because Openssl-3.x doesn't support the older ciphers like BF unless legacy is selected. In this case I think it is the OpenVPN server conf file that requires the

providers legacy default

to be included, rather than the client conf file.

Still it does feel like two steps forward and one backwards so overall still making progress.

Regards,

Adolf.

Best,

Erik

...

On 09/10/2023 14:05, Adolf Belka wrote:

...

Hi All,

Over the last week I have been working on the openvpn update using Erik's previous patches as my starting point.

My first attempt to try and be able to understand the changes from each patch to figure out what I needed to do proved difficult for me to work with.

What I then did was take the current ovpnmain.cgi and apply all of Erik's patches to it.

Then I have gone through that new version of ovpnmain.cgi and made the changes based on previous discussions with Michael.

So I have removed the b2sum options that were present for the Data and Channel Authentication.

I also moved all the cryptographic options from an additional advanced cryptographic options button into the Advanced Server options button.

I was successful in doing all the above and then tested the ovpnmain.cgi out with a vm using the existing openvpn-2.5.9 version for openvpn.

My old profile for my laptop which had a ciphers entry worked without any problem. My laptop was working withy openvpn-2.6.6

I then created a new profile using the new ovpnmain.cgi using the negotiation option which ended up with a data-ciphers line. That also worked in making a successful openvpn tunnel with my laptop without any issues.

I then downgraded my laptop to openvpn-2.4.8 and had to install openvpn-1.1.1 to make that work.

With that client version on my laptop both the old and new profiles connected with a tunnel with no problems.

I then tried downgrading my laptop to openvpn-2.3.14 but to make this work I would have had to downgrade the laptop to openssl- 1.0.0 which I was not willing to do as that is very old and very insecure.

The oldest openvpn version working with openssl-1.1.1 is 2.4.0 which is nearly 7 years old.

That version also worked with both the old and new laptop profiles.

I then tested out the openvpn server on my IPFire vm with a 2.6.0 and 2.6.6 version of openvpn.

Both these openvpn versions worked with both the old and new laptop connection profiles with my laptop on version 2.4.0 and on 2.6.6

All the above was using network manager with its openvpn plugin option on the laptop for making the openvpn tunnel connections.

As far as I can tell everything is working fine when negotiation is specified on the server. Old profiles that just use the cipher option also work fine. Therefore my plan is to only use the negotiation option and not make it selectable for older clients. The data-ciphers-fallback option in the server seems to be doing its job.

The negotiation option on the server was able to connect to a 2.4.0 client on my laptop.

According to the OpenVPN wiki on cipher negotiation the data- ciphers-fallback option will work with 2.4.x and 2.3.x clients. As the 2.3.x clients need to be using openssl-1.0.0 then I think if those clients work then fine but nothing further back.

Overall, I am very happy with what I have succeeded in doing so far. I achieved things much quicker than I had expected.

I will now try and see about creating a profile on a CU 179 based system that uses one of the old insecure ciphers such as Blow Fish and restore that into my evaluation vm and see how that works with my laptop when I have it downgraded to openvpn-2.4.0

I already know that if the laptop is at openvpn-2.6.6 then it will not accept a blowfish cipher (or another weak cipher such as DES) as that is something I tested in the past.

If that also works then my plan will be to take the updated ovpnmain.cgi and split the changes into a new range of patches and then submit them for consideration.

That will probably end up later in November as I will be busy with personal things at the end of October / beginning of November.

Regards,

Adolf.

On 14 Oct 2023, at 15:17, Adolf Belka adolf.belka@ipfire.org wrote:

Hi Michael,

On 14/10/2023 14:11, Michael Tremer wrote:

...

Hello,

...

On 12 Oct 2023, at 06:56, ummeegge ummeegge@ipfire.org wrote:

Good morning Adolf,

Am Mittwoch, dem 11.10.2023 um 17:53 +0200 schrieb Adolf Belka:

...

Hi Erik,

On 11/10/2023 16:20, ummeegge wrote:

...

Hi Adolf,

Am Montag, dem 09.10.2023 um 19:26 +0200 schrieb Adolf Belka:

...

Hi All,

I thought it was too good to be true.

Before creating a client connection with something like BlowFish I thought I would just test the server settings with selecting BF in the data-ciphers-fallback selection box.

Have disabled all the 64 bit block cipher in my previouse patches since the cipher negotiaton managed the whole thing. I think AEAD ciphers are since OpenSSL-1.0.1 available so if AES-GCM is available in --data- ciphers, the clients will use them even BF-CBC is set in client.ovpn . We have had a conversation about this also with some tests which you can find in here --> https://community.ipfire.org/t/openvpn-2-6-development-version/8603/3

Thanks for the feedback and the link to our conversation at the beginning of this year.

So even if the user has BF-CBC set in the client.ovpn, with the server having server negotiation in this update then the client will end up getting connected with an available cipher from the data-ciphers list. I will do a test of that then on my system

If my understanding is correct, then why do we need to still leave the weak ciphers in the data-fallback list. Those could also be removed, they are blocked anyway.

As mentioned, have removed all 64-Bit block Ciphers and left the 128- Bit CBC ones in the 'Data-Channel fallback' list to prevent warnings from the OpenVPN logs. You can find in the same above linked topic a respective message which points out to this configuration by using the 'data-cipher fallback' directive. So even if Blowfish, the variations of DES and CAST5 are out of the list, AES-CBC is still there and can therefor prevent warnings in the logs via '--data-ciphers-fallback' if AES-CBC is used on client.ovpn.

...

OpenVPN plan to remove those weak ciphers completely in version 2.7 If a user at that time still had a client with say BF-CBC would the negotiation still work then or would it fail because OpenVPN no longer recognises the old weak cipher?

This is true according to the OpenVPN 'Deprecated Option' wiki --> https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Policy:Migratea... that´s causes, beneath the OpenSSL-3.x decision, to leave the deprecated ciphers out of the Roadwarrior list (N2N is another thing since it do no understands cipher negotiation) but pushed at that time an idea to bring on some warnings for the users before the IPFire decision to leave the broken ciphers out of any list since the server can not see what client configuration is in place. This patch can be found in here --> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=dd11f427...

This patch looks good to me.

We just need to tame down the warning message a little bit :)

This message is in my changes and it also needs to make more clear that even though the OpenVPN server can't be started with that cipher selected for the fallback, the client with one of those ciphers can still be connected via negotiation.

Or we add the legacy provider :)

I still need to think how to word that in a concise way that doesn't take half the screen up.

It might not be the shortest, but we need to account for some space anyways because the German version will never ever be short :)

-Michael

Regards,

Adolf.

...

...

...

Regards,

Adolf.

Best,

Erik

...

...

...

Then pressed Start OpenVPN Server and nothing happened. Checked the logs and there is the openssl error

OpenSSL: error:0308010C:digital envelope routines::unsupported

which occurs because Openssl-3.x doesn't support the older ciphers like BF unless legacy is selected. In this case I think it is the OpenVPN server conf file that requires the

providers legacy default

to be included, rather than the client conf file.

Still it does feel like two steps forward and one backwards so overall still making progress.

Regards,

Adolf.

Best,

Erik

...

On 09/10/2023 14:05, Adolf Belka wrote: > Hi All, > > > Over the last week I have been working on the openvpn update > using > Erik's previous patches as my starting point. > > My first attempt to try and be able to understand the changes > from > each patch to figure out what I needed to do proved difficult > for > me to work with. > > What I then did was take the current ovpnmain.cgi and apply all > of > Erik's patches to it. > > Then I have gone through that new version of ovpnmain.cgi and > made > the changes based on previous discussions with Michael. > > So I have removed the b2sum options that were present for the > Data > and Channel Authentication. > > I also moved all the cryptographic options from an additional > advanced cryptographic options button into the Advanced Server > options button. > > I was successful in doing all the above and then tested the > ovpnmain.cgi out with a vm using the existing openvpn-2.5.9 > version > for openvpn. > > My old profile for my laptop which had a ciphers entry worked > without any problem. My laptop was working withy openvpn-2.6.6 > > I then created a new profile using the new ovpnmain.cgi using > the > negotiation option which ended up with a data-ciphers line. > That > also worked in making a successful openvpn tunnel with my > laptop > without any issues. > > I then downgraded my laptop to openvpn-2.4.8 and had to install > openvpn-1.1.1 to make that work. > > With that client version on my laptop both the old and new > profiles > connected with a tunnel with no problems. > > I then tried downgrading my laptop to openvpn-2.3.14 but to > make > this work I would have had to downgrade the laptop to openssl- > 1.0.0 > which I was not willing to do as that is very old and very > insecure. > > The oldest openvpn version working with openssl-1.1.1 is 2.4.0 > which is nearly 7 years old. > > That version also worked with both the old and new laptop > profiles. > > I then tested out the openvpn server on my IPFire vm with a > 2.6.0 > and 2.6.6 version of openvpn. > > Both these openvpn versions worked with both the old and new > laptop > connection profiles with my laptop on version 2.4.0 and on > 2.6.6 > > All the above was using network manager with its openvpn plugin > option on the laptop for making the openvpn tunnel connections. > > As far as I can tell everything is working fine when > negotiation is > specified on the server. Old profiles that just use the cipher > option also work fine. Therefore my plan is to only use the > negotiation option and not make it selectable for older > clients. > The data-ciphers-fallback option in the server seems to be > doing > its job. > > The negotiation option on the server was able to connect to a > 2.4.0 > client on my laptop. > > According to the OpenVPN wiki on cipher negotiation the data- > ciphers-fallback option will work with 2.4.x and 2.3.x clients. > As > the 2.3.x clients need to be using openssl-1.0.0 then I think > if > those clients work then fine but nothing further back. > > Overall, I am very happy with what I have succeeded in doing so > far. I achieved things much quicker than I had expected. > > I will now try and see about creating a profile on a CU 179 > based > system that uses one of the old insecure ciphers such as Blow > Fish > and restore that into my evaluation vm and see how that works > with > my laptop when I have it downgraded to openvpn-2.4.0 > > I already know that if the laptop is at openvpn-2.6.6 then it > will > not accept a blowfish cipher (or another weak cipher such as > DES) > as that is something I tested in the past. > > If that also works then my plan will be to take the updated > ovpnmain.cgi and split the changes into a new range of patches > and > then submit them for consideration. > > That will probably end up later in November as I will be busy > with > personal things at the end of October / beginning of November. > > > Regards, > > Adolf.

Am Samstag, dem 14.10.2023 um 13:10 +0100 schrieb Michael Tremer:

Hi Erik,

Long time no see :)

May it will become in the next time a little more often ;-) (a project has been canceled)...

...

On 11 Oct 2023, at 15:20, ummeegge ummeegge@ipfire.org wrote:

Hi Adolf,

Am Montag, dem 09.10.2023 um 19:26 +0200 schrieb Adolf Belka:

...

Hi All,

I thought it was too good to be true.

Before creating a client connection with something like BlowFish I thought I would just test the server settings with selecting BF in the data-ciphers-fallback selection box.

Have disabled all the 64 bit block cipher in my previouse patches since the cipher negotiaton managed the whole thing. I think AEAD ciphers are since OpenSSL-1.0.1 available so if AES-GCM is available in --data- ciphers, the clients will use them even BF-CBC is set in client.ovpn . We have had a conversation about this also with some tests which you can find in here --> https://community.ipfire.org/t/openvpn-2-6-development-version/8603/3

...

Then pressed Start OpenVPN Server and nothing happened. Checked the logs and there is the openssl error

OpenSSL: error:0308010C:digital envelope routines::unsupported

which occurs because Openssl-3.x doesn't support the older ciphers like BF unless legacy is selected. In this case I think it is the OpenVPN server conf file that requires the

providers legacy default

to be included, rather than the client conf file.

Still it does feel like two steps forward and one backwards so overall still making progress.

Regards,

Adolf.

Best,

Erik

...

On 09/10/2023 14:05, Adolf Belka wrote:

...

Hi All,

Over the last week I have been working on the openvpn update using Erik's previous patches as my starting point.

My first attempt to try and be able to understand the changes from each patch to figure out what I needed to do proved difficult for me to work with.

What I then did was take the current ovpnmain.cgi and apply all of Erik's patches to it.

Then I have gone through that new version of ovpnmain.cgi and made the changes based on previous discussions with Michael.

So I have removed the b2sum options that were present for the Data and Channel Authentication.

I also moved all the cryptographic options from an additional advanced cryptographic options button into the Advanced Server options button.

I was successful in doing all the above and then tested the ovpnmain.cgi out with a vm using the existing openvpn-2.5.9 version for openvpn.

My old profile for my laptop which had a ciphers entry worked without any problem. My laptop was working withy openvpn-2.6.6

I then created a new profile using the new ovpnmain.cgi using the negotiation option which ended up with a data-ciphers line. That also worked in making a successful openvpn tunnel with my laptop without any issues.

I then downgraded my laptop to openvpn-2.4.8 and had to install openvpn-1.1.1 to make that work.

With that client version on my laptop both the old and new profiles connected with a tunnel with no problems.

I then tried downgrading my laptop to openvpn-2.3.14 but to make this work I would have had to downgrade the laptop to openssl- 1.0.0 which I was not willing to do as that is very old and very insecure.

The oldest openvpn version working with openssl-1.1.1 is 2.4.0 which is nearly 7 years old.

That version also worked with both the old and new laptop profiles.

I then tested out the openvpn server on my IPFire vm with a 2.6.0 and 2.6.6 version of openvpn.

Both these openvpn versions worked with both the old and new laptop connection profiles with my laptop on version 2.4.0 and on 2.6.6

All the above was using network manager with its openvpn plugin option on the laptop for making the openvpn tunnel connections.

As far as I can tell everything is working fine when negotiation is specified on the server. Old profiles that just use the cipher option also work fine. Therefore my plan is to only use the negotiation option and not make it selectable for older clients. The data-ciphers-fallback option in the server seems to be doing its job.

The negotiation option on the server was able to connect to a 2.4.0 client on my laptop.

According to the OpenVPN wiki on cipher negotiation the data- ciphers-fallback option will work with 2.4.x and 2.3.x clients. As the 2.3.x clients need to be using openssl-1.0.0 then I think if those clients work then fine but nothing further back.

Overall, I am very happy with what I have succeeded in doing so far. I achieved things much quicker than I had expected.

I will now try and see about creating a profile on a CU 179 based system that uses one of the old insecure ciphers such as Blow Fish and restore that into my evaluation vm and see how that works with my laptop when I have it downgraded to openvpn-2.4.0

I already know that if the laptop is at openvpn-2.6.6 then it will not accept a blowfish cipher (or another weak cipher such as DES) as that is something I tested in the past.

If that also works then my plan will be to take the updated ovpnmain.cgi and split the changes into a new range of patches and then submit them for consideration.

That will probably end up later in November as I will be busy with personal things at the end of October / beginning of November.

Regards,

Adolf.

Hi Michael,

On 14/10/2023 14:08, Michael Tremer wrote:

Hello Adolf,

We should already have the legacy option enabled by default on the server and client side in some cases.

Potentially, we need to add a list of ciphers that require it and then add the same flag again.

https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=7dec360355f0eb5bb9bc...

Maybe just like the iscertlegacy() subroutine, we add a iscipherlegacy() one and then check both?!

I did add in some code to add providers legacy default into the server conf file if one of the insecure ciphers was selected, ie enabling the server to be started with an insecure cipher.

From feedback from Erik and further thinking myself, I reverted from this. If the cipher is able to be enabled then a new connection could be created with that old insecure cipher specified in the data-fallback option. I don't think this is a good approach and also, from my testing, not required.

My preference would have been to remove completely the insecure ciphers from the data-fallback option as the negotiation works with openvpn-2.4.0 and a client with a BF-CBC cipher specified.

The only reason for having the ciphers in the data fallback section is as Erik mentioned that this tells the user that they have a client(s) that need to have their connection profiles progressively updated to a modern cipher. The same message would be seen in the logs but as Erik mentioned, too many of the users won't look in the logs.

So in the end my cgi changes have not re-enabled any of the insecure ciphers in the data fallback table but they are still visible there.

The only problem situation I could see is a user who does not know that their client(s) have insecure ciphers and selects or accepts the default data-fallback option of AES-CBC but the client has BF-CBC or one of the other insecure ciphers specified in the client config.

Maybe that user has inherited a set of client connections that were created by someone else and as long as they work they don't look any further.

In that case that user will get no warning that their clients have an insecure cipher except for the log messages. Those might have a problem then when openvpn is updated to 2.7 because they might not have updated their clients because they didn't know about the insecure ciphers being used.

Regards, Adolf.

-Michael

...

On 9 Oct 2023, at 18:26, Adolf Belka adolf.belka@ipfire.org wrote:

Hi All,

I thought it was too good to be true.

Before creating a client connection with something like BlowFish I thought I would just test the server settings with selecting BF in the data-ciphers-fallback selection box.

Then pressed Start OpenVPN Server and nothing happened. Checked the logs and there is the openssl error

OpenSSL: error:0308010C:digital envelope routines::unsupported

which occurs because Openssl-3.x doesn't support the older ciphers like BF unless legacy is selected. In this case I think it is the OpenVPN server conf file that requires the

providers legacy default

to be included, rather than the client conf file.

Still it does feel like two steps forward and one backwards so overall still making progress.

Regards,

Adolf.

On 09/10/2023 14:05, Adolf Belka wrote:

...

Hi All,

Over the last week I have been working on the openvpn update using Erik's previous patches as my starting point.

My first attempt to try and be able to understand the changes from each patch to figure out what I needed to do proved difficult for me to work with.

What I then did was take the current ovpnmain.cgi and apply all of Erik's patches to it.

Then I have gone through that new version of ovpnmain.cgi and made the changes based on previous discussions with Michael.

So I have removed the b2sum options that were present for the Data and Channel Authentication.

I also moved all the cryptographic options from an additional advanced cryptographic options button into the Advanced Server options button.

I was successful in doing all the above and then tested the ovpnmain.cgi out with a vm using the existing openvpn-2.5.9 version for openvpn.

My old profile for my laptop which had a ciphers entry worked without any problem. My laptop was working withy openvpn-2.6.6

I then created a new profile using the new ovpnmain.cgi using the negotiation option which ended up with a data-ciphers line. That also worked in making a successful openvpn tunnel with my laptop without any issues.

I then downgraded my laptop to openvpn-2.4.8 and had to install openvpn-1.1.1 to make that work.

With that client version on my laptop both the old and new profiles connected with a tunnel with no problems.

I then tried downgrading my laptop to openvpn-2.3.14 but to make this work I would have had to downgrade the laptop to openssl-1.0.0 which I was not willing to do as that is very old and very insecure.

The oldest openvpn version working with openssl-1.1.1 is 2.4.0 which is nearly 7 years old.

That version also worked with both the old and new laptop profiles.

I then tested out the openvpn server on my IPFire vm with a 2.6.0 and 2.6.6 version of openvpn.

Both these openvpn versions worked with both the old and new laptop connection profiles with my laptop on version 2.4.0 and on 2.6.6

All the above was using network manager with its openvpn plugin option on the laptop for making the openvpn tunnel connections.

As far as I can tell everything is working fine when negotiation is specified on the server. Old profiles that just use the cipher option also work fine. Therefore my plan is to only use the negotiation option and not make it selectable for older clients. The data-ciphers-fallback option in the server seems to be doing its job.

The negotiation option on the server was able to connect to a 2.4.0 client on my laptop.

According to the OpenVPN wiki on cipher negotiation the data-ciphers-fallback option will work with 2.4.x and 2.3.x clients. As the 2.3.x clients need to be using openssl-1.0.0 then I think if those clients work then fine but nothing further back.

Overall, I am very happy with what I have succeeded in doing so far. I achieved things much quicker than I had expected.

I will now try and see about creating a profile on a CU 179 based system that uses one of the old insecure ciphers such as Blow Fish and restore that into my evaluation vm and see how that works with my laptop when I have it downgraded to openvpn-2.4.0

I already know that if the laptop is at openvpn-2.6.6 then it will not accept a blowfish cipher (or another weak cipher such as DES) as that is something I tested in the past.

If that also works then my plan will be to take the updated ovpnmain.cgi and split the changes into a new range of patches and then submit them for consideration.

That will probably end up later in November as I will be busy with personal things at the end of October / beginning of November.

Regards,

Adolf.

Hi Michael,

On 15/10/2023 12:44, Michael Tremer wrote:

Hello Adolf,

...

On 14 Oct 2023, at 15:12, Adolf Belka adolf.belka@ipfire.org wrote:

Hi Michael,

On 14/10/2023 14:08, Michael Tremer wrote:

...

Hello Adolf, We should already have the legacy option enabled by default on the server and client side in some cases. Potentially, we need to add a list of ciphers that require it and then add the same flag again. https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=7dec360355f0eb5bb9bc... Maybe just like the iscertlegacy() subroutine, we add a iscipherlegacy() one and then check both?!

I did add in some code to add providers legacy default into the server conf file if one of the insecure ciphers was selected, ie enabling the server to be started with an insecure cipher.

From feedback from Erik and further thinking myself, I reverted from this. If the cipher is able to be enabled then a new connection could be created with that old insecure cipher specified in the data-fallback option. I don't think this is a good approach and also, from my testing, not required.

Correct me if I didn’t understand this correctly, but I thought the there might be some corner cases where we would run into this:

Don't worry. It has taken me a while reading the openvpn reference manual on some of these options and some feedback from Erik to get to a point where I think I am starting to understand what is happening.

Let’s assume that someone has been using BF-CBC (a legacy cipher) and we now upgrade to the new way. Then we would have BF-CBC as fallback cipher and a couple of other ones for NCP. Wouldn’t that require the legacy setting for OpenSSL allowing us to use BF?

The client configuration should no longer have the BF (and therefore legacy) setting because we are creating it for modern clients. Older clients that have imported an old configuration might still be using the “cipher” setting and we want to support those for a little bit longer.

The corner case is if the user has clients with openvpn-2.3 or older. With openvpn-2.4 onwards cipher negotiation is available.

When a connection is made from an old cipher, the first approach from the server will be to do a negotiation. That can occur even if BF-CBC as an example is explicitly in the client connection. openvpn-2.4 onwards can still negotiate a more modern cipher and the ones that can be used in openvpn-2.4 are in the data-ciphers section of the new cgi. Basically the strongest common cipher will be taken and in all my tests that ended up being AES-GCM.

If the user has client with openvpn-2.3 then negotiation will fail and that is when the server will then use the data-cipher-fallback. To be using openvpn-2.3 as a client then the user would also have to have openssl-1.0.x installed because I tried to test openvpn-2.3.14 I got the message that it was looking for a specific library version libssl.so.1.0.0 which I believe comes with openssl-1.0.1x

So if we also want to still support users using openvpn-2.3 and using openssl-1.0.1x on their clients then we would need to make the 64 bit ciphers selectable in the data-ciphers-fallback table by adding providers legacy default into the server config file - but only for those 64 bit insecure ciphers. Then we would need to hope that there are not people who would then create new connections using the 64 bit ciphers but who knows what people can do if they have clients still running with openssl-1.0.1x which had the last version released in 2016 and is no longer supported.

If the user has clients with openvpn-2.2 then the openvpn page has written "All bets are off - Upgrade now!"

...

My preference would have been to remove completely the insecure ciphers from the data-fallback option as the negotiation works with openvpn-2.4.0 and a client with a BF-CBC cipher specified.

It does, but in my example from above we need it to support all those sins from the past and give people some time and technical options to move away from them...

In an earlier email you said that you were happy to say that we only support back to clients with openvpn-2.4 but if we now say that we also support back to clients with openvpn-2.3 then yes we will need to allow the selection of the 64 bit ciphers in the server for data-cipher-fallback and have providers legacy default added to the server config file if one of the 64 bit ciphers has been selected for the data-cipher-fallback and then keep our fingers crossed that no one creates new client connections with those old ciphers.

The big crunch will come when opoenvpn-2.7 comes because there will be no fallback option from then on so if users have not updated their client configs with a newer cipher and updated their openvpn client versions then we will reach a decision point.

We either move to openvpn-2.7 and those users who have not updated their clients, in the time between now and when we decide to go to 2.7, will not be able to update IPFire without breaking their connections

or we stay for ever at version 2.6.x

...

The only reason for having the ciphers in the data fallback section is as Erik mentioned that this tells the user that they have a client(s) that need to have their connection profiles progressively updated to a modern cipher. The same message would be seen in the logs but as Erik mentioned, too many of the users won't look in the logs.

Yes, but we don’t quite know what that number is. I agree that it is *very* small, because clients have been using NCP for a long time, even with IPFire. But it is quite likely not zero, as there might be clients that are too old to support NCP, yet.

So what do we do to make the path smoother? Introduce the new options, deprecate the old ones, let people know about the deprecation, and then finally phase it out. In our case, people might be able to do this themselves by simply removing the fallback cipher, so they know for certain that they are out of the woods with all of this.

...

So in the end my cgi changes have not re-enabled any of the insecure ciphers in the data fallback table but they are still visible there.

I wouldn’t insist, but I feel that it might be easier to just make them all available for a couple of months and then remove the whole thing entirely. But I am happy to be shown another way :)

To protect that very small (but maybe not zero), number of users with clients on openvpn-2.3 that does not support NCP then we would need to make them available. We will just then have to think about how we decide that things are better after the couple of months to make the change. I am not sure we will know if those few users without NCP actually exist or not without stopping the use of the 64 bit data-cipher-fallback.

...

The only problem situation I could see is a user who does not know that their client(s) have insecure ciphers and selects or accepts the default data-fallback option of AES-CBC but the client has BF-CBC or one of the other insecure ciphers specified in the client config.

Maybe that user has inherited a set of client connections that were created by someone else and as long as they work they don't look any further.

In that case that user will get no warning that their clients have an insecure cipher except for the log messages. Those might have a problem then when openvpn is updated to 2.7 because they might not have updated their clients because they didn't know about the insecure ciphers being used.

My working assumption is, that most clients are at least on >= 2.4, and therefore don’t use the cipher setting any more - even though it is there. That means that we are dealing with a very small fraction of clients. Let me know if you disagree with this assumption.

That is also my assumption. The cipher setting will have been used up to current status as we have the ncp-disable option in our server config currently with openvpn-2.5.9 With this cgi change to using NCP then the cipher option will no longer be used, even though it is in the client config because the negotiation will supersede it.

Regards, Adolf.

-Michael

...

Regards, Adolf.

...

-Michael

...

On 9 Oct 2023, at 18:26, Adolf Belka adolf.belka@ipfire.org wrote:

Hi All,

I thought it was too good to be true.

Before creating a client connection with something like BlowFish I thought I would just test the server settings with selecting BF in the data-ciphers-fallback selection box.

Then pressed Start OpenVPN Server and nothing happened. Checked the logs and there is the openssl error

OpenSSL: error:0308010C:digital envelope routines::unsupported

which occurs because Openssl-3.x doesn't support the older ciphers like BF unless legacy is selected. In this case I think it is the OpenVPN server conf file that requires the

providers legacy default

to be included, rather than the client conf file.

Still it does feel like two steps forward and one backwards so overall still making progress.

Regards,

Adolf.

On 09/10/2023 14:05, Adolf Belka wrote:

...

Hi All,

Over the last week I have been working on the openvpn update using Erik's previous patches as my starting point.

My first attempt to try and be able to understand the changes from each patch to figure out what I needed to do proved difficult for me to work with.

What I then did was take the current ovpnmain.cgi and apply all of Erik's patches to it.

Then I have gone through that new version of ovpnmain.cgi and made the changes based on previous discussions with Michael.

So I have removed the b2sum options that were present for the Data and Channel Authentication.

I also moved all the cryptographic options from an additional advanced cryptographic options button into the Advanced Server options button.

I was successful in doing all the above and then tested the ovpnmain.cgi out with a vm using the existing openvpn-2.5.9 version for openvpn.

My old profile for my laptop which had a ciphers entry worked without any problem. My laptop was working withy openvpn-2.6.6

I then created a new profile using the new ovpnmain.cgi using the negotiation option which ended up with a data-ciphers line. That also worked in making a successful openvpn tunnel with my laptop without any issues.

I then downgraded my laptop to openvpn-2.4.8 and had to install openvpn-1.1.1 to make that work.

With that client version on my laptop both the old and new profiles connected with a tunnel with no problems.

I then tried downgrading my laptop to openvpn-2.3.14 but to make this work I would have had to downgrade the laptop to openssl-1.0.0 which I was not willing to do as that is very old and very insecure.

The oldest openvpn version working with openssl-1.1.1 is 2.4.0 which is nearly 7 years old.

That version also worked with both the old and new laptop profiles.

I then tested out the openvpn server on my IPFire vm with a 2.6.0 and 2.6.6 version of openvpn.

Both these openvpn versions worked with both the old and new laptop connection profiles with my laptop on version 2.4.0 and on 2.6.6

All the above was using network manager with its openvpn plugin option on the laptop for making the openvpn tunnel connections.

As far as I can tell everything is working fine when negotiation is specified on the server. Old profiles that just use the cipher option also work fine. Therefore my plan is to only use the negotiation option and not make it selectable for older clients. The data-ciphers-fallback option in the server seems to be doing its job.

The negotiation option on the server was able to connect to a 2.4.0 client on my laptop.

According to the OpenVPN wiki on cipher negotiation the data-ciphers-fallback option will work with 2.4.x and 2.3.x clients. As the 2.3.x clients need to be using openssl-1.0.0 then I think if those clients work then fine but nothing further back.

Overall, I am very happy with what I have succeeded in doing so far. I achieved things much quicker than I had expected.

I will now try and see about creating a profile on a CU 179 based system that uses one of the old insecure ciphers such as Blow Fish and restore that into my evaluation vm and see how that works with my laptop when I have it downgraded to openvpn-2.4.0

I already know that if the laptop is at openvpn-2.6.6 then it will not accept a blowfish cipher (or another weak cipher such as DES) as that is something I tested in the past.

If that also works then my plan will be to take the updated ovpnmain.cgi and split the changes into a new range of patches and then submit them for consideration.

That will probably end up later in November as I will be busy with personal things at the end of October / beginning of November.

Regards,

Adolf.

Hi Michael,

On 16/10/2023 12:02, Michael Tremer wrote:

Hello,

...

On 15 Oct 2023, at 13:43, Adolf Belka adolf.belka@ipfire.org wrote:

Hi Michael,

On 15/10/2023 12:44, Michael Tremer wrote:

...

Hello Adolf,

...

On 14 Oct 2023, at 15:12, Adolf Belka adolf.belka@ipfire.org wrote:

Hi Michael,

On 14/10/2023 14:08, Michael Tremer wrote:

...

Hello Adolf, We should already have the legacy option enabled by default on the server and client side in some cases. Potentially, we need to add a list of ciphers that require it and then add the same flag again. https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=7dec360355f0eb5bb9bc... Maybe just like the iscertlegacy() subroutine, we add a iscipherlegacy() one and then check both?!

I did add in some code to add providers legacy default into the server conf file if one of the insecure ciphers was selected, ie enabling the server to be started with an insecure cipher.

From feedback from Erik and further thinking myself, I reverted from this. If the cipher is able to be enabled then a new connection could be created with that old insecure cipher specified in the data-fallback option. I don't think this is a good approach and also, from my testing, not required.

Correct me if I didn’t understand this correctly, but I thought the there might be some corner cases where we would run into this:

Don't worry. It has taken me a while reading the openvpn reference manual on some of these options and some feedback from Erik to get to a point where I think I am starting to understand what is happening.

...

Let’s assume that someone has been using BF-CBC (a legacy cipher) and we now upgrade to the new way. Then we would have BF-CBC as fallback cipher and a couple of other ones for NCP. Wouldn’t that require the legacy setting for OpenSSL allowing us to use BF? The client configuration should no longer have the BF (and therefore legacy) setting because we are creating it for modern clients. Older clients that have imported an old configuration might still be using the “cipher” setting and we want to support those for a little bit longer.

The corner case is if the user has clients with openvpn-2.3 or older. With openvpn-2.4 onwards cipher negotiation is available.

When a connection is made from an old cipher, the first approach from the server will be to do a negotiation. That can occur even if BF-CBC as an example is explicitly in the client connection. openvpn-2.4 onwards can still negotiate a more modern cipher and the ones that can be used in openvpn-2.4 are in the data-ciphers section of the new cgi. Basically the strongest common cipher will be taken and in all my tests that ended up being AES-GCM.

If the user has client with openvpn-2.3 then negotiation will fail and that is when the server will then use the data-cipher-fallback. To be using openvpn-2.3 as a client then the user would also have to have openssl-1.0.x installed because I tried to test openvpn-2.3.14 I got the message that it was looking for a specific library version libssl.so.1.0.0 which I believe comes with openssl-1.0.1x

So if we also want to still support users using openvpn-2.3 and using openssl-1.0.1x on their clients then we would need to make the 64 bit ciphers selectable in the data-ciphers-fallback table by adding providers legacy default into the server config file - but only for those 64 bit insecure ciphers. Then we would need to hope that there are not people who would then create new connections using the 64 bit ciphers but who knows what people can do if they have clients still running with openssl-1.0.1x which had the last version released in 2016 and is no longer supported.

Yes, this is what I have assumed as well. There might be one extra case where people with OpenVPN >= 2.4 have manually disabled the cipher negotiation. We don’t ship that in our client configuration, but it might have been manually enabled by the user. So therefore I think that we should support all currently supported ciphers as a fallback cipher and then deprecate the whole thing to get people upgraded to NCP as soon as possible. But when people install the Core Update, existing setups have to remain working without anything, because otherwise we break people’s setups. And that is sad.

...

If the user has clients with openvpn-2.2 then the openvpn page has written "All bets are off - Upgrade now!"

Yes, even 2.3 is something that we shouldn’t really support any more as it is so old. But there will be a few poor souls who still have to run some Windows XP somewhere because their company is using this really old software for this really big and expensive machine and the vendor doesn’t give a shit about software support and you know the rest of those stories...

...

...

...

My preference would have been to remove completely the insecure ciphers from the data-fallback option as the negotiation works with openvpn-2.4.0 and a client with a BF-CBC cipher specified.

It does, but in my example from above we need it to support all those sins from the past and give people some time and technical options to move away from them...

In an earlier email you said that you were happy to say that we only support back to clients with openvpn-2.4 but if we now say that we also support back to clients with openvpn-2.3 then yes we will need to allow the selection of the 64 bit ciphers in the server for data-cipher-fallback and have providers legacy default added to the server config file if one of the 64 bit ciphers has been selected for the data-cipher-fallback and then keep our fingers crossed that no one creates new client connections with those old ciphers.

I would like to support as many client versions that we can. Because why not? But if things become complicated and we have to invest a lot of work into something that only a very small fraction of our users are using, then it is not worth our time. That being said, I think that it wouldn’t hurt us to have a drop down with all ciphers that we put into the configuration file as a fallback cipher. That is all we need as far as I understand to support those clients (2.3 and 2.4 without NCP).

This allows us to spend more time on the next step. Step one would be to roll out NCP and make it configurable. We don’t have that yet. For all clients to remain working we need the fallback cipher option. And to not make that all too complicated we should just support all ciphers that we can - including lecacy ones. If people rely on this, the clock has started for them to upgrade anyways…

Step two would then be to remove the whole fallback thing again so that everyone is on NCP. There might also be more things like LZO and others that are more or less independent...

The LZO command change is independent in terms of the commands involved but it can't be independent from the NCP change because after the compression migration has been put in place in ovpnmain.cgi then the users will need to update their clients before compression is completely removed from openvpn.

We don't want users having to update all their clients for the weak ciphers and then at a later time having to do it again to remove compression.

It seems to make sense to me to combine the NCP weak ciphers migration and compression migration into the same change so we ask users to update clients that need to be with both changes in one go.

...

The big crunch will come when opoenvpn-2.7 comes because there will be no fallback option from then on so if users have not updated their client configs with a newer cipher and updated their openvpn client versions then we will reach a decision point.

Yes, so let’s remove the fallback option with the upgrade to 2.7 at the latest.

I suppose the bigger fish to fry here is the networking/routing changes.

...

We either move to openvpn-2.7 and those users who have not updated their clients, in the time between now and when we decide to go to 2.7, will not be able to update IPFire without breaking their connections

But before that happens they will have several months. The faster we are now with getting step one done, the longer this timeframe is going to be.

...

or we stay for ever at version 2.6.x

That isn’t an option long term. We do not have to go to 2.7 on its release day, but we cannot ship 2.6 after it has become EOL.

...

...

...

The only reason for having the ciphers in the data fallback section is as Erik mentioned that this tells the user that they have a client(s) that need to have their connection profiles progressively updated to a modern cipher. The same message would be seen in the logs but as Erik mentioned, too many of the users won't look in the logs.

Yes, but we don’t quite know what that number is. I agree that it is *very* small, because clients have been using NCP for a long time, even with IPFire. But it is quite likely not zero, as there might be clients that are too old to support NCP, yet. So what do we do to make the path smoother? Introduce the new options, deprecate the old ones, let people know about the deprecation, and then finally phase it out. In our case, people might be able to do this themselves by simply removing the fallback cipher, so they know for certain that they are out of the woods with all of this.

...

So in the end my cgi changes have not re-enabled any of the insecure ciphers in the data fallback table but they are still visible there.

I wouldn’t insist, but I feel that it might be easier to just make them all available for a couple of months and then remove the whole thing entirely. But I am happy to be shown another way :)

To protect that very small (but maybe not zero), number of users with clients on openvpn-2.3 that does not support NCP then we would need to make them available. We will just then have to think about how we decide that things are better after the couple of months to make the change. I am not sure we will know if those few users without NCP actually exist or not without stopping the use of the 64 bit data-cipher-fallback.

They will have to figure this out themselves I would say :) We cannot do the entire job for them.

It would be kind of cool if we could capture the client version when they connect to tell the admin which client versions are being used, but that is probably too complicated and not worth it with such a low expected number of total clients. And in practical terms, it is possible for an admin out there to fix a few clients after an update, but it simply doesn’t work if they would have to fix hundreds on the same Monday morning.

...

...

...

The only problem situation I could see is a user who does not know that their client(s) have insecure ciphers and selects or accepts the default data-fallback option of AES-CBC but the client has BF-CBC or one of the other insecure ciphers specified in the client config.

Maybe that user has inherited a set of client connections that were created by someone else and as long as they work they don't look any further.

In that case that user will get no warning that their clients have an insecure cipher except for the log messages. Those might have a problem then when openvpn is updated to 2.7 because they might not have updated their clients because they didn't know about the insecure ciphers being used.

My working assumption is, that most clients are at least on >= 2.4, and therefore don’t use the cipher setting any more - even though it is there. That means that we are dealing with a very small fraction of clients. Let me know if you disagree with this assumption.

That is also my assumption. The cipher setting will have been used up to current status as we have the ncp-disable option in our server config currently with openvpn-2.5.9

What? Shit, I was looking for that and couldn't find it. My memory told me as well that we had this somewhere. Well this changes things slightly, but not a lot.

...

With this cgi change to using NCP then the cipher option will no longer be used, even though it is in the client config because the negotiation will supersede it.

Maybe then I misunderstood you slightly, because with NCP, I would not want to make any legacy ciphers available. This should be a list of ciphers that is current as of today. The fallback cipher list should include the legacy ones. Just in case I wasn’t able to bring this difference across :)

-Michael

...

Regards, Adolf.

...

-Michael

...

Regards, Adolf.

...

-Michael

...

On 9 Oct 2023, at 18:26, Adolf Belka adolf.belka@ipfire.org wrote:

Hi All,

I thought it was too good to be true.

Before creating a client connection with something like BlowFish I thought I would just test the server settings with selecting BF in the data-ciphers-fallback selection box.

Then pressed Start OpenVPN Server and nothing happened. Checked the logs and there is the openssl error

OpenSSL: error:0308010C:digital envelope routines::unsupported

which occurs because Openssl-3.x doesn't support the older ciphers like BF unless legacy is selected. In this case I think it is the OpenVPN server conf file that requires the

providers legacy default

to be included, rather than the client conf file.

Still it does feel like two steps forward and one backwards so overall still making progress.

Regards,

Adolf.

On 09/10/2023 14:05, Adolf Belka wrote: > Hi All, > > > Over the last week I have been working on the openvpn update using Erik's previous patches as my starting point. > > My first attempt to try and be able to understand the changes from each patch to figure out what I needed to do proved difficult for me to work with. > > What I then did was take the current ovpnmain.cgi and apply all of Erik's patches to it. > > Then I have gone through that new version of ovpnmain.cgi and made the changes based on previous discussions with Michael. > > So I have removed the b2sum options that were present for the Data and Channel Authentication. > > I also moved all the cryptographic options from an additional advanced cryptographic options button into the Advanced Server options button. > > I was successful in doing all the above and then tested the ovpnmain.cgi out with a vm using the existing openvpn-2.5.9 version for openvpn. > > My old profile for my laptop which had a ciphers entry worked without any problem. My laptop was working withy openvpn-2.6.6 > > I then created a new profile using the new ovpnmain.cgi using the negotiation option which ended up with a data-ciphers line. That also worked in making a successful openvpn tunnel with my laptop without any issues. > > I then downgraded my laptop to openvpn-2.4.8 and had to install openvpn-1.1.1 to make that work. > > With that client version on my laptop both the old and new profiles connected with a tunnel with no problems. > > I then tried downgrading my laptop to openvpn-2.3.14 but to make this work I would have had to downgrade the laptop to openssl-1.0.0 which I was not willing to do as that is very old and very insecure. > > The oldest openvpn version working with openssl-1.1.1 is 2.4.0 which is nearly 7 years old. > > That version also worked with both the old and new laptop profiles. > > I then tested out the openvpn server on my IPFire vm with a 2.6.0 and 2.6.6 version of openvpn. > > Both these openvpn versions worked with both the old and new laptop connection profiles with my laptop on version 2.4.0 and on 2.6.6 > > All the above was using network manager with its openvpn plugin option on the laptop for making the openvpn tunnel connections. > > As far as I can tell everything is working fine when negotiation is specified on the server. Old profiles that just use the cipher option also work fine. Therefore my plan is to only use the negotiation option and not make it selectable for older clients. The data-ciphers-fallback option in the server seems to be doing its job. > > The negotiation option on the server was able to connect to a 2.4.0 client on my laptop. > > According to the OpenVPN wiki on cipher negotiation the data-ciphers-fallback option will work with 2.4.x and 2.3.x clients. As the 2.3.x clients need to be using openssl-1.0.0 then I think if those clients work then fine but nothing further back. > > Overall, I am very happy with what I have succeeded in doing so far. I achieved things much quicker than I had expected. > > I will now try and see about creating a profile on a CU 179 based system that uses one of the old insecure ciphers such as Blow Fish and restore that into my evaluation vm and see how that works with my laptop when I have it downgraded to openvpn-2.4.0 > > I already know that if the laptop is at openvpn-2.6.6 then it will not accept a blowfish cipher (or another weak cipher such as DES) as that is something I tested in the past. > > If that also works then my plan will be to take the updated ovpnmain.cgi and split the changes into a new range of patches and then submit them for consideration. > > That will probably end up later in November as I will be busy with personal things at the end of October / beginning of November. > > > Regards, > > Adolf.

Hi Michael,

On 14/10/2023 14:05, Michael Tremer wrote:

Hello everyone,

Apologies for my late response on this. The last week had a couple of urgent things that were tying me in, but I was happy to see that we are finally making some progress on OpenVPN…

...

On 9 Oct 2023, at 13:05, Adolf Belka adolf.belka@ipfire.org wrote:

Hi All,

Over the last week I have been working on the openvpn update using Erik's previous patches as my starting point.

Could you please push those changes to a Git repository for review? Or did that happen already and I just was too blind to find them...

No, I have been working on them on my vm on my desktop system as there has been a lot of coming and going as I worked on understanding various things. What I have now is different from what I started with.

I will try and push the changes to my git repository but currently it is just a single set of changes. I have not yet started to break the changes into sections to have a commit patch against them yet.

...

My first attempt to try and be able to understand the changes from each patch to figure out what I needed to do proved difficult for me to work with.

What I then did was take the current ovpnmain.cgi and apply all of Erik's patches to it.

Then I have gone through that new version of ovpnmain.cgi and made the changes based on previous discussions with Michael.

So I have removed the b2sum options that were present for the Data and Channel Authentication.

I also moved all the cryptographic options from an additional advanced cryptographic options button into the Advanced Server options button.

I was successful in doing all the above and then tested the ovpnmain.cgi out with a vm using the existing openvpn-2.5.9 version for openvpn.

My old profile for my laptop which had a ciphers entry worked without any problem. My laptop was working withy openvpn-2.6.6

I then created a new profile using the new ovpnmain.cgi using the negotiation option which ended up with a data-ciphers line. That also worked in making a successful openvpn tunnel with my laptop without any issues.

I then downgraded my laptop to openvpn-2.4.8 and had to install openvpn-1.1.1 to make that work.

With that client version on my laptop both the old and new profiles connected with a tunnel with no problems.

I then tried downgrading my laptop to openvpn-2.3.14 but to make this work I would have had to downgrade the laptop to openssl-1.0.0 which I was not willing to do as that is very old and very insecure.

The oldest openvpn version working with openssl-1.1.1 is 2.4.0 which is nearly 7 years old.

I think that it is an acceptable baseline to only support OpenVPN 2.4 and up. That is already a lot more than we actually need to do, and we would support clients that are probably vulnerable to many things… If we need to drop support for OpenVPN 2.4 in this process, that might also be acceptable.

What is *not* so acceptable is that the client configuration file has to be changed in order to keep working with newer clients, because that would require that admins update every single configuration file if the client software is being updated. And that can be a nightmare with hundreds of connections.

From Erik's input and my understanding and my experiments there will be no need for any client configuration to be done as an immediate consequence of the changes I am working on.

If the users are using openvpn-2.4 up then the negotiation from the openvpn server will work even if the client has BF-CBC specified as a cipher. I have proven this with openvpn-2.4.0 on my laptop with a connection profile using BF-CBC and the connection was made with AES-GCM.

The users will however need to take the opportunity of the migration approach with this openvpn work to update the clients from BF-CBC on a one by one basis. This needs to be done for when the change to openvpn-2.7 occurs because that version branch will no longer recognise those old 64 bit ciphers at all.

I can understand the concern if all client connections had to be updated in a big bang situation but with the changes being worked on in this openvpn cgi code the users will be able to update each client as they have time. This set of changes provides the migration opportunity for a one by one client update and still maintaining the non-updated client connections.

Being on the topic of compatibility, I do believe that it is acceptable that connections that are generated today are only working with clients OpenVPN >= 2.6 if we have to do it.

I don't think there is any restriction like that, that will occur. However any new client connection that is created will be made with the data-ciphers option and older insecure ciphers will not be able to be selected for new connections. If a new connection is being created then there will be a new .p12 certificate as well so the package set will need to be transferred to the client anyway so that restriction should not create a problem.

...

That version also worked with both the old and new laptop profiles.

I then tested out the openvpn server on my IPFire vm with a 2.6.0 and 2.6.6 version of openvpn.

Both these openvpn versions worked with both the old and new laptop connection profiles with my laptop on version 2.4.0 and on 2.6.6

All the above was using network manager with its openvpn plugin option on the laptop for making the openvpn tunnel connections.

As far as I can tell everything is working fine when negotiation is specified on the server. Old profiles that just use the cipher option also work fine. Therefore my plan is to only use the negotiation option and not make it selectable for older clients. The data-ciphers-fallback option in the server seems to be doing its job.

The negotiation option on the server was able to connect to a 2.4.0 client on my laptop.

According to the OpenVPN wiki on cipher negotiation the data-ciphers-fallback option will work with 2.4.x and 2.3.x clients. As the 2.3.x clients need to be using openssl-1.0.0 then I think if those clients work then fine but nothing further back.

Overall, I am very happy with what I have succeeded in doing so far. I achieved things much quicker than I had expected.

I will now try and see about creating a profile on a CU 179 based system that uses one of the old insecure ciphers such as Blow Fish and restore that into my evaluation vm and see how that works with my laptop when I have it downgraded to openvpn-2.4.0

I already know that if the laptop is at openvpn-2.6.6 then it will not accept a blowfish cipher (or another weak cipher such as DES) as that is something I tested in the past.

If that also works then my plan will be to take the updated ovpnmain.cgi and split the changes into a new range of patches and then submit them for consideration.

Okay, just to sum this up for me, what will happen is this (in no particular order):

• The cipher option in the configuration file will be removed and changed to data-cipher-fallback. That way, we will continue to support older clients and new ones will use NCP.> * There will be a new UI element where people can select ciphers to use in “data-ciphers” very similarly to how to select a cipher for IPsec
• There will be a deprecation warning for people who use an older (64 bit) “CIPHER” and they will be encouraged to upgrade all their clients to OpenVPN >= 2.4 (which should already have happened anyways) and they should use NCP only (i.e. no data-cipher-fallback option in the server configuration file any more). This will also be the new default.

No. The server will have both a data-cipher and a data-fallback-cipher option line, selected from the WUI.

However the server will try for a negotiation first using the ciphers listed in the data-ciphers list (can be more than one). If the server and client find a cipher that they both have in their list then they will agree on that. Only if nothing can be agreed will the server go to the fallback option. However it seems that openvpn-2.4.x versions onwards include the AEAD ciphers and therefore all my testing even with a client of 2.4.0 resulted in a successful negotiation of AES-GCM (256 bit) even when the config in the client had cipher BF-CBC specified.

How do we do all this for N2N connections? Is is safe to just remove the cipher option entirely because we assume that all clients perform NCP anyways?

I haven't started looking at that yet. I was trying to get to a working process with RW tested out with old client versions and insecure ciphers. I an just about at that point now so I will start to look at the N2N situation and consequences for existing connections in early November.

• In the near future (2.7), the fallback option will have to be removed for all, which will render clients that are OpenVPN <= 2.4 unusable. This is probably acceptable at this point in time.

That is true, but it will also render clients unusable that have not taken the opportunity from this openvpn cgi update that is being discussed, to update the clients from cipher 64_bit_insecure to data-cipher secure as mentioned earlier.

• We will have to deprecate LZO as well. Do your patches include anything about that?

No not yet. The cgi update being worked on also works with openvpn-2.5.9, the current version. We could do the cgi release with the current version of openvpn and after any debugging that is flagged up we could then do an update to openvpn-2.6.x where x could be anywhere between 0 and 6. I have tested the cgi changes with openvpn version 2.5.9, 2.6.0 and 2.6.6 and it worked the same way for all three versions.

For the LZO situation, the migration path to allow users with compression to be update on a one by one basis is only available from version 2.6.0

To prevent asking users to make multiple updates of client connections (which I understand would also be undesirable) then we would need to issue the cgi update together with an update to at least 2.6.0 and with the LZO changes.

I have not yet had the chance to work on those. They will probably come after the N2N checks and evaluation with the changes have been completed. I will also need to do testing of any changes of the LZO with my setup and that is not something I have evaluated to date.

Regards, Adolf.

...

That will probably end up later in November as I will be busy with personal things at the end of October / beginning of November.

Regards,

Adolf.

-Michael

Hello,

On 15 Oct 2023, at 14:43, Adolf Belka adolf.belka@ipfire.org wrote:

Hi Michael,

On 14/10/2023 15:57, Adolf Belka wrote:

...

Hi Michael,

On 14/10/2023 14:05, Michael Tremer wrote:

...

Hello everyone,

Apologies for my late response on this. The last week had a couple of urgent things that were tying me in, but I was happy to see that we are finally making some progress on OpenVPN…

...

On 9 Oct 2023, at 13:05, Adolf Belka adolf.belka@ipfire.org wrote:

Hi All,

Over the last week I have been working on the openvpn update using Erik's previous patches as my starting point.

Could you please push those changes to a Git repository for review? Or did that happen already and I just was too blind to find them...

No, I have been working on them on my vm on my desktop system as there has been a lot of coming and going as I worked on understanding various things. What I have now is different from what I started with.

I will try and push the changes to my git repository but currently it is just a single set of changes. I have not yet started to break the changes into sections to have a commit patch against them yet.

I have pushed the changes as a single diff into my IPFire repo.

https://git.ipfire.org/?p=people/bonnietwin/ipfire-2.x.git;a=commit;h=4fbf17...

Thanks for pushing this. It is good to have something visual and a backup, just in case :)

At the moment it is still a single set of all changes as that way I could understand the whole picture and the bits that I was changing. I still need to add the LZO stuff plus other changes based on our email discussion in the last few days.

When that is all done and we are generally agreed on the approach then I will split all the changes into separate chunks to go in separate patches of a patch set.

With the diff in my git repo you can apply that and see the changes and simplifications that I have made so far before our email discussions.

Yes, this looks alright so far.

I am not sure who wrote this, but you can use more lines. They are free :)

print SERVERCONF "proto tcp4-server\n"; - print SERVERCONF "# Packet size\n"; + print SERVERCONF "# Packet size\n";&writeserverconf();#hier ok if ($cgiparams{'MTU'} eq '') {$tunmtu = '1400'} else {$tunmtu = $cgi

This is hard to read :)

—

And… do we need to put the data ciphers into the client configuration? Isn’t it enough if the server tells the client what to use? That allows changing the cipher later on without touching the client configuration again - this is the massive advantage of NCP, isn’t it?

-Michael

Regards,

Adolf.

...

...

...

My first attempt to try and be able to understand the changes from each patch to figure out what I needed to do proved difficult for me to work with.

What I then did was take the current ovpnmain.cgi and apply all of Erik's patches to it.

Then I have gone through that new version of ovpnmain.cgi and made the changes based on previous discussions with Michael.

So I have removed the b2sum options that were present for the Data and Channel Authentication.

I also moved all the cryptographic options from an additional advanced cryptographic options button into the Advanced Server options button.

I was successful in doing all the above and then tested the ovpnmain.cgi out with a vm using the existing openvpn-2.5.9 version for openvpn.

My old profile for my laptop which had a ciphers entry worked without any problem. My laptop was working withy openvpn-2.6.6

I then created a new profile using the new ovpnmain.cgi using the negotiation option which ended up with a data-ciphers line. That also worked in making a successful openvpn tunnel with my laptop without any issues.

I then downgraded my laptop to openvpn-2.4.8 and had to install openvpn-1.1.1 to make that work.

With that client version on my laptop both the old and new profiles connected with a tunnel with no problems.

I then tried downgrading my laptop to openvpn-2.3.14 but to make this work I would have had to downgrade the laptop to openssl-1.0.0 which I was not willing to do as that is very old and very insecure.

The oldest openvpn version working with openssl-1.1.1 is 2.4.0 which is nearly 7 years old.

I think that it is an acceptable baseline to only support OpenVPN 2.4 and up. That is already a lot more than we actually need to do, and we would support clients that are probably vulnerable to many things… If we need to drop support for OpenVPN 2.4 in this process, that might also be acceptable.

What is *not* so acceptable is that the client configuration file has to be changed in order to keep working with newer clients, because that would require that admins update every single configuration file if the client software is being updated. And that can be a nightmare with hundreds of connections.

From Erik's input and my understanding and my experiments there will be no need for any client configuration to be done as an immediate consequence of the changes I am working on.

If the users are using openvpn-2.4 up then the negotiation from the openvpn server will work even if the client has BF-CBC specified as a cipher. I have proven this with openvpn-2.4.0 on my laptop with a connection profile using BF-CBC and the connection was made with AES-GCM.

The users will however need to take the opportunity of the migration approach with this openvpn work to update the clients from BF-CBC on a one by one basis. This needs to be done for when the change to openvpn-2.7 occurs because that version branch will no longer recognise those old 64 bit ciphers at all.

I can understand the concern if all client connections had to be updated in a big bang situation but with the changes being worked on in this openvpn cgi code the users will be able to update each client as they have time. This set of changes provides the migration opportunity for a one by one client update and still maintaining the non-updated client connections.

...

Being on the topic of compatibility, I do believe that it is acceptable that connections that are generated today are only working with clients OpenVPN >= 2.6 if we have to do it.

I don't think there is any restriction like that, that will occur. However any new client connection that is created will be made with the data-ciphers option and older insecure ciphers will not be able to be selected for new connections. If a new connection is being created then there will be a new .p12 certificate as well so the package set will need to be transferred to the client anyway so that restriction should not create a problem.

...

...

That version also worked with both the old and new laptop profiles.

I then tested out the openvpn server on my IPFire vm with a 2.6.0 and 2.6.6 version of openvpn.

Both these openvpn versions worked with both the old and new laptop connection profiles with my laptop on version 2.4.0 and on 2.6.6

All the above was using network manager with its openvpn plugin option on the laptop for making the openvpn tunnel connections.

As far as I can tell everything is working fine when negotiation is specified on the server. Old profiles that just use the cipher option also work fine. Therefore my plan is to only use the negotiation option and not make it selectable for older clients. The data-ciphers-fallback option in the server seems to be doing its job.

The negotiation option on the server was able to connect to a 2.4.0 client on my laptop.

According to the OpenVPN wiki on cipher negotiation the data-ciphers-fallback option will work with 2.4.x and 2.3.x clients. As the 2.3.x clients need to be using openssl-1.0.0 then I think if those clients work then fine but nothing further back.

Overall, I am very happy with what I have succeeded in doing so far. I achieved things much quicker than I had expected.

I will now try and see about creating a profile on a CU 179 based system that uses one of the old insecure ciphers such as Blow Fish and restore that into my evaluation vm and see how that works with my laptop when I have it downgraded to openvpn-2.4.0

I already know that if the laptop is at openvpn-2.6.6 then it will not accept a blowfish cipher (or another weak cipher such as DES) as that is something I tested in the past.

If that also works then my plan will be to take the updated ovpnmain.cgi and split the changes into a new range of patches and then submit them for consideration.

Okay, just to sum this up for me, what will happen is this (in no particular order):

• The cipher option in the configuration file will be removed and changed to data-cipher-fallback. That way, we will continue to support older clients and new ones will use NCP.> * There will be a new UI element where people can select ciphers to use in “data-ciphers” very similarly to how to select a cipher for IPsec
• There will be a deprecation warning for people who use an older (64 bit) “CIPHER” and they will be encouraged to upgrade all their clients to OpenVPN >= 2.4 (which should already have happened anyways) and they should use NCP only (i.e. no data-cipher-fallback option in the server configuration file any more). This will also be the new default.

No. The server will have both a data-cipher and a data-fallback-cipher option line, selected from the WUI.

However the server will try for a negotiation first using the ciphers listed in the data-ciphers list (can be more than one). If the server and client find a cipher that they both have in their list then they will agree on that. Only if nothing can be agreed will the server go to the fallback option. However it seems that openvpn-2.4.x versions onwards include the AEAD ciphers and therefore all my testing even with a client of 2.4.0 resulted in a successful negotiation of AES-GCM (256 bit) even when the config in the client had cipher BF-CBC specified.

...

How do we do all this for N2N connections? Is is safe to just remove the cipher option entirely because we assume that all clients perform NCP anyways?

I haven't started looking at that yet. I was trying to get to a working process with RW tested out with old client versions and insecure ciphers. I an just about at that point now so I will start to look at the N2N situation and consequences for existing connections in early November.

...

• In the near future (2.7), the fallback option will have to be removed for all, which will render clients that are OpenVPN <= 2.4 unusable. This is probably acceptable at this point in time.

That is true, but it will also render clients unusable that have not taken the opportunity from this openvpn cgi update that is being discussed, to update the clients from cipher 64_bit_insecure to data-cipher secure as mentioned earlier.

...

• We will have to deprecate LZO as well. Do your patches include anything about that?

No not yet. The cgi update being worked on also works with openvpn-2.5.9, the current version. We could do the cgi release with the current version of openvpn and after any debugging that is flagged up we could then do an update to openvpn-2.6.x where x could be anywhere between 0 and 6. I have tested the cgi changes with openvpn version 2.5.9, 2.6.0 and 2.6.6 and it worked the same way for all three versions.

For the LZO situation, the migration path to allow users with compression to be update on a one by one basis is only available from version 2.6.0

To prevent asking users to make multiple updates of client connections (which I understand would also be undesirable) then we would need to issue the cgi update together with an update to at least 2.6.0 and with the LZO changes.

I have not yet had the chance to work on those. They will probably come after the N2N checks and evaluation with the changes have been completed. I will also need to do testing of any changes of the LZO with my setup and that is not something I have evaluated to date.

Regards, Adolf.

...

...

That will probably end up later in November as I will be busy with personal things at the end of October / beginning of November.

Regards,

Adolf.

-Michael

Hi Erik,

On 18/10/2023 11:29, ummeegge wrote:

Hi Adolf,

Am Sonntag, dem 15.10.2023 um 15:43 +0200 schrieb Adolf Belka:

...

Hi Michael,

On 14/10/2023 15:57, Adolf Belka wrote:

...

Hi Michael,

On 14/10/2023 14:05, Michael Tremer wrote:

...

Hello everyone,

Apologies for my late response on this. The last week had a couple of urgent things that were tying me in, but I was happy to see that we are finally making some progress on OpenVPN…

...

On 9 Oct 2023, at 13:05, Adolf Belka adolf.belka@ipfire.org wrote:

Hi All,

Over the last week I have been working on the openvpn update using Erik's previous patches as my starting point.

Could you please push those changes to a Git repository for review? Or did that happen already and I just was too blind to find them...

No, I have been working on them on my vm on my desktop system as there has been a lot of coming and going as I worked on understanding various things. What I have now is different from what I started with.

I will try and push the changes to my git repository but currently it is just a single set of changes. I have not yet started to break the changes into sections to have a commit patch against them yet.

I have pushed the changes as a single diff into my IPFire repo.

https://git.ipfire.org/?p=people/bonnietwin/ipfire-2.x.git;a=commit;h=4fbf17...

As far as i can see, isn´t this not the old code from my previouse patches ? The BLAKE algorithm for the HMACs has been reverted and some plausibility checks and some configuration logic has been reformated (tabs instead of dot´s) or have i overlooked something ?

Yes, the start basis was your patches. I made that clear at the start of this email communication on the status.

I don't have the capability to start anew and that definitely didn't seem sensible when you had already done the work initially.

I removed the BLAKE options and the tls-crypt v2 as these seemed to give too many options to people to start with. The tls-crypt gives an improved option for people creating new connections.

We can always add these in later on but the options here seemed to be less the critical item as compared to the move to ncp and preparing for total removal of 64 bit ciphers in openvpn-2.7

I also removed all the options for the ciphers for the control channel. There were no defaults and in that case openvpn makes the choice and seems to choose the best capable option. In my case a tls-1.3 was always chosen.

The openvpn ref manual says the following about those ciphers

" WARNING: --tls-ciphers, --tls-ciphersuites and tls-groups These options are expert features, which - if used correctly - can improve the security of your VPN connection. But it is also easy to unwittingly use them to carefully align a gun with your foot, or just break your connection. Use with care! "

This indicates that experts can use them well but for non-experts they could be dangerous. Therefore I removed them as options and experts can always add them in as options into their client specific config additions.

This way openvpn will choose the best option for people and that seemed a good situation to be in.

I also moved all the advanced encryption into the advanced server section. This was something that Michael preferred and it also seems sensible to me as then by default a user can just set the global settings and everything else could run with the default settings which would give a good secure system, also good for the future.

I did make some formatting changes but I intend to revert those as in the diff they don't appear to have given the result I was expecting.

The diff is not completed yet but a work in progress and still needs additions for the compression migration path for those users who have selected LZO in the past.

Also the whole diff will then need to be split up into separate patches. I didn't stay with you patch subdivision because I had difficulty trying to follow all the separate changes and understand how to make the changes I was planning. Therefore I applied your whole change set and then have been editing that version with my changes I was able to more easily understand and follow the file with all changes applied to it. That was just my capability limitations.

Regards, Adolf.

...

At the moment it is still a single set of all changes as that way I could understand the whole picture and the bits that I was changing. I still need to add the LZO stuff plus other changes based on our email discussion in the last few days.

When that is all done and we are generally agreed on the approach then I will split all the changes into separate chunks to go in separate patches of a patch set.

With the diff in my git repo you can apply that and see the changes and simplifications that I have made so far before our email discussions.

Regards,

Adolf.

Best,

Erik

...

...

...

...

My first attempt to try and be able to understand the changes from each patch to figure out what I needed to do proved difficult for me to work with.

What I then did was take the current ovpnmain.cgi and apply all of Erik's patches to it.

Then I have gone through that new version of ovpnmain.cgi and made the changes based on previous discussions with Michael.

So I have removed the b2sum options that were present for the Data and Channel Authentication.

I also moved all the cryptographic options from an additional advanced cryptographic options button into the Advanced Server options button.

I was successful in doing all the above and then tested the ovpnmain.cgi out with a vm using the existing openvpn-2.5.9 version for openvpn.

My old profile for my laptop which had a ciphers entry worked without any problem. My laptop was working withy openvpn-2.6.6

I then created a new profile using the new ovpnmain.cgi using the negotiation option which ended up with a data-ciphers line. That also worked in making a successful openvpn tunnel with my laptop without any issues.

I then downgraded my laptop to openvpn-2.4.8 and had to install openvpn-1.1.1 to make that work.

With that client version on my laptop both the old and new profiles connected with a tunnel with no problems.

I then tried downgrading my laptop to openvpn-2.3.14 but to make this work I would have had to downgrade the laptop to openssl-1.0.0 which I was not willing to do as that is very old and very insecure.

The oldest openvpn version working with openssl-1.1.1 is 2.4.0 which is nearly 7 years old.

I think that it is an acceptable baseline to only support OpenVPN 2.4 and up. That is already a lot more than we actually need to do, and we would support clients that are probably vulnerable to many things… If we need to drop support for OpenVPN 2.4 in this process, that might also be acceptable.

What is *not* so acceptable is that the client configuration file has to be changed in order to keep working with newer clients, because that would require that admins update every single configuration file if the client software is being updated. And that can be a nightmare with hundreds of connections.

From Erik's input and my understanding and my experiments there will be no need for any client configuration to be done as an immediate consequence of the changes I am working on.

If the users are using openvpn-2.4 up then the negotiation from the openvpn server will work even if the client has BF-CBC specified as a cipher. I have proven this with openvpn-2.4.0 on my laptop with a connection profile using BF-CBC and the connection was made with AES-GCM.

The users will however need to take the opportunity of the migration approach with this openvpn work to update the clients from BF-CBC on a one by one basis. This needs to be done for when the change to openvpn-2.7 occurs because that version branch will no longer recognise those old 64 bit ciphers at all.

I can understand the concern if all client connections had to be updated in a big bang situation but with the changes being worked on in this openvpn cgi code the users will be able to update each client as they have time. This set of changes provides the migration opportunity for a one by one client update and still maintaining the non-updated client connections.

...

Being on the topic of compatibility, I do believe that it is acceptable that connections that are generated today are only working with clients OpenVPN >= 2.6 if we have to do it.

I don't think there is any restriction like that, that will occur. However any new client connection that is created will be made with the data-ciphers option and older insecure ciphers will not be able to be selected for new connections. If a new connection is being created then there will be a new .p12 certificate as well so the package set will need to be transferred to the client anyway so that restriction should not create a problem.

...

...

That version also worked with both the old and new laptop profiles.

I then tested out the openvpn server on my IPFire vm with a 2.6.0 and 2.6.6 version of openvpn.

Both these openvpn versions worked with both the old and new laptop connection profiles with my laptop on version 2.4.0 and on 2.6.6

All the above was using network manager with its openvpn plugin option on the laptop for making the openvpn tunnel connections.

As far as I can tell everything is working fine when negotiation is specified on the server. Old profiles that just use the cipher option also work fine. Therefore my plan is to only use the negotiation option and not make it selectable for older clients. The data-ciphers-fallback option in the server seems to be doing its job.

The negotiation option on the server was able to connect to a 2.4.0 client on my laptop.

According to the OpenVPN wiki on cipher negotiation the data- ciphers-fallback option will work with 2.4.x and 2.3.x clients. As the 2.3.x clients need to be using openssl-1.0.0 then I think if those clients work then fine but nothing further back.

Overall, I am very happy with what I have succeeded in doing so far. I achieved things much quicker than I had expected.

I will now try and see about creating a profile on a CU 179 based system that uses one of the old insecure ciphers such as Blow Fish and restore that into my evaluation vm and see how that works with my laptop when I have it downgraded to openvpn- 2.4.0

I already know that if the laptop is at openvpn-2.6.6 then it will not accept a blowfish cipher (or another weak cipher such as DES) as that is something I tested in the past.

If that also works then my plan will be to take the updated ovpnmain.cgi and split the changes into a new range of patches and then submit them for consideration.

Okay, just to sum this up for me, what will happen is this (in no particular order):

• The cipher option in the configuration file will be removed and

changed to data-cipher-fallback. That way, we will continue to support older clients and new ones will use NCP.> * There will be a new UI element where people can select ciphers to use in “data- ciphers” very similarly to how to select a cipher for IPsec

• There will be a deprecation warning for people who use an older

(64 bit) “CIPHER” and they will be encouraged to upgrade all their clients to OpenVPN >= 2.4 (which should already have happened anyways) and they should use NCP only (i.e. no data- cipher-fallback option in the server configuration file any more). This will also be the new default.

No. The server will have both a data-cipher and a data-fallback- cipher option line, selected from the WUI.

However the server will try for a negotiation first using the ciphers listed in the data-ciphers list (can be more than one). If the server and client find a cipher that they both have in their list then they will agree on that. Only if nothing can be agreed will the server go to the fallback option. However it seems that openvpn-2.4.x versions onwards include the AEAD ciphers and therefore all my testing even with a client of 2.4.0 resulted in a successful negotiation of AES-GCM (256 bit) even when the config in the client had cipher BF-CBC specified.

...

How do we do all this for N2N connections? Is is safe to just remove the cipher option entirely because we assume that all clients perform NCP anyways?

I haven't started looking at that yet. I was trying to get to a working process with RW tested out with old client versions and insecure ciphers. I an just about at that point now so I will start to look at the N2N situation and consequences for existing connections in early November.

...

• In the near future (2.7), the fallback option will have to be

removed for all, which will render clients that are OpenVPN <= 2.4 unusable. This is probably acceptable at this point in time.

That is true, but it will also render clients unusable that have not taken the opportunity from this openvpn cgi update that is being discussed, to update the clients from cipher 64_bit_insecure to data-cipher secure as mentioned earlier.

...

• We will have to deprecate LZO as well. Do your patches include

anything about that?

No not yet. The cgi update being worked on also works with openvpn- 2.5.9, the current version. We could do the cgi release with the current version of openvpn and after any debugging that is flagged up we could then do an update to openvpn-2.6.x where x could be anywhere between 0 and 6. I have tested the cgi changes with openvpn version 2.5.9, 2.6.0 and 2.6.6 and it worked the same way for all three versions.

For the LZO situation, the migration path to allow users with compression to be update on a one by one basis is only available from version 2.6.0

To prevent asking users to make multiple updates of client connections (which I understand would also be undesirable) then we would need to issue the cgi update together with an update to at least 2.6.0 and with the LZO changes.

I have not yet had the chance to work on those. They will probably come after the N2N checks and evaluation with the changes have been completed. I will also need to do testing of any changes of the LZO with my setup and that is not something I have evaluated to date.

Regards, Adolf.

...

...

That will probably end up later in November as I will be busy with personal things at the end of October / beginning of November.

Regards,

Adolf.

-Michael

Hi Erik,

On 18/10/2023 12:26, ummeegge wrote:

Hello Adolf,

Am Mittwoch, dem 18.10.2023 um 11:55 +0200 schrieb Adolf Belka:

...

Hi Erik,

On 18/10/2023 11:29, ummeegge wrote:

...

Hi Adolf,

Am Sonntag, dem 15.10.2023 um 15:43 +0200 schrieb Adolf Belka:

...

Hi Michael,

On 14/10/2023 15:57, Adolf Belka wrote:

...

Hi Michael,

On 14/10/2023 14:05, Michael Tremer wrote:

...

Hello everyone,

Apologies for my late response on this. The last week had a couple of urgent things that were tying me in, but I was happy to see that we are finally making some progress on OpenVPN…

> On 9 Oct 2023, at 13:05, Adolf Belka > adolf.belka@ipfire.org > wrote: > > Hi All, > > > Over the last week I have been working on the openvpn > update > using Erik's previous patches as my starting point.

Could you please push those changes to a Git repository for review? Or did that happen already and I just was too blind to find them...

No, I have been working on them on my vm on my desktop system as there has been a lot of coming and going as I worked on understanding various things. What I have now is different from what I started with.

I will try and push the changes to my git repository but currently it is just a single set of changes. I have not yet started to break the changes into sections to have a commit patch against them yet.

I have pushed the changes as a single diff into my IPFire repo.

https://git.ipfire.org/?p=people/bonnietwin/ipfire-2.x.git;a=commit;h=4fbf17...

As far as i can see, isn´t this not the old code from my previouse patches ? The BLAKE algorithm for the HMACs has been reverted and some plausibility checks and some configuration logic has been reformated (tabs instead of dot´s) or have i overlooked something ?

Yes, the start basis was your patches. I made that clear at the start of this email communication on the status.

I don't have the capability to start anew and that definitely didn't seem sensible when you had already done the work initially.

True and good to see that you go this way.

...

I removed the BLAKE options and the tls-crypt v2 as these seemed to give too many options to people to start with. The tls-crypt gives an improved option for people creating new connections.

We can always add these in later on but the options here seemed to be less the critical item as compared to the move to ncp and preparing for total removal of 64 bit ciphers in openvpn-2.7

Totally agree with.

...

I also removed all the options for the ciphers for the control channel. There were no defaults and in that case openvpn makes the choice and seems to choose the best capable option. In my case a tls-1.3 was always chosen.

The openvpn ref manual says the following about those ciphers

" WARNING: --tls-ciphers, --tls-ciphersuites and tls-groups      These options are expert features, which - if used correctly - can improve the security of your VPN connection. But it is also easy to unwittingly use them to carefully align a gun with your foot, or just break your connection. Use with care! "

This indicates that experts can use them well but for non-experts they could be dangerous. Therefore I removed them as options and experts can always add them in as options into their client specific config additions.

This makes the WUI also more readable with a better overview in my opinion but even if more options would by time come in there might be ways to bring on a better overview but this is future sound...

...

This way openvpn will choose the best option for people and that seemed a good situation to be in.

I also moved all the advanced encryption into the advanced server section. This was something that Michael preferred and it also seems sensible to me as then by default a user can just set the global settings and everything else could run with the default settings which would give a good secure system, also good for the future.

Sound is good and i did it also in the same way in the Gitlab repo where i sended you a link at that time may you remember. Have also reopened it since there are some other stuff meanwhile in but also not updated in the last time. The Gitlab repo does includes also a wiki (which was the reason to open it up for this topic) for explaining all the commits. If you want to go over it to get may some more infos, you can find it here --> https://gitlab.com/ummeegge/openvpn-2.5.x/-/wikis/Explanation-of-the-OpenVPN...

...

I did make some formatting changes but I intend to revert those as in the diff they don't appear to have given the result I was expecting.

The diff is not completed yet but a work in progress and still needs additions for the compression migration path for those users who have selected LZO in the past.

OK, are you planning to use the '--compress migrate' option ?

Yes, that was my plan. Not tested yet but will do so when I get some time.

Adolf.

...

Also the whole diff will then need to be split up into separate patches. I didn't stay with you patch subdivision because I had difficulty trying to follow all the separate changes and understand how to make the changes I was planning. Therefore I applied your whole change set and then have been editing that version with my changes I was able to more easily understand and follow the file with all changes applied to it. That was just my capability limitations.

Great. The above linked wiki includes also links to the patches, screenshots and further explanations, some of them are already merged in IPFire e.g. the 'Finite_field_DH-parameter'. Even the ovpnmain.cgi in there is outdated, it might be may useful.

...

Regards, Adolf.

Best,

Erik

...

...

...

At the moment it is still a single set of all changes as that way I could understand the whole picture and the bits that I was changing. I still need to add the LZO stuff plus other changes based on our email discussion in the last few days.

When that is all done and we are generally agreed on the approach then I will split all the changes into separate chunks to go in separate patches of a patch set.

With the diff in my git repo you can apply that and see the changes and simplifications that I have made so far before our email discussions.

Regards,

Adolf.

Best,

Erik

...

...

...

> My first attempt to try and be able to understand the > changes > from each patch to figure out what I needed to do proved > difficult for me to work with. > > What I then did was take the current ovpnmain.cgi and apply > all > of Erik's patches to it. > > Then I have gone through that new version of ovpnmain.cgi > and > made the changes based on previous discussions with > Michael. > > So I have removed the b2sum options that were present for > the > Data and Channel Authentication. > > I also moved all the cryptographic options from an > additional > advanced cryptographic options button into the Advanced > Server > options button. > > I was successful in doing all the above and then tested the > ovpnmain.cgi out with a vm using the existing openvpn-2.5.9 > version for openvpn. > > My old profile for my laptop which had a ciphers entry > worked > without any problem. My laptop was working withy openvpn- > 2.6.6 > > I then created a new profile using the new ovpnmain.cgi > using > the negotiation option which ended up with a data-ciphers > line. > That also worked in making a successful openvpn tunnel with > my > laptop without any issues. > > I then downgraded my laptop to openvpn-2.4.8 and had to > install > openvpn-1.1.1 to make that work. > > With that client version on my laptop both the old and new > profiles connected with a tunnel with no problems. > > I then tried downgrading my laptop to openvpn-2.3.14 but to > make this work I would have had to downgrade the laptop to > openssl-1.0.0 which I was not willing to do as that is very > old > and very insecure. > > The oldest openvpn version working with openssl-1.1.1 is > 2.4.0 > which is nearly 7 years old.

I think that it is an acceptable baseline to only support OpenVPN 2.4 and up. That is already a lot more than we actually need to do, and we would support clients that are probably vulnerable to many things… If we need to drop support for OpenVPN 2.4 in this process, that might also be acceptable.

What is *not* so acceptable is that the client configuration file has to be changed in order to keep working with newer clients, because that would require that admins update every single configuration file if the client software is being updated. And that can be a nightmare with hundreds of connections.

From Erik's input and my understanding and my experiments there will be no need for any client configuration to be done as an immediate consequence of the changes I am working on.

If the users are using openvpn-2.4 up then the negotiation from the openvpn server will work even if the client has BF-CBC specified as a cipher. I have proven this with openvpn-2.4.0 on my laptop with a connection profile using BF-CBC and the connection was made with AES-GCM.

The users will however need to take the opportunity of the migration approach with this openvpn work to update the clients from BF-CBC on a one by one basis. This needs to be done for when the change to openvpn-2.7 occurs because that version branch will no longer recognise those old 64 bit ciphers at all.

I can understand the concern if all client connections had to be updated in a big bang situation but with the changes being worked on in this openvpn cgi code the users will be able to update each client as they have time. This set of changes provides the migration opportunity for a one by one client update and still maintaining the non-updated client connections.

...

Being on the topic of compatibility, I do believe that it is acceptable that connections that are generated today are only working with clients OpenVPN >= 2.6 if we have to do it.

I don't think there is any restriction like that, that will occur. However any new client connection that is created will be made with the data-ciphers option and older insecure ciphers will not be able to be selected for new connections. If a new connection is being created then there will be a new .p12 certificate as well so the package set will need to be transferred to the client anyway so that restriction should not create a problem.

...

> That version also worked with both the old and new laptop > profiles. > > I then tested out the openvpn server on my IPFire vm with a > 2.6.0 and 2.6.6 version of openvpn. > > Both these openvpn versions worked with both the old and > new > laptop connection profiles with my laptop on version 2.4.0 > and > on 2.6.6 > > All the above was using network manager with its openvpn > plugin > option on the laptop for making the openvpn tunnel > connections. > > As far as I can tell everything is working fine when > negotiation is specified on the server. Old profiles that > just > use the cipher option also work fine. Therefore my plan is > to > only use the negotiation option and not make it selectable > for > older clients. The data-ciphers-fallback option in the > server > seems to be doing its job. > > The negotiation option on the server was able to connect to > a > 2.4.0 client on my laptop. > > According to the OpenVPN wiki on cipher negotiation the > data- > ciphers-fallback option will work with 2.4.x and 2.3.x > clients. > As the 2.3.x clients need to be using openssl-1.0.0 then I > think if those clients work then fine but nothing further > back. > > Overall, I am very happy with what I have succeeded in > doing so > far. I achieved things much quicker than I had expected. > > I will now try and see about creating a profile on a CU 179 > based system that uses one of the old insecure ciphers such > as > Blow Fish and restore that into my evaluation vm and see > how > that works with my laptop when I have it downgraded to > openvpn- > 2.4.0 > > I already know that if the laptop is at openvpn-2.6.6 then > it > will not accept a blowfish cipher (or another weak cipher > such > as DES) as that is something I tested in the past. > > If that also works then my plan will be to take the updated > ovpnmain.cgi and split the changes into a new range of > patches > and then submit them for consideration.

Okay, just to sum this up for me, what will happen is this (in no particular order):

• The cipher option in the configuration file will be removed

and changed to data-cipher-fallback. That way, we will continue to support older clients and new ones will use NCP.> * There will be a new UI element where people can select ciphers to use in “data- ciphers” very similarly to how to select a cipher for IPsec

• There will be a deprecation warning for people who use an

older (64 bit) “CIPHER” and they will be encouraged to upgrade all their clients to OpenVPN >= 2.4 (which should already have happened anyways) and they should use NCP only (i.e. no data- cipher-fallback option in the server configuration file any more). This will also be the new default.

No. The server will have both a data-cipher and a data- fallback- cipher option line, selected from the WUI.

However the server will try for a negotiation first using the ciphers listed in the data-ciphers list (can be more than one). If the server and client find a cipher that they both have in their list then they will agree on that. Only if nothing can be agreed will the server go to the fallback option. However it seems that openvpn-2.4.x versions onwards include the AEAD ciphers and therefore all my testing even with a client of 2.4.0 resulted in a successful negotiation of AES-GCM (256 bit) even when the config in the client had cipher BF-CBC specified.

...

How do we do all this for N2N connections? Is is safe to just remove the cipher option entirely because we assume that all clients perform NCP anyways?

I haven't started looking at that yet. I was trying to get to a working process with RW tested out with old client versions and insecure ciphers. I an just about at that point now so I will start to look at the N2N situation and consequences for existing connections in early November.

...

• In the near future (2.7), the fallback option will have to

be removed for all, which will render clients that are OpenVPN <= 2.4 unusable. This is probably acceptable at this point in time.

That is true, but it will also render clients unusable that have not taken the opportunity from this openvpn cgi update that is being discussed, to update the clients from cipher 64_bit_insecure to data-cipher secure as mentioned earlier.

...

• We will have to deprecate LZO as well. Do your patches

include anything about that?

No not yet. The cgi update being worked on also works with openvpn- 2.5.9, the current version. We could do the cgi release with the current version of openvpn and after any debugging that is flagged up we could then do an update to openvpn-2.6.x where x could be anywhere between 0 and 6. I have tested the cgi changes with openvpn version 2.5.9, 2.6.0 and 2.6.6 and it worked the same way for all three versions.

For the LZO situation, the migration path to allow users with compression to be update on a one by one basis is only available from version 2.6.0

To prevent asking users to make multiple updates of client connections (which I understand would also be undesirable) then we would need to issue the cgi update together with an update to at least 2.6.0 and with the LZO changes.

I have not yet had the chance to work on those. They will probably come after the N2N checks and evaluation with the changes have been completed. I will also need to do testing of any changes of the LZO with my setup and that is not something I have evaluated to date.

Regards, Adolf.

...

> That will probably end up later in November as I will be > busy > with personal things at the end of October / beginning of > November. > > > Regards, > > Adolf. >

-Michael