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.

Generating an Audit Trail of Failed Access Attempts to Files or Folders

27 March 2018 GDPR,NetFort Blog By: Darragh Delaney

Why is it important to monitor for failed access attempts?

For some time now we have included a file activity monitoring feature in our LANGuardian product. It passively generates an audit trail of file and folder activity using network traffic as a data source. All you need to do is monitor network traffic going to and from your file servers and you can easily see who is doing what with your files and folders. The image below shows an output of a sample report.

network user accessing SMB file share

With the release of LANGuardian 14.4.1 we can now report on successful and failed access attempts to network file shares. The failed access attempts can be viewed in report format or they can also trigger alerts via email or SYSLOG.

For many compliance standards such as GDPR and CIS CSC 20 you also need to monitor for failed access attempts.  This is useful for generating alerts on anomalous activity where a user or device is attempting to access sensitive data. When it comes to GDPR and failed access attempts, this is what you need to focus on and how LANGuardian can help:

Requirement: Article 5 – Principles relating to the processing of personal data

1 (b) “Personal data shall be collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes; further processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes shall, in accordance with Article 89(1), not be considered to be incompatible with the initial purposes (‘purpose limitation’)”

How to comply


In most enterprises, personal data is collected and stored in a database or a file server. To ensure that the data is being processed only for the purpose it had been collected for, it is necessary to monitor accesses to these systems and to the personal data itself.

Enterprises should watch out for anomalous personal data access, modification, and deletion, which could result in the data being processed in a way that was not originally intended.

How LANGuardian can help

In the case of personal data stored on network file shares, LANGuardian can help enterprises generate a real-time and historical view of all activity to and from important file shares. This includes:

Content and location changes (created, modified, overwritten, moved, restored, renamed, and deleted files/folders). Active directory integration also allows you to see associated usernames.

Failed access attempts (file/folder read, write, or delete). This is useful for generating alerts on anomalous activity where a user or device is attempting to access sensitive data.

Requirement: Article 32 – Security of processing

1(b) “The ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services”

How to comply

Continuously monitor and audit the storage\file\database systems that store personal data as well as the services (or applications) that process personal data.

Watch out for failed access attempts and anomalies in user activities on these systems and services.

How LANGuardian can help

In the case of personal data stored on network file shares, LANGuardian can help enterprises generate a real-time and historical view of all activity to and from important file shares. This includes:

File access/change events with associated username and IP address

Audit trail of content and location changes (modified, overwritten, moved, restored, renamed, and deleted files/folders).

Audit trial of failed file/folder process or access attempts (file/folder read, write, or delete).

A closer look at the LANGuardian failed access reports

You can access the failed access activity via any of the LANGuardian file share reports which contain the actions report filter. Use the search bar at the top of LANGuardian and type in “Filenames by Actions“.

On the left hand side you should see an Action filter with a drop down selector. Scroll down and you will be able to select from a range of failed access attempts.

You can also focus on a specifc file or folder by ising the file name filter. Once you run the report you can save a custom report which will include your filter selection.

failed access attempts

The image below shows a sample output. Here can see some failed file open attempts originating from client Drilling down further will show the date and time that this event was triggered and you can also get associated usernames if you have configured the Active Directory integration.

A closer look at the LANGuardian failed access reports

Video Guide: Generating an Audit Trail of Failed Access Attempts to Files or Folders

You can download a 30 day trial of LANGuardian from here and use it to monitor, track file and folder activity 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 to and from your file servers.

Storm Emma, GDPR and the CIS CSC 20

GDPR Storm

It is back to work and school this week, following the most severe blizzard in years to hit Ireland, storm Emma (Emma, who decides the name?). The country was under the highest weather warning, a red alert, as the worst snow in 35 years swept north across the island. All shops were closed because of the weather and because they had no fresh meat, bread or milk left!  There seemed to be more talk regarding the lack of bread on shelves than the weather which is really unusual for the Irish. I saw some students walking home from the stores with cases of beer, pizza, beer, movies, no mortgage to pay, no worries, happy days, good for them!

Anyway, this storm has reminded me of another one that is on the way, and will also have a severe impact, the ‘GDPR’ storm.  GDPR is a hot topic for many people and organizations all over the world at the moment, not just across the EU but for also for ‘non-EU’ companies, even if they are not based in the EU. It is such an important market and as a result, they have EU ‘data’ and they are impacted.

