Show Menu

TLS Myths Cheat Sheet (DRAFT) by [deleted]

Myths About TLS

This is a draft cheat sheet. It is a work in progress and is not finished yet.


Transport Layer Security is the most widely used approach for security on the intern­et—the majority of secure transa­ctions depend on it. But myths about TLS still abound.

1. TLS is broken

TLS is broken and can’t provide adequate protection against hackers.

Hearing about widely publicized security breaches, you would think that those designing security are incomp­etent. This is simply not the case. The truth is, there are no known hacks of TLS 1. Rather, these hackers were successful not due to faulty TLS, but because of a lack of softwa­re-­quality processes.

2. TLS 1.2 is perfect

TLS 1.2 is perfect and will always protect you.
This is never going to be true, but the main criticism facing TLS (and all attempts at security) is that it can be difficult to use safely in real-world enviro­nments. This has been demons­trated by the stream of security failures. However, as stated in Myth 1, these protocols can only be effective if they’re implem­ented properly, using proven softwa­re-­quality processes

3. TLS 1.3 will fix problems with TLS 1.2.

TLS 1.3 will fix problems with TLS 1.2.
TLS 1.3 is really an enhanc­ement of 1.2, reducing inform­ation leakage and cleaning things up rather than fixing TLS 1.2. While it may not fix all problems, the main things that TLS 1.3 enhances are security and connection speed. Security is improved both through the algorithms used as well as the TLS protocol exchanges, which give fewer attack vectors. The speed of TLS has also been improved by simpli­fying certain key protocol exchanges. Nothing was actually broken in TLS 1.2—it’s just a continuous struggle to keep TLS ahead of the bad guys and to improve the user experi­ence.

4. TLS & network security all about crypto­graphy.

TLS and network security are all about crypto­graphy.
Most recent network security failures have been caused by either the leak of key inform­ation by humans, badly written code, or poor integr­ation of the security layer. While some crypto­graphic algorithms have been weakened in lab condit­ions, practical attacks rarely exploit these weakne­sses.

5. Crypto­graphic algorithms can’t be broken.

5. Crypto­graphic algorithms can’t be broken
Using currently available computing power, this is probably true. However, computing power, partic­ularly that available to nation­-st­ates, is increasing rapidly and conseq­uently must be kept under observ­ation. Embedded developers first need to assess their risks. If you’re really concerned about being hacked by a nation­-state, then you need to take different measures than if you’re trying to protect your data from a company trying to extract competitor inform­ation. Many would argue that if a nation­-sate wants to hack you, you have bigger problems to address.

6. Compre­ssion makes encryption more secure.

Adding compre­ssion makes encryption more secure.
Surpri­singly, the opposite is the case. The reason is that compre­ssion reduces the size by keeping dictio­naries of common strings. Therefore, by injecting strings and checking the change in size, you can find out how much that data is used. That’s not an easy thing to process, but it’s a very useful attack vector for the determined hacker.

7, TLS properly implem­ented has no Leakage

7. Properly implem­ented TLS has no inform­ation leakage.
This isn’t true, and although desirable, “zero inform­ation leakage” was not a goal of TLS. The types of leakage that occur can include the size of messages being conveyed and the fact that a conver­sation between two people has occurred. Developers need to decide if these are real risks for their system and take additional measures as approp­riate. The use of VPNs, for example, can provide additional levels of security.

8. Web browsers mostly use state-­of-­the-art

8. Web browsers mostly now use state-­of-­the-art security.
State-­of-­the-art algorithms are available for most browsers, but they often negotiate down to older versions where required. Web browsers all fight for market share, so they want backwards compat­ibility with as many servers as possible. On the other hand, they all want to be very secure, so they have a difficult balance to strike. But as a matter of course, developers should all use the latest versions of TLS (1.2 and/or 1.3) and not allow this to be negotiated down. All modern browsers support at least TLS 1.2

9. Side-c­hannel attacks are common­place.

Side-c­hannel attacks are common­place.
Side-c­hannel attacks have been used to break crypto­-al­gor­ithms. To execute them, though, you normally need to be physically local to your target and have the ability to execute millions of test cases without anyone noticing. At best, it’s useful for targeting a single specified target

10. TLS will never be broken.

TLS will never be broken.
This seems unlikely. But since both computing power and the imagin­ation of hackers continues to rise, it’s possible that a point will be reached where trying to break TLS isn’t worth it. This seems unlikely. Rather, it seems inevitable that breaches of TLS will occur and improv­ements will be required.

11. Security is a perfected art.

11. Security is a perfected art.
The expect­ation that there’s a foolproof solution to security is naive. Most high-p­rofile security breaches have come from three main sources: insiders divulging secrets, poor system manage­ment, and badly or inappr­opr­iately written software. The first two sources can only be dealt with by the organi­zations respon­sible for the security of the inform­ation. Clearly, there are no easy solutions where humans are involved.