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.