Identify Weak Protocols and Cipher Suites

Table of Contents

Investigate Reasons for Decryption Failure

Identify Weak Protocols and Cipher Suites

Find sites that use weak encryption, authentication, and key exchange algorithms and weak TLS protocols to make informed decisions about allowed traffic.

Where Can I Use This?	What Do I Need?
All NGFW deployments, including those funded by software NGFW credits All Prisma Access deployments	No separate license required for decryption when using NGFWs or Prisma Access. Note: The features and capabilities available to you in Strata Cloud Manager depend on your active license(s).

Weak TLS protocols and weak cipher suites (encryption algorithms, authentication algorithms, key exchange algorithms, and negotiated EC curves) weaken your security posture and are easier for bad actors to exploit than strong TLS protocols and strong cipher suites.

Five fields in the Decryption log entries show the protocol and cipher suites for a decryption session:

Track down old, vulnerable TLS versions and cipher suites so that you can make informed decisions about whether to allow connections with servers and applications that may compromise your security posture.

The examples in this topic show how to:

Identify traffic that uses less secure TLS protocol versions.
Identify traffic that uses a particular key exchange algorithm.
Identify traffic that uses a particular authentication algorithm.
Identify traffic that uses a particular encryption algorithm.

These examples show you how to use the decryption troubleshooting tools in various ways so that you can learn to use them to troubleshoot any decryption issues you may encounter.

You can use Wireshark or other packet analyzers to double-check whether the client or the server caused an issue, TLS client and server versions, and other cipher suite information. This can help analyze version mismatches and other issues.

Identify Weak Protocols and Cipher Suites (Strata Cloud Manager)

Filter decryption logs to check TLSv1.0 activity details.

Decryption logs show successful TLS activity only if you select the Log Successful TLS Handshakes option in a decryption policy rule. If this option is disabled, you can’t see this information.
1. Select Log Viewer, and then select Firewall/Decryption.
2. Use the query (TLS Version = 'TLS1.0') AND (Error Index = 'None') to show successful TLSv1.0 decryption sessions.
  The decryption logs show us that the name of the decryption policy rule that controls the traffic. Now, we know the site that uses TLSv1.0 and can check the decryption policy rule to find the decryption profile that controls the traffic and learn why the traffic is allowed.
3. Find the decryption profile that controls the traffic to learn why the traffic is allowed.
  Select Configuration NGFW and Prisma Access Security Services Decryption, and search for the decryption policy rule you identified earlier.
  Scroll to the Profile column of the decryption policy rule. Alternatively, you can select the rule to open it. Then, under Action and Advanced Inspection, find the Decryption Profile.
  
  Example: The decryption profile associated with the policy rule is old TLS versions support.
4. Check the Protocol Versions that the decryption profile allows.
  Under Decryption Profiles, select the profile identified earlier.
  Under SSL/TLS Decryption, look at the Protocol Min Version and Protocol Max Version.
  
  Example: The profile allows TLSv1.0 traffic.
5. Decide if want to allow or block access to the website.
  Ask questions like "Do you need access for business purposes?"
  
  Another common scenario that results in the NGFW allowing traffic that uses less secure protocols is when that traffic is not decrypted. When you filter the decryption log for TLSv1.0 traffic, if the Proxy Type column contains the value No Decrypt, then a No Decryption policy controls the traffic, so the NGFW doesn't decrypt or inspect it. If you don’t want to allow the weak protocol, modify the decryption profile so that it blocks TLSv1.0 traffic.
  
  There are many ways you can filter decryption logs to find applications and sites that use weak protocols. For example:
  
  Instead of filtering only for successful TLSv1.0 handshakes, filter for both successful and unsuccessful TLSv1.0 handshakes using the query TLS Version = 'TLS1.0'.
  Filter only for unsuccessful TLSv1.0 handshakes using the query (TLS Version = 'TLS1.0') AND (Error Index = 'None').
  Filter for all less secure protocols (TLSv1.1 and earlier) using the query TLS Version <='TLS1.1'.
  If you want to filter the logs for other TLS versions, simply replace TLS1.0 or TLS1.1 with another TLS version.
