Identify Weak Protocols and Cipher Suites

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.

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.
Start by checking the Application Command Center (ACC) to see if the firewall allows weak protocols (
ACC
SSL Activity
Successful TLS Version Activity
) 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 firewall is allowing traffic identified as web-browsing traffic. To gain insight into what that TLSv1.0 web-browsing traffic is and why it’s allowed, we go next to the Decryption logs.
Filter the Decryption log to check TLSv1.0 activity details.
Use the query
(tls_version eq TLS1.0) and (err_index eq ‘None’)
to show successful TLSv1.0 Decryption sessions.
Decryption logs show successful TLS activity only if you enable logging successful TLS handshakes in Decryption policy when you Configure Decryption Logging. If logging successful TLS handshakes is disabled, you can’t check this information.

The Decryption log shows us that the name of the Decryption policy 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 the Decryption policy (
Policies
Decryption
) 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 (
Objects
Decryption
Decryption 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 if you want to block it.
Another common scenario that results in the firewall 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 firewall 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 the Decryption log 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 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.
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 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 (
Options
tab).
If you need to access the site for business purposes, consider creating a Decryption policy 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.
Key Exchange
—Identify traffic that uses less secure key exchange algorithms.
Start by checking the Application Command Center (ACC) to see which key exchange algorithms the firewall allows (
ACC
SSL Activity
Successful Key Exchange Activity
) 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.
Go to the Decryption log (
Monitor
Logs
Decryption)
) 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 controls most of the traffic that uses RSA key exchanges and can infer that the firewall does not decrypt the traffic and allows it without inspection. Because the traffic isn’t decrypted, the firewall 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 ACC or in the first Decryption log query.
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 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 uses 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 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 log.