Identify Weak Protocols and Cipher Suites (2024)

TLS Protocols

—Identify trafficthat uses older, less secure versions of the TLS protocol so thatyou can evaluate whether to allow access to servers and applicationsthat use weak protocols.

Start by checking the Application CommandCenter (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 majorityof successful TLS activity in this example is TLSv1.2 and TLSv1.3activity. However, there are a few instances of allowed TLSv1.0traffic. Let’s click the number

49

to drilldown into the TLSv1.0 activity and see which applications are makingsuccessful TLSv1.0 connections:



We seethat the firewall is allowing traffic identified as web-browsingtraffic. To gain insight into what that TLSv1.0 web-browsing trafficis and why it’s allowed, we go next to the Decryption logs.

See Also

Intersect Under ConstructionHow to Disable Weak SSL Cipher SuitesCracking Codes and Cryptograms For Dummies Cheat Sheet7 Secret Codes for Kids for Family Game Night - Waterford.org

Filter the Decryption log to check TLSv1.0 activity details.

Use the query

(tls_version eq TLS1.0) and (err_index eq ‘None’)

toshow successful TLSv1.0 Decryption sessions.

Decryptionlogs show successful TLS activity only if you enable logging successfulTLS handshakes in Decryption policy when you Configure Decryption Logging. If loggingsuccessful TLS handshakes is disabled, you can’t check this information.



The Decryption log shows us that the name of the Decryptionpolicy that controls the traffic is

Inner Eye

andthat the name of the host is

hq-screening.mt.com

.Now we know the site that uses TLSv1.0 and we can check the Decryptionpolicy (

Policies

Decryption

)to find the Decryption profile that controls the traffic and learnwhy the traffic is allowed:



We seethat the Decryption profile associated with the policy is

oldTLS versions support

. We check the profile (

Objects

Decryption

Decryption Profile

) and lookat the SSL Protocol Settings to find out exactly what traffic theprofile allows:



The profileallows TLSv1.0 traffic. The next thing to do is to decide if you wantto allow access to the site (do you need access for business purposes?)or if you want to block it.

Another common scenario that resultsin the firewall allowing traffic that uses less secure protocolsis when that traffic is not decrypted. When you filter the Decryptionlog for TLSv1.0 traffic, if the

Proxy Type

columncontains the value

No Decrypt

, then a NoDecryption policy controls the traffic, so the firewall does notdecrypt or inspect it. If you don’t want to allow the weak protocol,modify the Decryption profile so that it blocks TLSv1.0 traffic.

Thereare many ways you can filter the Decryption log to find applications andsites that use weak protocols, for example:

Insteadof filtering only for successful TLSv1.0 handshakes, filter forboth successful and unsuccessful TLSv1.0 handshakes using the query

(tls_version eq TLS1.0).

Filter only for unsuccessful TLSv1.0 handshakes using thequery

(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)

.

Ifyou want to filter the logs for other TLS versions, simply replace

TLS1.0

or

TLS1.1

withanother TLS version.

Decide what action to take for sites that use weakTLS 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 Decryptionpolicy and Decryption profile that control the traffic. The Decryptionlog

Policy Name

column provides the policy nameand the Decryption policy shows the attached Decryption profile (

Options

tab).

If you need to access the site for business purposes, consider creatinga Decryption policy and Decryption profile that apply only to thatsite (or to that site and other similar sites) and block all othertraffic that uses less secure protocols.

Key Exchange

—Identify traffic that uses less secure keyexchange algorithms.

Start by checking the Application CommandCenter (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 majorityof the key exchanges use the secure ECDHE key exchange algorithm.However, some key exchange sessions use the less secure RSA algorithmand a few use another key algorithm. To begin investigating trafficthat uses RSA key exchanges, for example, click the number

325

to drilldown into the data.



The drill-downshows the applications that use RSA key exchanges. We can also clickthe

SNI

radio button to view the RSA key exchangesby SNI:



Armed withthis information, we can go to the logs to gain more context aboutRSA key exchange usage.

Go to the Decryption log (

Monitor

Logs

Decryption)

)and filter them for decryption sessions that use the RSA key exchangeusing the query

(tls_keyxchg eq RSA)

:



From the

PolicyName

column in the log, we see that the

NoDecrypt

Decryption policy controls most of the trafficthat uses RSA key exchanges and can infer that the firewall doesnot decrypt the traffic and allows it without inspection. Becausethe traffic isn’t decrypted, the firewall can’t identify the applicationand lists it as

ssl

. If you don’t want toallow traffic that uses RSA key exchanges, modify the Decryptionprofile attached to the Decryption policy that controls the traffic.

Youcan add to the query to further filter the results for a particularSNI or application that you saw in the ACC or in the first Decryptionlog query.

Decide what action to take for traffic that uses lesssecure key exchange algorithms.

Block access to sites that use less secure key exchangeprotocols unless you need to access them for business purposes.For those sites, consider creating a Decryption policy and Decryptionprofile that apply only to that site (or to that site and othersimilar sites) and block all other traffic that uses less secure keyexchange algorithms.

Use the Decryption logs to identify sessions that usesolder, less secure authentication algorithms.

Filter the Decryption log to identify older, less secureauthentication algorithms.

For example, to identify all sessions that use the SHA1algorithm, use the query

(tls_auth eq SHA)

:



You can add to the queryto further drill down into the results. For example, you can adda particular SNI, a key exchange version (such as filtering forSHA1 sessions that also use RSA key exchanges), a TLS version, orany other metric found in a Decryption log column.

Use the Decryption logs to identify sessions that usea particular encryption algorithm.

For example, to identify all sessions that use the AES-128-CBCencryption algorithm, use the query

(tls_enc eq AES_128_CBC)

:



You canadd to the query to further drill down into the results.

Examplesof 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 createqueries to investigate negotiated ECC curves and any other informationyou find in the Decryption log.

{{ } else { }}