Last updated at Thu, 03 Dec 2020 19:25:36 GMT
Weak SSL/TLS encryption. Why worry?
Think back to a time when the clock highlighted June 30, 2018—an important deadline for online security and network administrators. It was the date from which older versions of TLS and all SSL should be confined to history for PCI-compliant networks. From that date onward, 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 compliance 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, including your own networks, partner network, or client networks that interact with your infrastructure. GDPR regulations (article 31) require use of state-of-the-art technical and organizational 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 the 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 1990s, 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:
- Some weaknesses are in the protocol implementation itself, such as Heartbleed, which exploited a read buffer overflow in OpenSSL’s implementation of the heartbeat extension. This allowed attacking clients to read private key information from the server.
- 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 one 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 the new version of TLS to enable use of stronger ciphers.
- Weakness in the protocol itself
Even if properly implemented, according to the spec, with good ciphers, TLS1.1 is still vulnerable. The pseudorandom function (PRF) 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 weaknesses, 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 that you have access to scan the network. The PCI Security Standards Council emphasizes the importance of ensuring adherence to standards at all times—not just once per year to close audit requirements.
Continuous adherence is just good business and security practice, and it 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.
