Thoughts on the TLS bug
So our old friend SSL has been broken again. I’ve had a little more time to chew on this than most, and a few thoughts have occurred to me.
Firstly, let’s talk about its implications for HTTP.
Assuming all the conditions are right (and we’ll get back to that) at best it allows an attacker to inject an arbitrary request into an SSL-protected stream. It does not allow you to decrypt data, it does not allow you to read any information back, it does not allow you to inject into the returning stream of data.
Here’s the thing – I can already do that. Watch:
<html>
<body onload="document.pwned.submit()">
<form method="post" name="pwned" action="http://www.arbitrary.com/some/path/here">
<input type="hidden" name="parameter1" value="value1">
<input type="hidden" name="parameter2" value="value2">
</form> </body> </html>
(This works so well that when I first previewed this post I ended up at a 404 on /some/path/here from arbitrary.com…)
Hey look! I can make you submit an arbitrary POST request to any location on the internet! No SSL / TLS trickery needed, just click on my link. Your browser will automatically fill in the cookie (meaning that the request will be authenticated) and you’ll submit the nastiness for me. It’s called Cross-Site Request Forgery, it’s been around for a long time, and it’s well-known and well-defended against by anyone who knows about such things (the key is to use a nonce in the original form – google is your friend).
It’s not a big deal for HTTP. The only ways to even trigger it require any of:
1: A client certificate being actively used (at the choice of the user)
2: An odd per-directory configuration of SSL/TLS cipersuites (a problem for shared hosting, sure, otherwise what I would regard as broken behaviour from IIS)
3: Other uncommon but possible circumstances.
It’s not a big deal for the majority of HTTP users, and there’s probably going to be good workarounds for it all in the coming days (expect some creative solutions – I plan to follow along if only to learn more about the internals of SSL).
Here’s the problem. SSL stands for “Secure Sockets Layer”, while TLS stands for “Transport Layer Security”. These protocols are designed to offer a layer of security – a universal “comfort blanket” to anyone who cares to implement them, something they can trust to do all the security heavy-lifting so they don’t have to. It’s a reasonable approach, and SSL / TLS is a good choice for doing so if it’s properly implemented.
The problem is that it’s not always properly implemented, and neither are the protocols that it protects. We may not have too much of a problem for HTTP, sure, but what do you think about SQL? An attacker who has the ability to inject a single arbitrary-length request into a stream of SQL queries and responses would be *devastating*. How about the thousands of different software update mechanisms out there that depend on SSL being secure in order to function? This is a protocol-level breach, one that requires a modification to the way that SSL & TLS function in order to repair. In other words, your implementation of SSL can be *completely* compliant with the protocol, *completely* immune to code-level vulnerabilities, *completely* fine at managing its keys, and using ciphers that are *completely* unbroken, and you are *still* vulnerable.
This is one of those bugs that will be biting us in the ass for a long time to come. Expect to see tools that exploit this weakness across a wide variety of protocols (what could you do with IMAP/S or POP3/S?) and a wide variety of devices, a hurried fix that isn’t-quite-thought-through by a lot of folks (and will have lots of implementation problems even if the protocol itself is secure), and some huge and far-reaching implications for the security of a whole lotta systems.
Just like Null-prefix certificates.
Just like DNS flaws.
Just like BGP.
Anyone who says this isn’t a problem simply doesn’t get it. It’s not a huge problem for HTTP (although I’m prepared to be proven wrong on that one, mail me if you have a PoC) and there will no doubt be some widening of the scope of this flaw once more eyeballs see it, but there’s a whole lot more than HTTP that gets protected by SSL.
Fun.