This site uses cookies for anonymized analytics. For more information or to change your cookie settings, view our Cookie Policy.

How to detect weak SSL/TLS encryption on your network

SSL/TLS encryption

Weak SSL/TLS encryption. Why worry?

A Google search for “GDPR countdown clock” yielded 18,900 results for me this morning so probably the last thing we need to consider is another countdown clock, but here is one for PCI compliance anyway.

The clock highlights 30 June 2018,  an important deadline for online security and network Administrators; a date from which older versions of TLS and all SSL should be confined to history for PCI compliant networks. From 30 June 2018, to be compliant with PCI DSS 3.2, SSL and “early versions” of TLS protocol should be eliminated from use (with some exceptions for POS terminals). This is because PCI requires the use of “strong encryption” and known weakness in all SSL, some TLS versions and some cipher suites mean they fail the ‘strong encryption’ standard.

“Early TLS” is defined as anything before TLS 1.1; however TLS 1.1 is also vulnerable as it allows use of bad ciphers; so TLS 1.2 is a better choice. Along with this version change, the ciphers that are used by SSL/TLS need to be carefully managed too. The ciphers and the SSL/TLS protocol versions are separate, but not completely independent of each other.

Even if you don’t care about PCI compliance, this is important for all networks running SSL/TLS; that includes your own networks, partner or client networks, that interact with your infrastructure. GDPR regulations (article 31) require use of “state of the art” technical and organisational measures to ensure security. While the GDPR language lacks specifics, we can look to PCI 3.2 and NIST guidelines (800-52 Rev 1) which strongly recommend use of TLS1.2 only, to know that SSL, TLS1.0 and TLS1.1 are not state of the art, and so fail the GDPR test. The NIST draft for 800-52 Rev 2 explicitly prohibits use of TLS 1.1.

What’s the problem, SSL provides encryption doesn’t it?

Since the mid 1990’s, SSL/TLS encryption has underpinned much of online security and is the defacto choice for encrypting our web based online shopping and payment transactions. SSL/TLS keeps our transactions private and unaltered. However, researchers and attackers have identified and published weaknesses in the aging versions of the protocols, from SSL2.0, SSL3.0, TLS1.0 and TLS1.1. and in the ciphers that they use. There are three sources of weakness here to be aware of:

  1. Some weaknesses are in the protocol implementation itself, for example Heartbleed exploited a read buffer overflow in OpenSSL’s implementation of in the heartbeat extension. This allowed attacking clients to read private key information from the server.
  2. Other weaknesses are in the ciphers supported SSL/TLS. For example, increased computation along with the increased volumes of data being transferred, mean that 3DES cipher can be compromised in about 1 hour, using the Sweet 32 attacks. RC4 can also be compromised by brute force attacks. These weaker ciphers are supported by all versions of SSL/TLS up to version 1.2. However, newer. stronger ciphers such as AES are only supported by newer versions of SSL/TLS. So, use new version of TLS to enable use of stronger ciphers.
  3. Weakness in the protocol itself

Even if properly implemented, according to the spec, with good ciphers, TLS1.1 is still vulnerable. The PRF (pseudorandom function) is based on broken cryptographic hashes MD5 or SHA1 and its use of ciphers in CBC mode is insecure.

There are no available fixes for these weakness, so the only avenue to remain secure is to use the newer more robust versions.

TLS1.3, the newest, most secure version of TLS resolves the known weakness with the protocol, prohibits use of weak ciphers and has a much shorter setup time. TLS1.3 was in draft form when PCI 3.2 was adopted, so it isn’t mentioned in the PCI 3.2 document (TLS1.3 was formally adopted in March 2018. Mandating use of TLS1.3 at this stage could lead to interoperability problems).

Using Network Monitoring for SSL/TLS analysis