It is such an important market and as a result, many organizations have EU ‘data’ and they are impacted. The port in this storm for many companies may be the CIS CSC 20.

Obviously, there is also a lot of hype and companies jumping on the bandwagon. Some of our customers have mentioned that they are sick of receiving sales calls from vendors, consultants, etc at this stage on the subject.

We in NetFort have been contacted by our customers, mostly our Irish and UK ones to date, asking us how we can help. ‘We have already purchased a LANGuardian, have been a good customer for years, we want to buy as few tools as possible, how can you help?’ Makes sense, most companies already have too many point security solutions and are trying to consolidate, NOT buy more.

We have also secured some new EU customers in central Europe. One for example, when asked why they purchased, came back with the following interesting information:

On our side, our GDPR” requirements are (so far):

  • Who is doing what on any shared file?
  • Who is sending or receiving a file on the Internet?
  • What is done on a database (SQL query is fine)?
  • What rights are given to some user?
  • What Admin are doing (reading CEO files or mail for example)?
  • What email is sent, to whom, with an attachment- for SMTP’
  • Some kind of IDS (have we been attacked) from either the internal network and the outside’

The image below shows a section from our CIS CSC 20 reports which we built using customer feedback like that shown above.

CIS CSC 20 Dashboard with reports

So we have taken the approach of firstly trying to work with and help our current customers and taking it from there.

Our LANGuardian  analyses raw network traffic or wire data, extracts application specific metadata and integrates with Active Directory to enrich the traffic metadata and add usernames. It enables visibility, drill down, context into both Internet and internal network user and device activity including shared Data (file shares and SQL databases)  Inventory, Users, and Applications.  The LANGuardian is ideal for continuous monitoring, troubleshooting, forensics and as result an ideal data source or tool to help demonstrate visibility, control, and compliance. It retains an audit trail of network activity very cost effectively for long periods but we needed to convince ourselves first of the compliance and GDPR usefulness, then discuss it with our customers and get their reaction.

Our or my first piece of learning was that GDPR is very vague, time-consuming and difficult to read and understand. I’m an engineer, I want hard facts, the detail I can read and believe in. I understand GDPR is still in its infancy but at the moment it is almost so vague it is frightening a lot of organizations and as a result, they are waiting to see what will happen. Risky approach.

From a security perspective, Article 32 specifically compels companies to look at existing best practices. For example, The UK’s National Cyber Security Centre “10 Steps to Cyber Security’ or ISO 27001 or the CIS CSC 20 Security Controls.  In our opinion, one very practical and detailed option is the CIS Critical Security Controls, originally the SANS Top 20.  Lot of good information here:

So we have studied them and tried to understand the detail. There is a lot of good practical information, readable which is critical but also realistic. GDPR aside, organizations should use these or an equivalent as guidelines, a good checklist. Recently I have met a number of our customers face to face and made a presentation on the CIS CSC 20 and how they can help. I wasn’t trying to sell to them, they are already customers. Just trying to have a discussion and get their reaction.

I was surprised to discover that about 50% of them to date had been studying the CIS CSC 20 and the current goal was to target the top 5 and be able to demonstrate compliance with these by May:

  1. CSC 1, Inventory of Authorized and Unauthorized Devices
  2. CSC 2, Inventory of Authorized and Unauthorized Software
  3. CSC 3, Secure Configurations for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers
  4. CSC 4, Continuous Vulnerability Assessment and Remediation
  5. CSC 5, Controlled Use of Administrative Privileges

Seems like a good approach to us, take it step by step, be realistic. Be able to demonstrate that you are trying, taking it seriously, doing your best to be compliant. The goal is not just a checklist, it is to improve security and AVOID a breach. Everybody wins.

So now we ARE on a mission, on the CIS CSC 20 bandwagon because they are a very good practical set of security guidelines and realistic for organizations of all sizes.  We are trying to leverage them and show how our LANGuardian internal visibility and continuous monitoring of network and user activity can try and help our customers.

We now have a GDPR and CIS CSC 20 tab on our LANGuardian system, access it directly here.

Stay tuned to this blog for more and more practical information and learnings.

John Brosnan

CEO, NetFort