Identify Weak Protocols and Cipher Suites

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.