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:

<body onload="document.pwned.submit()">
<form method="post" name="pwned" action="">
<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…)

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.


Be Sociable, Share!

9 Responses to Thoughts on the TLS bug

  1. dispensa says:

    You’re definitely right about non-HTTP implications. As for HTTP – first, the client often can’t choose whether or not to use a client certificate (e.g. SOAP) – if he doesn’t, he simply can’t play. Also, you might have forgotten the client-initiated case. Either way, this is a problem for HTTP but it’s not Armageddon.

  2. marshray says:

    Hi Chris,

    I remember staying up too late watching a video of your Shmoocon RFID presentation. That is awesome stuff!

    I think your comparison with XSRF is very apt, as there are a lot of similarities. Remember however, that XSRF bugs are pretty darn serious bugs and a lot of work has been done to close those holes down (same origin policy and whatnot). This TLS problem in a sense un-does most of that. It can bypass same-origin because the attacker can change the client’s GET to a POST.

    Re: “The only ways to even trigger it require any of”, those are the cases we wrote up for the paper, and we and the industry continue to learn more. For example, the first version of the paper speculated on the possibility of a client (i.e. MITM)-initiated renegotiation being accepted by the server. It seems that there are many HTTPS servers that accept it, and many which do not.

    Client-cert auth may seem to be an obscure deployment scenario, but it seems to be used in places where security is most important. E.g. smart card systems. If MitM can take your smart card credentials to any server on the net that will accept them and use them to authorize his arbitrary request, that’s a big problem.

    Re: “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)” You may be right on that, but I hope not, and probably only time will tell. I hope to get the word out early though that I think we did get the right people in a room together and I think we did come up with the right fix, and I expect the Internet Draft doc to hit the public IETF process tomorrow. Some evidence that it probably doesn’t totally suck (as far as protocol fixes go anyway) is that several people came up with the same idea more or less independently after getting a real understanding of the issue. Since then, it’s had a few weeks of scrutiny and I’m not aware of any shortcomings being pointed out.

    Of course, all patches could always use more testing, and that goes 10x for protocol changes. At the end of the day we weren’t able to give the vendors as much time as any of us had wanted, but we (as security researchers) think we gave the industry the best possible chance to succeed.

    So I’d like to see the proposed fix get a fair shake, since I think it represents the best way to get the whole net patched quickly.

    - Marsh

  3. Chris says:


    Thanks for the info, and good job on finding a very subtle bug. I’ve been comparing it to the bug that forced SSLv2 to become SSLv3, I’m looking forward to reading the RFC that fixes this.

    You’re right that XSRF bugs are very serious, but they’re also very easy to mitigate. This bug doesn’t directly reveal credentials (phew) but what worries me is how this is going to be widened once more eyeballs see it, and how many deployments think they’re extra-secure because they’ve enabled protections like client certificates and per-directory ciphering requirements. It’s one of those open-ended bugs that worry me in that I’ll never believe we’ve seen the last of it.

    You’ll certainly have my peer review when the draft is posted; do you know when any of the patches are planned?


  4. Frank.Heidt says:

    Hey Chris,

    Thanks for taking the time to allow me to brief you on this today. You were clearly one of the few folks that instantly got it and that, in of itself was, really quite refreshing.

    Many of the folks I had to explain this too quickly got lost in the mechanics of the bug or went off on wild tangents of possible but unlikely scenarios.

    Having said that.

    I think that most if not all of the protocols currently protected via STARTTLS extensions are likely to remain safe. A careful reading of the hundreds (literally) of RFC’s on this topic shows some consistency of thought around channel binding and state clearance that should, (should mind you) protect us.

    This is really quite a win! Your concerns about “(what could you do with IMAP/S or POP3/S?)]…” are probably not as bad as they could be. I’m not calling them baseless, they deserve examination, however only experimentation will prove that for sure. Right now, as far as Leviathan’s research shows, there are no credibility attacks against the two protocols you mentioned. Again, however, only time will tell.

    “RFC2595 – Using TLS with IMAP, POP3 and ACAP

    ” A TLS negotiation begins immediately after the CRLF at the end of
    the tagged OK response from the server. Once a client issues a
    STARTTLS command, it MUST NOT issue further commands until a
    server response is seen and the TLS negotiation is complete.

    The STARTTLS command is only valid in non-authenticated state.
    The server remains in non-authenticated state, even if client
    credentials are supplied during the TLS negotiation. The SASL
    [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS
    client credentials are successfully exchanged, but servers
    supporting the STARTTLS command are not required to support the
    EXTERNAL mechanism.

    Once TLS has been started, the client MUST discard cached
    information about server capabilities and SHOULD re-issue the
    CAPABILITY command. This is necessary to protect against
    man-in-the-middle attacks which alter the capabilities list prior
    to STARTTLS. The server MAY advertise different capabilities
    after STARTTLS.

    Read more:

  5. samhooker says:

    SSL VPNs? Serious impact, or not?

  6. moxie__ says:

    Hey Chris, you’re really equating this to BGP hijacking and DNS cache poisoning? As an attacker, those vulnerabilities leave me with some very immediate ideas about how I can leverage attacks on an entire network. When I first saw this, however, all I thought was “wow, that’s a really fragile and complicated way to do CSRF.”

    So I agree with you that this is not very useful in the context of HTTP, but all of the examples that were provided in the disclosure were portrayed in the context of HTTP, and they all seem to suggest that the sky is falling. Personally, I don’t find that kind of disclosure very helpful. So yes, if anywhere, it’s likely that this might actually be more useful in the context of other protocols, but my feeling is that the reason most of the discussion on this has been limited to HTTP is because that’s where particular configuration issues actually make this “exploitable.” How many other protocols do you know of that accept a request, then decide to ask for authentication through their transport layer, then act on the request that they received before the authentication was complete?

    They might exist, but they’re edge cases. That’s what this vulnerability is, a very nice edge case. Clever, yes, but not the same as a whole-scale network-wide attack like DNS cache poisoning.

    Finally, I’ll say that it’s a little difficult to respond to this post because of the way that you’ve employed tautology here. By saying that “anyone who doesn’t think this is huge doesn’t get it,” you’ve automatically cut off any discussion, because to question your assessment immediately pegs you as someone who “doesn’t get it.”

    So the best I can do is say: “Anyone who thinks this is huge REALLY doesn’t get it.” There. =)

  7. Chris says:


    It’s great to hear that you’ve done a lot of research into this; it’s reassuring that a pass over the relevant RFCs hasn’t thrown up any major warning flags. I’m more concerned about the non-RFC’ed protocols that use SSL; it’s pretty common to see a layer of SSL added to proprietary protocols in order to hide the underlying flaws. It’ll be interesting to see where this flaw gets realised, for sure.


    That thought had occurred to me. I’d love to hear if anyone has done any testing.


    You’re right that there’s a difference of scale between this auth gap and the other flaws I mention, and that this flaw does not immediately present an exploitable vector without significant work on the part of the attacker. That said, when it does present an exploitable circumstance it would likely be quite severe. That’s why I made the statement about not getting it – this bug is a lot more subtle than just client-certificates or bizarre IIS configurations, and anyone who dismisses it based on the rarity of that vector hasn’t seen the wider implications. I’m not saying it’s huge but people certainly should not dismiss it out of hand – there’s some significant potential for harm here.

    You’re also right that anyone who thinks the sky is falling also doesn’t get it – that’s simply not the case, but people do need to take it seriously until they’ve quantified the effect that it will have in *their* environments. The sky isn’t falling but it’s certainly cracked; I’m expecting to see some creative applications of this flaw in the coming weeks.


  8. moxie__ says:

    Chris, I think that’s a totally fair assessment. This is potentially interesting, and we should think about it carefully, but I’d personally like to wait until we can assess whatever creative applications might emerge before equating this to DNS or BGP attacks.

    Right now, all I see is the PR company that PhoneFactor has hired literally blackening the skies with press releases that are borderline-false. Maybe I should realize how my bread is buttered and get on-point here with the hyperbole, but I just can’t help but feel like we’re taking ourselves too seriously.

  9. macewan says:

    Your example brings back memories of interesting times in 1998. Fourty years old now and do not angry as quickly. Certainly would not perform the crazy shit we did those days.