Raccoon 2 – Attacks on TLS Implementations

Truncation attacks show why it is important that both Alice and Bob have the same view of the cryptographic protocol they are executing. If Bob thinks they are both in state x but Alice thinks they are in state y, the security of the whole protocol may be compromised.

The danger of making assumptions about input data – in other words, data that might come from Eve or be manipulated by Mallory – is illustrated by Heartbleed. It is also yet more evidence that programming is inherently hard, and so extra effort must be invested in validating the implementations of cryptographic systems.

Along similar lines, Heartbleed shows that getting the specification right does not guarantee the security of an actual system. Right from the start, RFC 6520 correctly specified that if a TLS peer receives a Heartbeat message where payload˙length is too large, they must silently discard that message; however, that specification was not implemented accordingly.

Cloudbleed, once again, illustrates how sneaky bugs can be and that dormant bugs can exist in source code even if the implementation does not show any vulnerable behavior today. It also shows that software companies with professional developers on their payroll are susceptible to implementation-level security vulnerabilities in the same manner as open source projects with voluntary maintainers and contributors.

Moreover, Cloudbleed is a practical example of security problems caused by switching from one technology to another. On the positive side, it shows that having kill switches to immediately turn off a deployed feature is one of the best patterns for building secure systems.

Implementation bugs degrading the quality of random number generation highlight that entropy is fundamental and, at the same time, hard to test. While a collection of statistical tests might have uncovered the Debian bug, simple tests won’t work. Testing the remaining cryptographic functions, say, block cipher and hash function implementations, with known-answer-tests will not reveal missing entropy.

Insecure encryption invocation illustrates how the use of legacy protocols in conjunction with modern, secure protocols can undermine the system’s security. Raccoon is yet another example of how side channel leakage can be exploited to extract secrets.

Finally, there is a more general insight to be learned from the attacks described in this chapter: while they have nothing to do with cryptography, the financial damage caused by Heartbleed alone very likely exceeds that of all cryptanalytic attacks on TLS taken together.

It thus seems appropriate to close this chapter – and the book – with a quote by Niels Ferguson and Bruce Schneier [65]: Cryptography is fiendishly difficult. Even seasoned experts design systems that are broken a few years later. [At the same time, cryptography] is one of the easy parts of a security system. […] Cryptography is the easy part because there are people who know how to do a reasonably good job. […] The rest of the security system contains problems that we don’t know how to solve.