Transport Layer Security, or TLS, is a critical part of the internet. It allows a mechanism to secure and authenticate a connection between a host and a client. While generally considered an unbreakable security layer, TLS does have some vulnerabilities that are important for network professions to be aware of. These vulnerabilities can pose a real threat to network systems if they are not addressed. In this article, I would like to discuss how you can detect TLS vulnerabilities, as well as outline a few vulnerabilities that you should be looking for.
ROBOT is the latest in TLS vulnerabilities; it stands for Return Of Bleichenbacher’s Oracle Threat. It is the return of a 19-year-old vulnerability that allows both RSA decryption and the ability to sign operations with the private key of a TLS server. Back in 1998, Daniel Bleichenbacher discovered that error messages given by SSL servers relating to errors in the PKCS #1 1.5 padding would allow an adaptive-chosen ciphertext attack. Basically, when using RSA encryption, the attack breaks the confidentiality of TLS.
With this information in mind, we know that we can look for potentially vulnerable connections by looking for SSL/TLS ciphers that use RSA for encryption. In the example below, based on the cipher suites being used, I can see from our Gigamon exports that there are a number of connections to servers using RSA for encryption.
Because none of these connections are using elliptic curves for encryption, but instead are relying on RSA, they are vulnerable to ROBOT (view this article on cipher suites for more details).
Keep in mind that this vulnerability comes from the RSA implementation of 8 vendors (at the time of this writing), including F5, Citrix, Radware, Oracle (Java), and Cisco. You can view a more complete list of vendors that were affected by this vulnerability by visiting https://robotattack.org. The site also includes a tool to scan for the vulnerability.
POODLE is another vulnerability that you can easily detect on your network. It stands for Padding Oracle On Downgraded Legacy Encryption. This is a man-in-the-middle exploit that relies on internet and software clients’ fallback to SSL v3. As such, this vulnerability is found in SSL only, not TLS. Given that TLS 1.2 is accepted in all modern browsers, I recommend that all connections over HTTPS be upgraded to allow only TLS 1.2 (and TLS 1.3 if available).
Given that we know POODLE is only possible via SSL v3, we can search on our network for connections that use SSL v3 to see which connections are susceptible to POODLE attacks. If I modify my previous report for the SSL Version field to show only 3.0, I am given a list of all connections that were vulnerable to POODLE.
Here is one more TLS vulnerability that I’d like to discuss, and it too is something you can look for using network traffic analytics. BEAST stands for Browser Exploit Against SSL/TLS. This vulnerability affects SSL 3.0 and TLS 1.0. With BEAST, an attacker can decrypt data exchanged between two parties by taking advantage of a vulnerability of the Cipher Block Chaining implementation specific to the TLS 1.0 mode that allows them to perform a plaintext attack.
If I update my previous report to show TLS 1.0 instead of SSL 3.0 (although, SSL 3.0 is also vulnerable to BEAST), I can see a list of connections that could be vulnerable to this attack.
Keep in mind that BEAST requires that an attacker have control of the browser to be successful, so while it is important to look for this and other vulnerabilities, it is not likely to be a major issue compared with POODLE or ROBOT.
Now that you know how to detect TLS vulnerabilities using network traffic analytics from vendors like Gigamon, you are more prepared to protect your network from these vulnerabilities and can stop malicious activity before it starts. If you’d like to see what vulnerable protocols are being used on your network, download our trial of Scrutinizer today and see how network traffic analytics can help you detect TLS vulnerabilities.