The following blog post is meant to expand upon the findings commonly identified in BHIS reports. The “Server Supports Weak Transport Layer Security (SSL/TLS)” is almost universal across the breadth of our testing.

Why is this finding important?

This finding is important because attackers are ultimately interested in data. Use of a strong SSL/TLS configuration provides identification, authentication, confidentiality, and integrity services to the application or protocol that is using it. If weak protocols and ciphers are supported, then an attacker may be able to break the encrypted tunnel that exists between the client and server. After this occurs, the attacker might impersonate one of the communicating endpoints, slurp up unencrypted information, or modify that information in transit.

While attacking SSL/TLS might be difficult and time consuming, if it were impossible we wouldn’t have retired entire protocols like SSLv2, SSLv3, TLS 1.0 (by 30 June 2018 for PCI compliance). We also wouldn’t have had these over the years:

From Left to Right; Heartbleed, Drown, and SSL POODLE Vulnerability Logos

Given the time constraints placed on a penetration test and conflicts with other goals and outcomes of the test, it’s unlikely that we will have done anything more than confirmed the results of Nessus using an additional tool.

So why should you care?

You should care because the use of SSL/TLS is typically one of the only protections that keeps communication between a client and server (whether by a customer or employee) private. It also can provide authentication and integrity checking. Even the most trivial communication can include sensitive information or the ability to generate sensitive information as a side effect (like authentication hashes). As a result, it’s best to just keep your SSL/TLS configuration up to date by patching and disabling support for weak protocols and ciphers.

What should you do about it?

In a corporate Active Directory environment, making these changes can be simple. Active Directory Group Policy can be used to disable weak ciphers and protocols and to set the cipher preference across the breadth of your Windows computers (clients and servers). Obviously, implementing a change like this should be accomplished incrementally to ensure that client connection and SSL/TLS negotiation failures do not occur.

In addition to implementing the change in Group Policy, we also recommend that you change the settings in your default client image to ensure that devices cannot use insecure protocols or ciphers by default. Additional configuration may be necessary for specific Active Directory infrastructure systems to completely disable support for weak protocols and ciphers.

Similar automation capabilities can be found for Linux, Linux-like, and Unix devices using automation frameworks like Puppet. As with Windows systems, these changes should be integrated into the baseline procedures for these operating systems as well.

Don’t forget those mobile devices too.

The area where you are likely to have the slowest progress is with embedded systems (printers, storage devices, point of sale hardware, etc.), and vendor appliances. If you have a homogeneous print environment you might be in luck because some vendors support mass firmware upgrades for cases like this. However, a better strategy might be segmentation and access control lists (or firewalls) to prevent devices (and their communication) from being accessible to an attacker in the first place.

What constitutes “weak” and “strong”?

From a protocol perspective, your best bet is to disable support for anything short of TLS 1.2 if you can. With regard to cipher suites and general configuration options, the following post by Ivan Ristic from Qualys SSL Labs contains all of the details you could want: https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices

Conclusion

On most modern hosts, correction of SSL/TLS issues isn’t a monumental task. Care does have to be taken to ensure that service degradation is avoided on especially sensitive systems. You can also take alternative approaches for systems that you don’t have the time or resources to address as well. We haven’t identified an exhaustive list, but thinking about isolating those systems from the rest of “the herd” should get your creative juices flowing.

And if all else fails…you can just do this.

Ready to learn more?

Level up your skills with affordable classes from Antisyphon!

Pay-What-You-Can Training

Available live/virtual and on-demand

Finding: Server Supports Weak Transport Layer Security (SSL/TLS)