Background
The sheer number of configuration options available within GlobalProtect is enough to send shivers down the spines of even the most experienced networking and security engineers. But one option you won’t find (easily, at least) is the ability to modify the SSL/TLS ciphers which are used to negotiate the VPN in the first place. For many organizations, it is critical that only specific cipher suites be used, and the default cipher suites used by GlobalProtect just don’t cut it. Thankfully, there are a few different ways in which we can alter both the TLS version and the cipher suites in use.
Solution 1 – Modify SSL/TLS Service Profile
In order for GlobalProtect to even function, an SSL/TLS Service Profile must be created and applied to the GlobalProtect Portal and Gateway. The SSL/TLS Service Profile is where we would select the SSL/TLS certificate and key for use in our remote-access VPN negotiations. Given this fact, it makes perfect sense to check here first. Browsing to Device → Certificate Management → SSL/TLS Service Profile, we can see that we are presented with the sole, lackluster option of changing the TLS version in use.
Tragically, there is nothing to be seen here in regard to the SSL/TLS cipher suites, themselves. Perhaps these limited controls over the TLS protocol in use is all you need, in which case you can stop reading here!
Option 2 – Switch From RSA to ECDSA
Since RSA has long-been the signing and key-exchange champion of the internet, it makes sense that cipher suites which leverage RSA are absolutely everywhere. We will cover RSA vs ECDSA in-depth in a future post. For now, we’ll have a brief primer:
RSA-Cryptography: Takes the product of two very large prime numbers, and uses the resulting semiprime to protect and encrypt the traffic. In order for a would-be attacker to break an RSA key, they would need to factor the semiprime number and find the two primes which were used in the initial calculations. This is a notoriously difficult process, and it gets even harder as the length of the RSA-key (measured in bits) grows larger. The bad news: With constant advances in computing, and the near limitless power of the cloud, factoring semiprime numbers is becoming more accessible for prying-eyes.
ECDSA-Cryptography: The Elliptical Curve Digital Signature Algorithm takes a different approach to encryption. ECDSA generates a mathematic curve and picks a point on it. Then, it multiplies that point by another number, therefore producing a different point on that same curve. In order to break an ECDSA-key, a would-be attacker needs to overcome the Elliptic Curve Discrete Logarithm Problem in order to find exactly where that new point lies. Needless to say, this is exceedingly difficult, and no significant progress has been made on this problem since it was introduced in 1985.
If you configure GlobalProtect to utilize both TLS1.2 and an RSA certificate, you can expect to see the following ciphers being used:
$ nmap --script ssl-enum-ciphers -p 443 example.cmdctrl.net
Starting Nmap 6.40 ( http://nmap.org ) at 2021-03-24 12:04 UTC
Nmap scan report for example.cmdctrl.net (192.0.2.8)
Host is up (0.08s latency).
PORT STATE SERVICE
443/tcp open https
| ssl-enum-ciphers:
| SSLv3: No supported ciphers found
| TLSv1.0: No supported ciphers found
| TLSv1.1: No supported ciphers found
| TLSv1.2:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA256 - strong
| TLS_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_RSA_WITH_AES_256_CBC_SHA256 - strong
| TLS_RSA_WITH_AES_256_GCM_SHA384 - strong
| compressors:
| NULL
|_ least strength: strong
Nmap done: 1 IP address (1 host up) scanned in 6.82 seconds
$However, if you were to instead upload an ECDSA certificate and key to your Palo Alto NGFW, then set it within an SSL/TLS Service Profile, you would see the following:
$ nmap --script ssl-enum-ciphers -p 443 example.cmdctrl.net
Starting Nmap 6.40 ( http://nmap.org ) at 2021-03-24 12:05 UTC
Nmap scan report for example.cmdctrl.net (192.0.2.8)
Host is up (0.10s latency).
PORT STATE SERVICE
443/tcp open https
| ssl-enum-ciphers:
| SSLv3: No supported ciphers found
| TLSv1.0: No supported ciphers found
| TLSv1.1: No supported ciphers found
| TLSv1.2:
| ciphers:
| TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - strong
| compressors:
| NULL
|_ least strength: strong
Nmap done: 1 IP address (1 host up) scanned in 4.24 seconds
$Due to the limited number of cipher suites in TLS1.2 which leverage ECDSA, there are only a handful of comparatively strong encryption algorithms available. As an added bonus, ECDSA cryptography takes much less computational power than RSA does, which has a direct improvement on the performance of the devices on both ends of the encrypted tunnel. A potential downside of using ECDSA-keys is that users on legacy devices, operating-systems, or browsers may be unable to communicate with your site (or, in this case, the GlobalProtect Portal and Gateway). But maybe that’s not such a bad thing after all…
Option 3 – Modify Ciphers Through CLI
You can search the GUI high-and-low, and you will never see an option (as of 10.0.4 code) which allows you to change the cipher suites in use. However, all hope is not lost, as we do have the ability to change ciphers through the CLI. Once you have SSHed to your Palo Alto NGFW, enter into configuration mode. From here, you must run the following commands and choose either yes or no to enable or disable the necessary ciphers or key-exchange algorithms, as needed:
sweet-t@cmdctrl-ngfw# set shared ssl-tls-service-profile test protocol-settings
+ auth-algo-sha1 Allow authentication SHA1
+ auth-algo-sha256 Allow authentication SHA256
+ auth-algo-sha384 Allow authentication SHA384
+ enc-algo-3des Allow algorithm 3DES
+ enc-algo-aes-128-cbc Allow algorithm AES-128-CBC
+ enc-algo-aes-128-gcm Allow algorithm AES-128-GCM
+ enc-algo-aes-256-cbc Allow algorithm AES-256-CBC
+ enc-algo-aes-256-gcm Allow algorithm AES-256-GCM
+ enc-algo-rc4 Allow algorithm RC4
+ keyxchg-algo-dhe Allow algorithm DHE
+ keyxchg-algo-ecdhe Allow algorithm ECDHE
+ keyxchg-algo-rsa Allow algorithm RSA
+ max-version max-version
+ min-version min-version
<Enter> Finish input
sweet-t@cmdctrl-ngfw# set shared ssl-tls-service-profile test protocol-settings auth-algo-sha1
no no
yes yesOnce you have disabled the ciphers or key-exchange algorithms as you see fit and committed your changes, go ahead and run another nmap scan as we did earlier in order to verify that everything worked as expected.