Cloud Hosting

Weak encryption is a real risk to data privacy and security. This article, based on Packet Detectives episode The case of the unknown TLS versions, shows how you can use packet capture (via Endace) and Wireshark to discover the outdated & vulnerable devices that exist on your network

Updates to TLS have significantly strengthened data privacy over the Internet with the introduction of perfect forward secrecy and stronger crypto ciphers in TLS 1.2 and TLS 1.3. Stronger cyphers, which are almost impossible to crack using modern computers, protects the privacy of sensitive data as it traverses the Internet.

Weak cyphers can leave sensitive transactions exposed to brute force attacks and man-in-the-middle (MitM) attacks. For example, your login credentials, password, or sensitive data that displays in your web browser may be exposed if a cybercriminal decrypts a TLS session can be decrypted. Its for this reason that the industry is rapidly moving to deprecate TLS 1.0 and 1.1.

Back in 2018, Google, Microsoft, Apple and Mozilla announced that their browsers will remove support for these outdated versions of TLS. Many cloud services, such as Office 365, have pledged to do the same.

To reduce the threat of these attacks and the consequences that accompany them, its essential that all of your devices, servers and applications are using the most recent versions of TLS (TLS 1.2 or later). But how can you tell what version of TLS encryption is being used? And how can you ensure that all of your connected devices and endpoints arent using outdated versions of the TLS protocol? Well walk you through the process of collecting network packet data using Endace and Wireshark.

Lets hash it out.

Its important to ensure recent versions of TLS are being used by all devices, servers and applications in the enterprise to reduce these threats. August 2020 data from SSL Labs shows that 65.5% of sites support TLS 1.2, whereas 32.8% support TLS 1.3. This data is based on the 150,000 most popular sites in the world (according to Alexas list).

But what decides which version of TLS the client and server use to communication? The version of TLS thats used to encrypt data is defined through a negotiation between the server and client where a handshake agrees on the strongest encryption that both can handle.

Hashed Out has broken down the TLS handshake process before. However, heres a visual overview of how that process works and the communications that take place between the client and the server as a quick reminder.

Every device that uses SSL/TLS including applications, networking elements, servers, IoT devices and endpoints must be updated with the latest software and/or OS that supports TLS 1.2 or greater. Furthermore, each device must be configured to deny connection requests at TLS 1.1 and lower.

Manage Digital Certificates like a Boss

14 Certificate Management Best Practices to keep your organization running, secure and fully-compliant.

Thats because outdated and legacy devices become the weakest link for security and data privacy. Needless to say, tracking down all the devices in your enterprise and updating them can be a daunting task especially when just about every device connects to Wi-Fi and has a web interface!

Some firewalls can detect and block traffic by TLS version, so one solution is to block older TLS traffic in your network. However, blocking older versions of TLS without certain knowledge of who or what is using them can lead to nasty (and unintended) surprises.

Updating web browsers may not be enough to remove older TLS traffic. Many endpoints on the network use TLS including servers, software agents and IoT devices and all of these can also be outdated. Another approach is to observe what is happening on the network and identify where older TLS traffic is originating. Outdated TLS agents can then be identified and, if needed, updated or replaced before blocking traffic.

Server logs, event logs and monitoring systems dont necessarily track the TLS version, so an EndaceProbe is used to capture the TLS version negotiations. Packet capture gives a true and accurate picture of all network activity so nothing is missed or altered, and its hard to argue with (should that become necessary). The downside is without good methodology, a huge amount of data (thats difficult to use) can be collected and thats a lot of noise to sort through. But with the right steps, this process is easily managed.

First, create a filter on the EndaceProbe (for example, Port443) in a Wireshark-compatible syntax to capture Port 443 traffic. Set the filter to ignore any other traffic that you dont need.

Using smart truncation in addition to filtering will reduce the data volume even further by truncating data packets and leaving TLS handshake negotiations intact. This reduces the size of the capture file, which is easier to store and manage.

Apply the Port443 filter to a data pipe on the EndaceProbe and let that capture for a full day to get a typical traffic sample. Port 443 is strictly for HTTPS traffic.

You are now ready to analyze. You can get a quick overview, using the built-in investigation tool, where traffic on Port 443 is going. Microsoft One Drive traffic tops the list, which is not unexpected but take a look at that Tik Tok (musical.ly) traffic!

To get into more detail and look into the fields of the TLS Hello packets, youll need to use a tool like Wireshark. Limit the time window to work hours and extract the capture from the EndaceProbe. This results in a 48GB capture file.

You can further reduce the amount of data by applying a Wireshark read filter when opening the capture file. This limits what is read into tls.handshake.type packets with a type of 1 or 2 the handshake types for client and server Hellos and ignores items like certificate and key exchanges. This reduces the number of packets loaded into Wireshark from more than 5 million to about 42,000.

You can save time in Wireshark by using a profile. These examples use a Wireshark profile that has been created to filter by TLS version on the client or server. You can download this Wireshark profile from the Endace website.

During the handshake, the server will only go to the highest TLS version that the client supports. This means that a good starting point is to examine the Client Hellos first. If you look at the packet detail of a Client Hello packet, you can see the TLS version and maximum version capabilities of that client.

The capture shows the actual TLS version in use and the clients using it. Many things can influence the TLS version used. For example, a web browser requesting an older TLS version may be due to a cookie from the last conversation, or maybe a non-browser software agent or device is in use.

If outdated clients are found, there may be much work yet to be done, but at least you now know with some certainty where the problem areas are.

The server makes the final determination of which TLS version is used by selecting the highest version that both client and server support. You can list servers using Wiresharks statistics and endpoints, and then apply Limit to display using the filter, so only those servers using TLS 1.1 or older are listed. This will allow you to further narrow down on the specific traffic youre targeting.

At this stage, you can export a list of servers from Wireshark (in CSV or YAML format) that might need updates. By switching your filters and endpoints, you can identify other areas that may need attention. The best case is to get everything up to TLS version 1.3. However, there is some urgency to eliminate the use of TLS versions below 1.2 (and the vulnerabilities that accompany them).

Applying Wireshark with a sound methodology and filtering gives an effective and efficient way to analyze TLS use in your network. When combined with untamperable packet capture, you can build a detailed, complete and certain picture of what is going on in your network that enables change without guess work. As a result, you can start addressing TLS issues where they originate, before blocking activity at the network level.

By identifying the weakest links in your network, you get on with eliminating them, without any unpleasant surprises and without managing irate users complaints.

This article was co-written with Betty DuBois, Chief Detective for Packet Detectives, an application and network performance consulting and training firm based in Atlanta, GA. DuBois has been solving mysteries since 1997. Experienced with a range of hardware and software packet capture solutions, she captures the right data, in the right place, and at the right time to find the real culprit. Check out bettydubois.com to learn more or to contact her.

Read the rest here:
TLS Is Only as Strong as Its Weakest Link - Hashed Out by The SSL Store - Hashed Out by The SSL Store