Enhanced Decryption Troubleshooting

A new Decryption Log and new Application Command Center (ACC) widgets provide enhanced visibility into TLS traffic, which enables you to troubleshoot and monitor decryption issues and identify traffic that uses weak algorithms and protocols. Use the new ACC widgets to identify traffic for which decryption causes issues and then use the new Decryption Log to drill down into details and gain context about that traffic.
The new
ACC
SSL Activity
widgets show you details about both successful and unsuccessful SSL Decryption activity in your network. They identify traffic—applications and Server Name Identifications (SNIs)—that cause decryption issues and that use weak ciphers and algorithms. Use that knowledge to identify misconfigured Decryption policies and profiles and to make informed decisions about what traffic to allow and what traffic to block. You can view SSL/TLS traffic in the ACC in multiple ways:
  • Traffic Activity Widget
    —Shows SSL/TLS activity compared to non-SSL/TLS activity by total number of sessions or bytes.
  • Successful TLS Version Activity Widget
    —Shows successful TLS connections by TLS version and application or SNI. This widget helps you understand how much risk you are taking on by allowing weaker TLS protocol versions. Identifying applications and SNIs that use weak protocols enables you to evaluate each one and decide whether you need to allow access to it for business reasons. If you don’t need the application for business purposes, you may want to block the traffic instead of allowing it. Click an application or an SNI to drill down and see detailed information.
  • Decryption Failure Reasons Widget
    —Shows the reasons for decryption failures, such as certificate or protocol issues, by SNI. Use this information to detect problems caused by Decryption policy or profile misconfiguration or by traffic that uses weak protocols or algorithms. Click a failure reason to drill down and isolate the number of sessions per SNI or click an SNI to see the failures for that SNI.
  • SSL/TLS Traffic Widget
    —Shows the amount of decrypted and non-decrypted traffic by sessions or bytes. Traffic that was not decrypted may be excepted from decryption by policy, policy misconfiguration, or by being on the Decryption Exclusion List (
    Device
    Certificate Management
    SSL Decryption Exclusion
    ).
  • Successful Key Exchange Activity
    —Shows successful key exchange activity per algorithm, by application or by SNI. Click a key exchange algorithm to see the activity for just that algorithm or click an application or SNI to view the key exchange activity for that application or SNI.
The new Decryption Log (
Monitor
Logs
Decryption
) provides comprehensive information about sessions that match a Decryption policy. You can view log information such as application, SNI, Decryption Policy Name, error index, TLS version, key exchange version, encryption algorithm, certificate key types, and many other characteristics by selecting which columns to display:
decryption-log-and-columns-sapporo.png
The firewall doesn’t log network traffic unless it matches a Decryption Policy rule. To maintain visibility into traffic that you exclude from decryption, create a policy-based decryption exclusion (and apply a No Decryption profile to protect against certificate issues in policies that control TLSv1.2 and earlier traffic) so the policy governs the encrypted traffic and you can see it in the logs.
Click the magnifying glass icon ( icon_spyglass_log.png ) to see the Detailed Log View of a session:
detailed-ssl-decryption-log-view.png
After using the ACC to identify decryption issues, filter the Decryption Log to see detailed information about issues. Common troubleshooting tasks include:
  • Filtering for weak cipher suites to identify SNIs and applications that use older, less secure protocols and algorithms. For example, the filter
    (tls_version leq TLS1.1)
    shows you all traffic that uses TLS versions lower than TLSv1.2. You can then make an informed decision about how you want to handle traffic that uses weaker TLS versions.
    In the same way, you can filter for weak key exchange and encryption algorithms. For example, the filter
    (tls_keyxchg eq RSA)
    identifies all traffic that uses the RSA key exchange algorithm. The filter
    (tls_auth eq MD5)
    identifies all traffic that uses the MD5 authentication algorithm. The filter
    (tls_enc eq 3DES_EDE_CBC)
    identifies the traffic that uses that encryption algorithm.
    If you must allow traffic that uses weak protocols or algorithms, create a separate Decryption policy for them with a Decryption profile that allows the weaker security. Ensure that the policy allows only the traffic you need to allow.
  • Filtering for expired certificates. The filter
    (error eq ‘Expired server certificate’)
    identifies traffic that generates an “Expired server certificate” error. You can check the results at SSL Labs and see the validity dates of the certificate.
    You can also filter for certificates that will expire soon. For example, to filter for certificates that expire after July 1st, 2020, use the filter
    (notafter leq ‘2020/7/01 12:00:00’)
    .
  • Filtering for revoked certificates (you must first enable Certificate Revocation Checking to do this). Use the filter
    (error eq ‘OCSP/CRL check: certificate revoked’)
There are many ways to filter the extensive information in the Decryption Logs to drill down into the details of any issue or potential issue.

Recommended For You