Share
Is your organization still using old SSL/TLS protocols? June 2018 was the deadline for hardening SSL/TLS protocols and implementing a more secure encryption protocol.
The PCI Security Standards Council requires all payment processors and merchants to move to TLS 1.2 and above. Organizations that don’t follow this standard do not meet PCI DSS. It is 2019 already and many organizations still are not complying with PCI DSS.
PCI-DSS requirement 2.2 hardening standards
This blog post will cover:
- What are TLS and SSL?
- TLS / SSL vulnerabilities and common attacks
- Mitigating TLS and SSL vulnerabilities
- Why TLS and SSL are still in use?
- What might break when hardening TLS and SSL?
- How to avoid outages when hardening TLS and SSL?
Understanding TLS & SSL: Fundamental Security Protocols
Transfer Layer Security (TLS) is a cryptographic protocol designed to provide secure communication between web browsers and servers. It is used in almost every app nowadays. Many IP-based protocols such as HTTPS, SMTP, POP3 and FTP support TLS. Secure Sockets Layer (SSL), on the other hand, is a protocol used to establish an encrypted link between web browsers and servers. It uses symmetric cryptography to encrypt the data transmitted. Encryption keys are based on shared secret negotiation at the beginning of any communication session. This secret negotiation is referred to as the TLS handshake.
Old, but still common TLS versions are the TLS 1.0, launched in 1999, and its update, TLS 1.1, which was launched in 2006. While both versions were recommended to be disabled a while ago, according to a Panorays research, 97% of organizations are still using them, instead of their updated versions.
While TLS 1.2 and TLS 1.3 are current and more secure, many organizations still inadvertently support TLS 1.0 and the obsolete TLS 1.1 due to compatibility requirements or oversight.
Vulnerabilities and Common Attacks: MITM, CBC Mode & More
Various MITM attacks exploit the vulnerabilities in these protocols.
TLS/SSL had suffered from numerous malware attacks that exploited its vulnerabilities. Examples include:
- In late 2011, Browser Exploit against SSL/TLS (BEAST) was first revealed. The BEAST attack takes advantage of weaknesses in cipher block changing (CBC) by using a man-in-the-middle attack. A BEAST attacker silently decrypts and obtains authentication tokens, allowing them to access data passing between the web server and the browser.
- Padding Oracle on Downgraded Legacy Encryption (POODLE), published in October 2014, exploits SSL v3.0’s vulnerability by also performing a man-in-the-middle attack. The attacker encrypts the traffic and mimics the server until the user agrees to downgrade the connection to the vulnerable SSL v3.0. Once the connection is established in the vulnerable SSL version, the POODLE attack takes advantage of the CBC vulnerability.
- Compressing Ratio Info-leak Made East (CRIME) exploits the vulnerability in TLS compression. TLS compression method in the ClientHello message is only optional, meaning that the connection can be established without any compression. The main purpose of compression is to reduce bandwidth usage while preserving integrity and security when exchanging large amounts of information. CRIME captures the SeverHello message (in response to the ClientHello), and disables the compression option. The attacker can then take advantage of the compromised traffic.
- TLS heartbeat extension is also a known vulnerability in old TLS versions. The heartbeat function is used to ensure that a connection between two parties continues, as long as they are still there. Heartbeat request is performed when the user sends a heartbeat message and the size of the data to the server. The server then responds with the same heartbeat request, sending data and its size. Heartbeat vulnerability is reflected when a client sends false data length, and the server then responds with the same data received from the user in addition to some random data from its memory, to meet the data size announced by the user, even though his data didn’t meet his own statements.
MITIGATING RISKS: WHAT CAN BE DONE TO PROTECT SENSITIVE DATA?
The proper way to address those vulnerabilities is to harden TLS v1.0, TLS v1.1, SSL v2.0 & SSL v3.0 by disabling them.
In order to disable TLS v1.0 & 1.1, you need to create an Enabled entry in TLS 1.0 or TLS 1.1 subkeys (depending on the protocol you want to disable). This entry does not exist in the registry by default. After you have created the entry, change the DWORD value to 0. In order to enable the protocol, change the DWORD to 1. The same can be done to SSL 2.0 and SSL 3.0.
Why are those protocols still here?
Newer, more resilient TLS protocols have already been released. TLS 1.2 and 1.3 were released in late 2008 and 2018 respectively. So, how come so many companies still insist on relying on breached protocol versions such as the 1.0 and 1.1? Well, apparently this is because TLS/SSL usage is so extended, changing configurations could cause extensive damage. Changing configurations on enterprises’ server demand the support of all the services to the new version. For example, web browsers that don’t comply with the new configuration basically force organizations that need the connection to those browsers to stay exposed. Another issue is the lack of awareness of the vulnerability or full awareness, but lack of regulations. In the absence of regulation to make them implement the changes, organizations might decide to avoid the mess of hardening SSL/TLS, thus leaving their infrastructure exposed to breaches.
In October 2018, Apple, Google, Microsoft & Mozilla (responsible for Chrome, Edge, IE, Firefox, and Safari browsers) announced that by the first half of 2020, TLS 1.0 & 1.1 will be disabled by them. This fact will hopefully force companies to finally deal with the hardening of the SSL/TLS task.
What might break when hardening SSL/TLS protocols?
Since SSL/TLS protocols support a wide variety of services as well as other protocols, you should take bear in mind that disabling it will probably force you to find solutions for services that depend on it. In particular, client-side applications and public-facing web servers that have not been configured to accommodate newer TLS versions might experience disruption.
Here are a few examples of things that might break when hardening TLS/SSL protocols:
- Public-facing websites using HTTPS
- Remote desktop services
- Anywhere Access RDP connection
- Office 365 integration
- Server 2008 R2, IIS 7.5 – when disabling both SSLv3 and TLS 1.0
IT forums and communities contain many more examples of damages that can be caused by hardening SSL/TLS. Eventually, many organizations prefer to remain vulnerable than to take the risk that although tests will be performed, things will still continue breaking.
How to avoid outages when hardening TLS & SSL?
CalCom’s software learning ability is capable of producing an accurate report regarding hardening SSL/TLS protocols’ consequences, so you won’t find out about it only when it breaks. It will also present the status of each server and whether it is hardened according to best practices recommendations or not. When finally deciding your course of action, CHS will automatically enforce your decision on the production environment. Learn more about it.
