GlobalProtect appliance PCI Compliance

[wholetthedogsout]

Hi,

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:

THREAT:
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.

IMPACT:
An attacker with access to sufficient computational power might be able to recover the session key and decrypt session content.

SOLUTION:
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.

RESULT:
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?

Thanks.

[PatrickMurphy]

Me too! Have you figured it out yet?

[jmora]

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.

[wholetthedogsout]

It seems to have been an issue with the PCI compliance scanner.

We submitted the ssllabs.com report to them and they accepted it and passed.

[AlexHepworth]

Have we had any movement on this? Or any solution? Got quite a few customers complaining about this at the moment.

[JeremyD]

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

TestSSL {
protocol-settings {
min-version tls1-2;
max-version tls1-2;
auth-algo-sha1 no;
auth-algo-sha256 no;
auth-algo-sha384 yes;
enc-algo-3des no;
enc-algo-aes-128-cbc no;
enc-algo-aes-128-gcm no;
enc-algo-aes-256-cbc yes;
enc-algo-aes-256-gcm yes;
enc-algo-rc4 no;
keyxchg-algo-dhe yes;
keyxchg-algo-ecdhe yes;
keyxchg-algo-rsa no;
}

set shared ssl-tls-service-profile protocol-settings auth-algo-sha1 no
set shared ssl-tls-service-profile protocol-settings keyxchg-algo-rsa no

[JamesPlonsky]

Unfortunately, this still fails for our scan. ECDHE needs to be disabled for ours to pass.

However setting 

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".

[JeremyD]

looking at the supported release guidance post - 9.1.8, it might be worth upgrading the appliance past 9.1.8.

https://live.paloaltonetworks.com/t5/customer-resources/support-pan-os-software-release-guidance/ta-...

[BradVC]

We're having the exact same problem as well and an ssllabs.com report was not accepted.

[JamesPlonsky]

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.