Decide what action to take for sites that use weak TLS protocols.
- If you don’t need to access the site for business purposes, the safest action is to block access to the site by editing the decryption policy rule and decryption profile that control the traffic. The decryption log Policy Name column provides the policy name and the decryption policy shows the attached decryption profile (Action and Advanced Inspection tab).
- If you need to access the site for business purposes, consider creating a decryption policy rule and decryption profile that apply only to that site (or to that site and other similar sites) and block all other traffic that uses less secure protocols.
Identify traffic that uses less secure key exchange algorithms, for example, RSA.
1. Filter decryption logs using the query TLS Key Exchange = RSA:
  
  Select Log Viewer, and then select Firewall/Decryption.
  
  From the Policy Name column in the log, we see that the No Decrypt decryption policy rule controls most of the traffic that uses RSA key exchanges and can infer that the NGFW does not decrypt the traffic and allows it without inspection. Because the traffic isn’t decrypted, the NGFW can’t identify the application and lists it as ssl. If you don’t want to allow traffic that uses RSA key exchanges, modify the decryption profile attached to the decryption policy that controls the traffic.
  
  You can add to the query to further filter the results for a particular SNI or application that you saw in the first decryption log query.
2. Decide what action to take for traffic that uses less secure key exchange algorithms.
  
  Block access to sites that use less secure key exchange protocols unless you need to access them for business purposes. For those sites, consider creating a decryption policy rule and decryption profile that applies only to that site (or to that site and other similar sites), and block all other traffic that uses less secure key exchange algorithms.
Use the decryption logs to identify sessions that use older, less secure authentication algorithms.

Filter the decryption log to identify older, less secure authentication algorithms. For example, to identify all sessions that use the SHA1 algorithm, use the query TLS Auth = SHA.

You can add to the query to further drill down into the results. For example, you can add a particular SNI, a key exchange version (such as filtering for SHA1 sessions that also use RSA key exchanges), a TLS version, or any other metric found in a decryption log column.
Use the decryption logs to identify sessions that use a particular encryption algorithm.

For example, to identify all sessions that use the AES-128-CBC encryption algorithm, use the query TLS Encryption Algorithm = AES_128_CBC. You can add to the query to further drill down into the results.

Examples of queries to find other older encryption algorithms include: TLS Encryption Algorithm = DES_CBC, TLS Encryption Algorithm = 3DES_EDE_CBC, and TLS Encryption Algorithm = DES40_CBC.
Use this methodology and the log Query Builder to create queries to investigate negotiated ECC curves and any other information you find in the decryption logs.

Identify Weak Protocols and Cipher Suites (PAN-OS)

TLS Protocols—Identify traffic that uses older, less secure versions of the TLS protocol so that you can evaluate whether to allow access to servers and applications that use weak protocols.
1. Check the Application Command Center (ACCSSL ActivitySuccessful TLS Version Activity) for applications that use weak protocols and to get an overall view of activity.
  
  The majority of successful TLS activity in this example is TLSv1.2 and TLSv1.3 activity. However, there are a few instances of allowed TLSv1.0 traffic. Let’s click the number 49 to drill down into the TLSv1.0 activity and see which applications are making successful TLSv1.0 connections:
  
  We see that the NGFW allowed web-browsing traffic over a TLSv1.0 connection. To gain insight into what that TLSv1.0 web-browsing traffic is and why it’s allowed, we look at the decryption logs.
