Before we hop in, it is worth mentioning a couple of things about TLS without getting too lost in the details. Behind the scenes, TLS uses a combination of symmetric and asymmetric encryption algorithms, as well as hashing algorithms to establish a secure connection and exchange data. The cipher suite specifies the algorithms that will be used for key exchange, authentication, encryption, and integrity verification.
The aim of TLS related attacks is to compromise the security of data sent over the network by exploiting vulnerabilities in the protocol or its implementation. The impact of these attacks can be severe, as they can result in data breaches, identity theft, financial losses, legal liabilities, and reputational damage for both users and organizations.
For brevity, we’ll be referring to TLS/SSL as simply just TLS for the most part and we’ll be speaking within the context of browser/server communications even though much of what is mentioned applies to other TLS-enabled applications.
Insufficient Encryption Key Lengths
Encryption key length is an important factor that affects the security of encrypted data. The key length is the number of bits within a key in a specific encryption algorithm. The longer the key length, the more possible values a key can have, and therefore the harder it is for an attacker to guess or brute force the correct key.
For example, a 40-bit key has 2^40 possible values, which is about 1 trillion. This may seem like a lot, but with modern computing power, it can be cracked in hours or days. On the other hand, a 256-bit key has 2^256 possible values, which is about 10^77. This is an astronomically large number that would take way too long to brute-force for most threat actors with conventional computing resources.
Therefore, choosing a sufficiently long key length is essential to protect data from unauthorized access or modification. Key lengths deemed sufficient by industry standards are not the same for each and every algorithm. Generally speaking, sufficient key lengths for asymmetric encryption algorithms tend to be longer than that of symmetric encryption algorithms. This is due to the use of 2 mathematically related keys in asymmetric encryption; one public and one private. The public key can be abused in factorisation attacks to derive the private key if the key length is too short. This is not true in symmetric encryption where there is one shared key that should only be known to the communicating parties.
However, key length alone is not enough to ensure encryption security. The encryption algorithm must also be secure and free of vulnerabilities or weaknesses that can be exploited by other methods than brute force.
Protocol Level Attacks
Protocol-level attacks are attacks that target the design or implementation of the TLS protocol itself. They aim to break the security guarantees of TLS, such as confidentiality, integrity, or authentication. Some examples of protocol-level attacks are:
- LUCKY13 (CVE-2013-0169)
- BREACH (CVE-2013-3587)
- SWEET32 (CVE-2016-2183)
- BEAST (CVE-2011-3389)
- POODLE (CVE-2014-3566)
What many protocol-level attacks have in common is that they are extremely difficult to exploit for several reasons. First, most of these vulnerabilities have a number of pre-requisites which are difficult to attain for most threat agents. The attacker must already be able to eavesdrop and/or be able to modify communications of their target over the network, often an almost impossible task. Moreover, these attacks are often associated with legacy versions of TLS/SSL which entails that the target’s browser or the servers they are communicating with are not updated or are misconfigured, something that is rarely seen in the real world. There are potentials for a downgrade attack to take place, but again in reality these are often easily protected against.
Another common factor of these attacks is that successful exploitation usually requires intercepting and analysing a large number of requests (sometimes hundreds of gigabytes) just to be able to reveal a small amount of data and often involves the ability to send specially crafted requests from the target’s browser using another vulnerability. In reality this could mean that an attacker with: appropriate access, tooling, computing resource and time could theoretically decrypt a small handful of bytes of completely meaningless data.
Practically speaking, it is only feasible for few threats to be able to exploit any of these vulnerabilities. This is especially true given that other application-level vulnerabilities tend to be more attractive to attackers given their relative ease of exploitation and larger impact.
Implementation Level Attacks
Not all TLS/SSL related vulnerabilities fall under the umbrella of the previous 2 categories. Sometimes a flaw in the tools that implement TLS are discovered. One good example is the infamous Heartbleed vulnerability that affects some versions of OpenSSL – a commonly used open source implementation of TLS. The vulnerability was introduced in OpenSSL version 1.0.1, which was released in March 2012 and affected versions up to 1.0.1f, which was released in January 2014.
The heartbleed vulnerability is caused by a flaw in the implementation of the OpenSSL “heartbeat” feature. The heartbeat feature is used to keep a connection between a client and server alive by sending periodic packets of data. Each heartbeat packet contains a payload and a length field that specifies the length of the payload. However, the vulnerability arises from the fact that the length field is not properly validated, which allows an attacker to specify a length that is greater than the actual length of the payload, causing the server to respond with a larger packet that includes data from its memory – potentially containing sensitive data.
As with all >10 year old security vulnerabilities, we would expect that the presence of this throughout environments is exceptionally limited. Although the impact of issues like this are high, the likelihood of these being present within modern environments is very rare.
All in all, it isn’t far-fetched to say that TLS related vulnerabilities won’t be hitting the headlines as often as other vulnerabilities. However, we still recommend applying the principle of defence-in-depth and we advise that servers are configured to not allow the use of vulnerable cipher suites unless there is a good reason to do otherwise. Usually by default, both servers and browsers allow for using legacy cipher suites for compatibility reasons, but this should be limited to reduce risk.
SSL should be removed throughout the environment and well configured TLS implementations should be put in place. Currently (2023) we recommend that TLSv1.2 at the very minimum is used to secure web based communications.
Finally, we of course recommend regularly reviewing the security posture of your web servers and applications through targeted web application pentesting and internal and external infrastructure pentesting.