communication #151492
closedVPN Security Configuration
0%
Description
While being on boarded, I noticed a number of security and accessibility issues with the current configuration of the VPN.
Recommendations
- Remove "auth-user-pass" from client configuration - certificate authentication only
- Change OpenVPN ciphers to AES-128-GCM instead of AES-256-CBC
To explain the above there are two facets.
First is about security failure domains. Within any secure system we want to limit the "blast radius" of any compromise. Of course we want to prevent compromise in the first place, but it is also an inevitable situation.
The current OpenVPN configuration relies on the following:
- Certificate Authentication
- TLS-AUTH static Key
- Username/Password
Each of these has a different purpose and overlap.
TLS-AUTH prevents bruteforce from "drive by" attacks, but is also not considered a true secret. If disclosed, the security of our VPN would not be measurably weakened.
Certificate Authentication allows unique per-user identification to the network boundary, but only to the network boundary. Within the network we still require other forms of authentication. This means that compromise of a certificate/key is limited to network access and other barriers must exist (see swiss cheese failure model)
Username/Password - this is the confusing part. We already have per-user authentication to the network via certificates, so the username password here is redundant for identification. To add further issues, currently hosts within the opensuse infra vpn accept username and password for ssh, and this same password is also used for sudo (a limit of freeipa's design).
As a result, the use of the username and password here weakens the security of the VPN, because many users will also have to store their username and password nearby or alongside their vpn configuration. This means that compromise of a machine with VPN access implicitly grants full ssh and sudo rights to users.
By removing the auth-user-pass requirement, this will allow our users to remove the username and password from adjacent storage, such that compromise of a VPN key and certificate limits the ability of an attacker to exploit further systems since they then also require extra credentials to pivot.
The ciphers currently used is AES-256-CBC + SHA512 MAC. While this appears secure, in cryptography big number != more secure.
AES-256 was created due to military standards stating that "there need to be three levels". This led to 128, 192 and 256 bit levels. However, at the same time the same designers created AES-128 to be resistant to future attacks. AES-128 is actually "as secure" as 256, and also is faster for CPU's and consumer devices. Similar is true for SHA, where SHA512 is slower, even though SHA256 is "as secure".
The reason to change to AES-128-GCM is that this is an AEAD cipher, meaning that it internally MAC's as part of it's operation. This cipher also has hardware acceleration in modern CPU's.
While it may seem odd, using AES-128-GCM will lower latency and CPU usage of client machines and VPN servers - critically important if you live on the other side of the planet and every millisecond counts.
Alternately, changing to AES-256-GCM would still allow the "AES-256" level, but reduce demand on the MAC side as SHA512 is far slower than S256.
This can be staged by changing the server allowed ciphers to AES-128-GCM:AES-256-GCM:AES-256-CBC and then working with current users to update their configurations.
Alternately, users can remove the cipher string and rely on the server to negotiate the correct ciphers instead making future changes easier.
Updated by firstyear 5 months ago
darix wrote in #note-2:
a way more fun question would be oidc support for openvpn :p
Without external plugins/hacks, I don't think this is viable.
In addition most VPN providers in linux and other OSes don't have good integrations and UIs for this to work in a user friendly way. This would make credential updating and user on boarding a very complicated process.
Finally part of the goal of the VPN is to provide isolation between infra and the world. Relying on OIDC for this would necessitate exposing the Kanidm webui to the world for the authentication, breaking that barrier down.
As a result, I think there is nothing wrong with the current certificate authentication strategy, as it provides strong authentication to the VPN, and with the changes I suggest it also provides isolation that the cryptograptic VPN credentials are isolated and do not have overlapping blast radius with sudo or ssh.
The changes I have suggested here are small changes that are practical and will measurable increase the security of what we already have.
Changing to OIDC would be a larger, riskier and complex process that would require more planning and care.
In summary, we should focus on the problem at hand and save the dreams/ideas for future, where we can perform proper security, risk and benefit assessments on them.
Updated by crameleon about 1 month ago
- Status changed from New to In Progress
- user/password authentication disabled by @firstyear via https://gitlab.infra.opensuse.org/infra/salt/-/merge_requests/1164
- compression to be disabled after announcement
Updated by crameleon about 1 month ago
Drafted email and requested feedback from @cboltz and @firstyear.
Updated by crameleon 28 days ago
Announcement sent to heroes@:
Hello!
We are implementing changes to the Heroes OpenVPN.
There are three changes - two are already implemented, and you likely did not notice - the other is breaking and requires changes in your client configuration after the 12th of April (one week from now)!SHORT version:
On April 12th, please visit the Admin Wiki and update your OpenVPN client configuration with the latest examples:
Native OpenVPN:
https://progress.opensuse.org/projects/opensuse-admin-wiki/wiki/VPN#OpenVPN-configNetworkManager:
https://progress.opensuse.org/projects/opensuse-admin-wiki/wiki/VPN#NetworkManager-setupAfterwards, delete any files containing Heroes credentials in plain text.
VERBOSE version:
- BREAKING: Removal of compression
On April 5th, LZO compression will be disabled on the OpenVPN server.
If you want to connect on or after this day, you will have to remove the respective option from your OpenVPN client configuration:With native OpenVPN:
comp-lzoWith NetworkManager:
compress=lzoIf you do not remove this option after it has been disabled on the server, you will receive error messages like "Bad LZO decompression header byte: xxx" blocking you from working in the Heroes network!
This change is implemented due to inherent security issues with compression in OpenVPN: https://community.openvpn.net/openvpn/wiki/Compression.
- Non-breaking: Removal of user/password authentication and change of ciphers
Previously we used two layers of authentication for OpenVPN:
- LDAP username/password
- client certificates
The LDAP layer is removed as it often encourages users to store sensitive data (i.e. the same passphrase also used for sudo elevation to root on our systems!) in plain text and does not yield a security benefit given the existing use of client certificates.
Additionally, we adjust the ciphers to make use of hardware acceleration and to decrease CPU load as well as latency for users in remote locations far away from our data center.
These changes have already been implemented and are compatible with existing clients - however we still ask you to remove the following lines from your client configuration:
With native OpenVPN:
auth-user-pass.* cipher AES-256-CBC data-ciphers AES-256-CBCWith NetworkManager:
username=.* password-flags=.* cipher=AES-256-CBC [vpn-secrets] password=.*Make sure to also delete any files containing the plain text credentials, such as the file previously passed as an argument to "auth-user-pass".
You can already implement the changes mentioned in point 2 now, or you do it together with the mandatory change mentioned in point 1 on April 12th.
All these changes are tracked and explained in https://progress.opensuse.org/issues/151492.
Thanks for collaborating!
If you have any questions, please let me know.Georg
Compression change will be implemented early on 2024-04-12.
Updated by crameleon 20 days ago ยท Edited
- Status changed from In Progress to Resolved
Implementation complete:
https://gitlab.infra.opensuse.org/infra/salt/-/merge_requests/1687
Final announcement sent to heroes@:
Hello!
All changes have now been implemented, and the examples in https://progress.opensuse.org/projects/opensuse-admin-wiki/wiki/VPN have been updated.
If you have not changed your client configuration yet, your setup should now be successfully broken! :-)Best,
Georg