2. Filter the decryption logs by successful TLSv1.0 activity.
  
  To show successful TLSv1.0 decryption sessions, use the (tls_version eq TLS1.0) and (err_index eq ‘None’) query.
  
  Decryption logs show successful TLS activity only if you select the Log Successful TLS Handshakes option in a decryption policy rule. If this option is disabled, you can’t see this information.
  The decryption logs show us that the decryption policy rule that controls the traffic is Inner Eye and that the name of the host is hq-screening.mt.com. Now, we know the site that uses TLSv1.0 and we can check our decryption policy rules (PoliciesDecryption) to find the decryption profile that controls the traffic and learn why the traffic is allowed:
  
  We see that the decryption profile associated with the policy is old TLS versions support. We check the profile (ObjectsDecryptionDecryption Profile) and look at the SSL Protocol Settings to find out exactly what traffic the profile allows:
  
  The profile allows TLSv1.0 traffic. The next thing to do is to decide if you want to allow access to the site (do you need access for business purposes?) or block access.
  
  Another common scenario that results in the NGFW allowing traffic that uses less secure protocols is when that traffic isn’t decrypted. When you filter the decryption log for TLSv1.0 traffic, if the Proxy Type column contains the value No Decrypt, then a no-decryption policy rule controls the traffic, so the NGFW does not decrypt or inspect it. If you don’t want to allow the weak protocol, modify the decryption profile so that it blocks TLSv1.0 traffic.
  
  There are many ways you can filter decryption logs for applications and sites that use weak protocols, for example:
  
  Instead of filtering only for successful TLSv1.0 handshakes, filter for both successful and unsuccessful TLSv1.0 handshakes using the query (tls_version eq TLS1.0).
  Filter only for unsuccessful TLSv1.0 handshakes using the query (tls_version eq TLS1.0) and (err_index neq ‘None’).
  Filter for all less secure protocols (TLSv1.1 and earlier) using the query (tls_version leq tls1.1).
  
  If you want to filter the logs for other TLS versions, simply replace TLS1.0 or TLS1.1 with another TLS version.
3. Decide what action to take for sites that use weak TLS protocols.
  If you don’t need to access the site for business purposes, the safest action is to block access to the site by editing the decryption policy rule and decryption profile that control the traffic. The decryption log Policy Name column provides the policy name and the decryption policy rule shows the attached decryption profile (Options tab).
  If you need to access the site for business purposes, consider creating a decryption policy rule and decryption profile that applies only to that site (or to that site and other similar sites), and block all other traffic that uses less secure protocols.
Key Exchange—Identify traffic that uses less secure key exchange algorithms.
1. Check the Application Command Center (ACC) (ACCSSL ActivitySuccessful Key Exchange Activity) to see which key exchange algorithms the NGFW allows and to get an overall view of activity.
  
  The majority of the key exchanges use the secure ECDHE key exchange algorithm. However, some key exchange sessions use the less secure RSA algorithm and a few use another key algorithm. To begin investigating traffic that uses RSA key exchanges, for example, click the number 325 to drill down into the data.
  
  The drill-down shows the applications that use RSA key exchanges. We can also click the SNI radio button to view the RSA key exchanges by SNI:
  
  Armed with this information, we can go to the logs to gain more context about RSA key exchange usage.
2. Go to the decryption logs (MonitorLogsDecryption)) and filter them for decryption sessions that use the RSA key exchange using the query (tls_keyxchg eq RSA):
  
  From the Policy Name column in the log, we see that the No Decrypt decryption policy rule controls most of the traffic that uses RSA key exchanges and can infer that the NGFW doesn't decrypt the traffic and allows it without inspection. Because the traffic isn’t decrypted, the NGFW can’t identify the application and lists it as ssl. If you don’t want to allow traffic that uses the RSA key exchange algorithm, modify the decryption profile attached to the decryption policy rule that controls the traffic.
  
  You can add to the query to further filter the results for a particular SNI or application that you saw in the ACC or in the first decryption log query.
3. Decide what action to take for traffic that uses less secure key exchange algorithms.
  
  Block access to sites that use less secure key exchange protocols unless you need to access them for business purposes. For those sites, consider creating a decryption policy rule and decryption profile that apply only to that site (or to that site and other similar sites) and block all other traffic that uses less secure key exchange algorithms.
Use the decryption logs to identify sessions that use older, less secure authentication algorithms.

Filter the decryption logs by older, less secure authentication algorithms.

For example, to identify all sessions that use the SHA1 algorithm, use the query (tls_auth eq SHA):

You can add to the query to further drill down into the results. For example, you can add a particular SNI, a key exchange version (such as filtering for SHA1 sessions that also use RSA key exchanges), a TLS version, or any other metric found in a decryption log column.
Use the decryption logs to identify sessions that use a particular encryption algorithm.

For example, to identify all sessions that use the AES-128-CBC encryption algorithm, use the query (tls_enc eq AES_128_CBC):

You can add to the query to further drill down into the results.

Examples of queries to find other older encryption algorithms include: (tls_enc eq DES_CBC), (tls_enc eq 3DES_EDE_CBC), and (tls_enc eq DES40_CBC).
Use this methodology and the log filter builder to create queries to investigate negotiated ECC curves and any other information you find in the decryption logs.