There are various techniques for identifying the SSL/TLS versions and ciphers that servers will support, such as nmap or just running Openssl from the command line. However, this requires that periodic checks are carried, the full inventory is always known, and you have access to scan the network. The PCI Security Standards Council emphasise the important of ensuring adherence to standards at all times and not just once per year to close audit requirements!

Continuous adherence is just good business and security practice and essentially points to continuous monitoring, rather than scheduled pen testing efforts. If you monitor network traffic within your network and perform packet analysis at session startup time, it’s possible to view the SSl/TLS versions and cipher used, as well as the certificates used on encrypted protocols (excluding TLS 1.3) .

You can do this without any access to the servers (i.e you can do it from the client or partner network) and without terminating any of the SSL/TLS sessions (i.e you don’t have to use man in the middle devices). This is possible as the opening salvos in SSL/TLS session establishment happen in the clear. The protocol negotiation, cipher choice and certificate exchange are all readable. Add to this the Server Name Indication (SNI) extension and a packet monitoring application can extract a lot of useful information about the nature of encrypted sessions on the network.

LANGuardian 14.4.1 includes features that are useful for monitoring the status of SSL/TLS on your network.

NetFort LANGuardian is deep-packet inspection software that monitors network and user activity passively via a SPAN\Mirror port or TAP. Here are a couple of use cases which cover how it can be used to detect the use of weak SSL/TLS encryption on your network.

The first is an inventory of SSL/TLS servers. Built from passive traffic analysis, this shows every SSL/TLS server, that has generated traffic on the network. The server can be internal or external (e.g a HTTPS website). The inventory report for each server shows some details of the server certificate, with expiry date and signature algorithm. It also shows the SSL/TLS protocol versions that the server has used to communicate with clients. Issues are highlighted in red, such as expired certificates or weak certificate signature algorithms, such as SHA1. A set of filters help identify conditions, such as use of SHA1 and help identify servers that need configuration or updates.

Filters for reporting on SSL/TLS Sever Inventory

Filters for reporting on SSL/TLS Sever Inventory

Report on a single SSL server, showing expired certificate, weak protocol used, weak SHA1 algorithm

Report on a single SSL server, showing expired certificate, weak protocol used, weak SHA1 algorithm

The other feature is a report on all the SSL/TLS sessions that have occurred on the network. This report (and its drilldowns), identifies all clients and servers that use SSL/TLS encryption, identifying the version of SSL/TLS used and the cipher that is used. Filters can be used to focus on versions of SSL/TLS, identify where SSL3.0 is used for example, or identify where any communication occurs that does not use TLS1.2.

Report showing use of weak SSL/TLS versions

Report showing use of weak SSL/TLS versions

Report drilldown showing cipher used by weak SSL3.0 session

Report drilldown showing cipher used by weak SSL3.0 session

A filter is also provided for the ciphers that are used. Ciphers suites have a specific naming scheme, which identity various attributes of the cipher used, viz:


For example, the cipher TLS_RSA_WITH_AES_128_CBC_SHA

is for use with TLS, using RSA for key exchange, AES 128 bit encryption, with SHA digests.

Report showing use of 3DES cipher

Report showing use of 3DES cipher

Filter support for SSL/TLS Versions and Ciphers

Filter support for SSL/TLS Versions and Ciphers

The list of supported ciphers for various versions of SSL/TLS is extensive (many hundreds) and there’s a balance between security and interoperability to consider when choosing which ciphers should be supported. Recommendations generally are to avoid RC4 and 3DES.

Continuous Network Monitoring is a useful tool for ensuring your network is operating to whatever standards or compliance regulations the you are required to adhere. Without using man in the middle decryption devices, it is possible to learn about the activity on your network.

Video Guide: How to detect weak SSL/TLS encryption on your network

You can download a 30 day trial of LANGuardian from here and use it to detect the use of weak SSL/TLS encryption on your network. You do not need any logs or client software. Just setup a SPAN or mirror port and you can passively monitor activity at your network edge and horizontal traffic moving within your network.