We're trying to get our VPN appliance PCI compliant and not sure what is going on, as it's automatically failing.
Minimum TLS is 1.2 and have disabled all the weak key exchanges. This was done prior to any PCI compliance requirement.
When we run the SSL test on ssllabs.com, we're getting an A-.
The PCI report contains the below:
QID Detection Logic:
For a SSL enabled port, the scanner probes and maintains a list of supported SSL/TLS versions. For each supported version, the scanner does a SSL handshake to get a
list of KEX methods supported by the server. It reports all KEX methods that are considered weak. The criteria of a weak KEX method is as follows:
The SSL/TLS server supports key exchanges that are cryptographically weaker than recommended. Key exchanges should provide at least 112 bits of security, which
translates to a minimum key size of 2048 bits for Diffie Hellman and RSA key exchanges.
An attacker with access to sufficient computational power might be able to recover the session key and decrypt session content.
Change the SSL/TLS server configuration to only allow strong key exchanges. Key exchanges should provide at least 112 bits of security, which translates to a minimum
key size of 2048 bits for Diffie Hellman and RSA key exchanges.
PROTOCOL NAME GROUP KEY-SIZE FORWARD-SECRET CLASSICAL-STRENGTH QUANTUMSTRENGTH
TLSv1.2 ECDHE secp192r1 192 yes 96 low
TLSv1.2 ECDHE secp192k1 192 yes 96 low
TLSv1.2 ECDHE secp160r2 160 yes 80 low
TLSv1.2 ECDHE secp160r1 160 yes 80 low
TLSv1.2 ECDHE secp160k1 160 yes 80 low
TLSv1.2 ECDHE sect193r2 193 yes 96 low
TLSv1.2 ECDHE sect193r1 193 yes 96 low
TLSv1.2 ECDHE sect163r2 163 yes 81 low
TLSv1.2 ECDHE sect163r1 163 yes 81 low
TLSv1.2 ECDHE sect163k1 163 yes 81 low
The appliance is running 9.1.8.
Any ideas on how to resolve it?
Feature Request ID: 19980. Customer is requesting the ability to individually select which Elliptical Curves are used with ECDHA on sessions. Currently several easily broken curves are in use and undocumented, however, vulnerability scanners such as Qualys has discovered this weakness. The ability for a customer to select which curves are available for use provides a simple mechanism to alleviate this issue.
Currently it is unresolved. We have no CVE indicating vulnerability. Please reach out to your SE to be added to the FR.
if you want to customise the ssl-tls-profile to get an A or A+
create a new ssl/tls profile for globalprotect then using the cli modify the globalprotect profile to remove the unwanted combinations
see example below
set shared ssl-tls-service-profile protocol-settings auth-algo-sha1 no
set shared ssl-tls-service-profile protocol-settings keyxchg-algo-rsa no
Unfortunately, this still fails for our scan. ECDHE needs to be disabled for ours to pass.
set shared ssl-tls-service-profile protocol-settings keyxchg-algo-rsa yes
set shared ssl-tls-service-profile protocol-settings keyxchg-algo-ecdhe no
passes PCI scans, but then users with apple devices (and some windows) cannot connect. It will not proceed past the pre-auth stage, even though the last log entry is "success".
looking at the supported release guidance post - 9.1.8, it might be worth upgrading the appliance past 9.1.8.
We are on the latest release of the 9.1.x code. There is no fix for this.
The only workaround we have is to disable the ECDHE key exchange, and all the weak RSA ciphers. This does give us an approved scan.
However, this breaks the application for Apple devices (and any others) that look for the ECDHE keys almost exclusively. In GlobalProtect, the user is left with a blank white box, and cannot enter credentials.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!