Ben Laurie blathering

SSL MitM, Day 4

Are we having fun yet? First, thanks to Benson, the only person so far to have expressed any kind of appreciation for the work we volunteers do.

Now to Q&A.

  • Several people have pointed out that Adam Langley is unhappy that I (and others) have maligned TLS. Apparently

    …it’s not a flaw in TLS. The TLS security properties are exactly what was intended.

    Isn’t that wonderful? Notice how much more secure the world became now we’ve got that cleared up.

    Also notice how this “intended” property was so carefully explained, and how everyone involved immediately noticed that every single protocol that is layered on top of TLS got this wrong and had them fix it. Not.

    I’m not particularly interested in the blame game. I don’t really care who’s at fault here. What I care about is fixing the problems we have. TLS is broken. TLS is not broken. Whatever. I still seem to be patching code, either way.

    By the way, Adam is incorrect in supposing this is tied to client certificates – this seems to be a common confusion. Any TLS session can be hijacked, so long as the server allows renegotiation. Which pretty much anything based on OpenSSL does.

  • Many people seem to think that fixing this (or working around it, as in OpenSSL 0.9.8l) will break session resumption. I’m not sure where this comes from, but it won’t.
  • On a related note: can a resumed session be attacked? I don’t quite have the energy to test this, but I assume it can – although it would be a weird thing to do, I believe a client is allowed to resume a session during a renegotiation. So, to the server, this would look like the client connected, negotiated a new session, said some stuff, then renegotiated an old session and continued.
  • On why this isn’t the same as XSRF, when considering HTTPS – I forgot to mention that the attacker can use methods other than GET or POST, which is all you can do with XSRF.
  • Again on XSRF: those who think no clicks are necessary for XSRF are wrong – the victim must first follow a link to your evil page.
  • Is this really a MitM attack? Eric Rescorla correctly points out it is rather more limited than a classic MitM attack, but I don’t like his term either. When I first heard of it I called it a blind prefix injection attack. Which is still my preferred term.

So, what next? Eric Rescorla et al have proposed a TLS extension which, when implemented by both clients and servers, fixes this problem by cryptographically binding the two sessions (before and after renegotiation) together.

I have today committed code (mostly written by Eric Rescorla) implementing this extension to the OpenSSL tree, in the OpenSSL_0_9_8-stable branch. This is to allow review, of course, but also interop testing. An earlier version of this, which was based on 0.9.8l, was tested against a completely independent implementation by Nasko Oskov. Unfortunately we (the OpenSSL team) later decided that 0.9.8m should be based on the head of the 0.9.8 branch so that it would include various other bug and security fixes, so this version is not exactly the same as the one I tested with Nasko. I will be re-testing at the earliest opportunity.

Implementing and testing this fix has raised a problem, though. One of the nice features of the extension is that it is back compatible with old clients, so long as they don’t try to renegotiate. However, there is no corresponding mechanism for back compatibility with old servers. A client connecting to an old server has no way to know whether an attack occurred or not – only the server can detect that (it sees a renegotiation) – but since the server is old, it won’t know this is bad. I don’t have a solution to this problem at this time. Perhaps we shouldn’t try to solve it, and just require servers to upgrade.


  1. […] newly discovered SSL vulnerabilities and possible mitigation. Ben Laurie has excellent, technical blog postings about the SSL protocol […]

    Pingback by Data Security Podcast Episode 78, Nov 09 2009 « Data Security Podcast — 9 Nov 2009 @ 6:40

  2. So, while its not at the openSSL level, an web client could try:

    examine server-hello

    if server-hello contains renegotiation-info extension great

    if server-hello does not contain renegotiation-info extension

    try to renegotiate

    if renegotiation succeeds disconnect, or display security warning before proceeding

    if renegotiation refused, reconnect and dont try to renegotiate

    if renegotiation terminated abnormally (could be mitm deleting/corrupting packets) display warning, retry


    Comment by Adam Back — 9 Nov 2009 @ 13:25

  3. I appreciate all that you have done. Your posts have helped me quickly get up to speed on this issue.

    Comment by Randy — 9 Nov 2009 @ 15:12

  4. “those who think no clicks are necessary for XSRF are wrong – the victim must first follow a link to your evil page.”

    Well, this blind prefix injection attack requires MitM attacker. Assuming that such attacker is more likely to be closer to the victim (hence intercepting all traffic of one victim) rather than target web site (intercepting traffic to just one site but from all users), she can inject malicious links / JS to any non-HTTPS page visited by victim. No evil page visit required. Probably less likely if attacker is assumed to be close to the web site, but still doable if any non-HTTPS page request is intercepted. Just a 2c…

    Comment by Anonymous — 12 Nov 2009 @ 10:58

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress