in his December 2 post, @pmueller announces a major change coming to OpenVPN and IPSec.
If I understood correctly, this update of core 172 will improve the level of security but at the same time invalidate the operation of VPN clients already created and used (which may be numerous for some).
This change deserved at least this post and if we are not warned, all the old VPN clients will be deactivated and will need to be regenerated and configured again on the client workstations…
In this period of the end of the year (and holidays for many), this update 172 promises to be painful and to bring its share of unhappy people.
Once an update has been released (e.g. 172), it’s a pity that you can’t choose / force an earlier update (e.g. CU 171) and later plan a VPN-specific migration plan with the collaborators (at a date when this function would be less in demand)…
I find it very unfortunate that when performing this update, a warning message does not appear to present this important change in operation and to allow the update to be postponed.
So once again if I understand correctly, for all users of VPN via IPFire, let’s hurry to update our firewalls to CU 171 before 172 comes out or prepare for some night work…
I have tested my OpenVPN clients with CU172 Testing and everything worked as normal with no issues with OpenVPN.
I would expect the same with IPSec but I don’t have this setup for testing on my systems currently.
If all the clients needed to be re-created then the change would likely not even be considered for release.
The fact that newer openvpn commands are not yet being used and we are staying with some of the deprecated versions is because those newer versions would stop clients using older insecure ciphers, such as BlowFish (BF-CBC) which is still being used by some IPFire users, from working.
How to use the newer commands while allowing the older versions to be still available is the challenge facing updates of OpenVPN.
Doing something that could break users IPFire installations is always uppermost in the developers minds and they would not release that without a way of enabling existing users to continue running.
Of course accidents can happen but that is why we have the testing phase and there has been no feedback from anyone of OpenVPN or IPSec clients stopping working with CU172 Testing.
no offense on my part, I was just wondering about this risk of a malfunction with VPN clients created with the CU 171 or earlier… Here I am reassured !
Fervent supporter of IPFire for years, I don’t doubt the seriousness of the developers but it seemed interesting to me to bring up the subject…
Note: Would a user have carried out tests (with CU 172 testing) on a firewall in production, at the risk of losing their customers’ VPN connections?
I just want to add some extra words to the CU172 situation for clarification.
The Diffie Hellman change being made with OpenVPN is automatically done with no manual action needed at all.
Your existing clients and peers will automatically benefit from the improved cryptography with no hiccup.
The IPSec/OpenVPN host certificates have always been 4096 bit so nothing is required to be done there.
The IPSec/OpenVPN client certificates have historically been set at 2048 bit. This is not immediately insecure but it is no longer recommended for long term security purposes.
The default value for newly generated client/peer certificates will now be 4096 bit. However all the existing client certificates will continue to operate but updating them to 4096 bit will require the connections to be re-created but it can be done at the pace that you want it to be done at.
If you have data that is considered highly sensitive then you may want to look at recreating the certificates sooner rather than later to prevent people collecting and storing your existing encrypted communications until the capability to break the 2048 bit encryption has been reached which is believed to become likely with Quantum Computing in the future. Currently today that still can’t be done and the number of Qubits in the Quantum Computer to do that is still very large compared to the current state of Quantum Computing but both of those numbers are improving, one getting smaller and the other larger.
I hope this helps remove any concerns about changes having to be made because things stop working but planning for the future is required, depending on the criticality of the data/info that is being sent encrypted by these tunnels.
Currently 2048 bit asymmetric keys can not be broken by existing computers.
Typically in articles 2048 bit capability is being indicated to likely be good to the year 2030 but that is an estimate with wide error bars dependent on how quickly Quantum Computing is available with enough Qubits.
If you are dealing with information that is not so sensitive or is time limited then 2048 bit will probably be fine for quite a while. You can update to 4096 as you able to organise it for future proofing but it is not anything urgent that needs to be worried about.
If you are dealing with sensitive personal information like medical records or similar then you might want to update from 2048 bit to 4096 bit but not because the traffic can be broken but because apparently there is activity to collect this type of encrypted data on the internet and to store it until the encryption can be broken and then to use that sensitive data for nefarious reasons in the future.
That is what is also mentioned in the CU172 release notes about PQC (Post Quantum Cryptography) as the next step beyond 4096 bits for those types of capture now, decrypt later attacks.
So you need to review the type of data you are transmitting and the criticality of it to determine the best level of encryption that you need.
I also note that the TA key If you have ticked the (TLS Channel Protection:) option remains 2048 length " # 2048 bit OpenVPN static key"
I toggled off the protection restarted openvpn and then toggled on to see if the TA key was regenerated however it remained 2048… On a new install would this be forced up to 4096… ?
The only thing that will change automatically is that your DH parameter will change to 4096 bit automatically.
If you want to change any existing client certificates from 2048 bit to 4096 bit you will need to recreate them. If you do nothing, then the existing client connections will stay working with 2048 bit security which is still quite good, just no longer recommended for long term security.
Any newly created client connections will end up with 4096 bit certificates.
The ta.key generation comes from OpenVPN and there is no option in that command for setting a bit strength. It just generates a single size of key.
From OpenVPN :-
The tls-auth HMAC signature provides an additional level of security above and beyond that provided by SSL/TLS. It can protect against:
DoS attacks or port flooding on the OpenVPN UDP port.
Port scanning to determine which server UDP ports are in a listening state.
Buffer overflow vulnerabilities in the SSL/TLS implementation.
SSL/TLS handshake initiations from unauthorized machines (while such handshakes would ultimately fail to authenticate, tls-auth can cut them off at a much earlier point).
Using tls-auth requires that you generate a shared-secret key that is used in addition to the standard RSA certificate/key:
So the tls-auth is providing a different additional security and not dealing with the content traffic encryption but the setup of the communication channel.
We now face the problem that our legacy USB-dongle based PKCS11 auth does not swallow 4k keys. Is there a possibility to “downgrade” the settings somewhere so that newly created connections still only have 2k?
I know that security-wise this is not optimal, but we need a temporary solution for new users now not being able to use the VPN dialin.
TIA!
It might be that it is only the second one of the two locations that needs to be changed back. The first one is for the Server Host certificate which I suspect you won’t have changed as that would need all connections to be re-done. However if you leave the server host certificate alone then it makes no difference which rsa strength key is specified for that one.
The second location is the one that creates the certificates for each client connection. This is the one that definitely would need to be reverted to 2048.
Make a backup copy of the ovpnmain.cgi in case something goes wrong and you need to change back to a working version.
A Core Update that involved any changes to the OpenVPN WUI page would likely overwrite your reversion.
!
,