Links

Wietse Venema has a nice analysis showing how an attack on Postfix doesn’t work. The core point here is that in turn-based protocols the common implementation is such that the server (or client – let’s call it an agent) will consume input from the OpenSSL layer character by character, in effect. This means that OpenSSL in turn will only consume a single SSL packet at a time, in order to provide input to the agent. The agent will then send output before reading further input. That output will be encrypted to the man-in-the-middle, because the OpenSSL layer has not yet processed the packets with the renegotiation in them. The victim will be unable to read the output, so the attacker has no option but to consume it. This means the attacker can execute arbitrary commands before handing over to the victim, but he can only hijack the very first command the victim sends – by sending an incomplete command himself, followed by the renegotiation. This makes it hard to kid the victim into doing anything interesting before something goes awry with the protocol and one end or the other gives up.

This defence only works if the application layer does not greedily consume from the OpenSSL layer – if you read everything OpenSSL has got, then the renegotiate will occur before you start sending responses.

Wietse thinks this means that Postfix can’t be attacked in any interesting way. My experience of making such claims has been unfortunate, so I’ll reserve judgement. My advice is still to upgrade to 0.9.8l if you can (or whatever fix your vendor is offering for this issue). If you need 0.9.8m in a hurry because you need renegotiation and can update both ends, let me know.

However, I rather suspect (but definitely don’t know) this will save many turn-based protocols from severe attacks, though I’m prepared to bet there are interesting corner cases.

Incidentally, Adam Langley pointed out to me that if protocols had included a sentinel character – i.e. a character that could only ever appear at the start of a command, then some attacks against HTTP would fail, and also even the hijacking of the victim’s first command would not be possible in SMTP, though arbitrary prefixing would work, still. Simply numbering the commands sent would fix that, though – and defeat some injection attacks (not that these are currently possible in SSL). These kinds of measures would be interesting defences in depth for future protocols. Keeping a running hash sounds like a better idea to me, though.

Share This

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.

Share This

A lot can happen in a day. Yesterday the news broke that SSL was compromised. We immediately (OK, it took about 10 hours) released a new version of OpenSSL, 0.9.8l, which mitigates the problem by completely disabling renegotiation. Obviously this will break some sites, and so is not a full fix, so the next step is to implement Eric Rescorla’s TLS extension. However, before I get on with that, it seems I have a few questions to answer.

Firstly, I must thank the anonymous poster who said “OpenSSL is written by monkeys”. But dude, you should’ve included the link. I’ve been meaning to link to that for ages. Well, days.

Secondly, as Marsh said, there is a better answer for people who need renegotiation. This is the extension mentioned above. It won’t work unless clients also implement that, but we are working on that, too (and clearly any client that uses OpenSSL will get it for free as soon as I get the next version out).

To the bloke who asked about ISA and OWA: I have no idea what either of those are.

Does this affect SGC (Server-Gated Cryptography)? I don’t actually know. I think it does, because I think SGC uses renegotiation, but I am not sure. If anyone knows, comment!

To the “but this is just XSRF” (Cross-site request forgery) guy:

• XSRF does not give the attacker control over headers.
• Your attack didn’t work on me: I didn’t click the link.
• HTTP is not the only protocol that uses SSL.

Though the fact that this attack doesn’t actually make HTTP much worse is a pretty damning indictment of HTTP (and HTML)!

Will this patch break session resumption? No – and nor will the 0.9.8l release, which does the same thing more elaborately and correctly.

Finally, even once we’ve implement the extension it seems to me this is not really the true fix – really applications should be aware of renegotiations and not carry trust across their boundaries. But more on that later, I’ve got code to write.

Share This

For the last 6 weeks or so, a bunch of us have been working on a really serious issue in SSL. In short, a man-in-the-middle can use SSL renegotiation to inject an arbitrary prefix into any SSL session, undetected by either end.

To make matters even worse, through a piece of (in retrospect) incredibly bad design, HTTP servers will, under some circumstances, replay that arbitrary prefix in a new authentication context. For example, this is what happens if you configure Apache to require client certificates for one directory but not another. Once it emerges that your request is for a protected directory, a renegotiation will occur to obtain the appropriate client certificate, and then the original request (i.e. the stuff from the bad guy) gets replayed as if it had been authenticated by the client certificate. But it hasn’t.

Not that the picture is all rosy even when client certificates are not involved. Consider the attacker sending an HTTP request of his choosing, ending with the unterminated line “X-Swallow-This: “. That header will then swallow the real request sent by the real user, and will cause any headers from the real user (including, say, authentication cookies) to be appended to the evil request.

It’s obviously going to take a little while for the world to patch this – and since the news is spreading like wildfire I’ve put up a patch to OpenSSL that bans all renegotiation. I’m sure an official release will follow very shortly.

Note that the patch is against the head of the OpenSSL 0.9.8 development tree (that is, it is against 0.9.8l-dev). You may have to do a little work to patch against other versions. And if you intend to deploy this patch permanently, please change at least the textual version of the version number, which you can find in crypto/opensslv.h. Also note that if you need renegotiation for your site to work, I have no solution for you, other than you redesign your site. Sorry.

Share This