Ben Laurie blathering

TLS Renegotiation Fix: Nearly There

Finally, after a lot of discussion, the IESG have approved the latest draft of the TLS renegotation fix. It is possible it’ll still change before an RFC number is assigned, but it seems unlikely to me.

But that doesn’t mean there isn’t plenty of work left to do. Now everyone has to implement it (in fact, many have already done so, including tracking the various changes as the I-D was updated), interop test with each other and roll out to clients and servers. And even then it isn’t over, since until clients are (mostly) universally updated, servers will have to allow old clients to connect and clients may have to be prepared to connect to old servers. In the case of a new server and an old client, it doesn’t hugely matter that the client has not been updated because it is defended by the server, which should not allow a renegotiation to occur if the client is old. However, in the case of an old server and a new client, or an old server and an old client, then there’s a problem – the client could be attacked. Obviously a new client can detect it is talking to an old server, and decline to play, but for some transitional period, it seems likely that clients will have to tolerate this, perhaps warning their user.

We could summarise the situation like this:

Old New
Server Old vulnerable vulnerable but client is aware, client should decline or at least warn
New not vulnerable if renegotiation is forbidden, client is unaware not vulnerable, everyone is aware


  1. Please don’t encourage the use of additional TLS/SSL warning messages being displayed to users. Doing so would only encourage users to ignore them even more than we do (actually, must) already.

    Comment by Toby — 8 Jan 2010 @ 15:14

  2. I think you can make a strong case for preventing new servers from talking to old clients (modulo the obvious interoperability trade-off). I know I originally recommended exactly what you say, but I’ve come to be convinced that it could still be bad for the server if an old client is unilaterally compromised.

    Consider a SAML-like case, where the client is bouncing a password off a server and the server is responding with “successfully authenticated” or “access denied”. If the MiTM negotiates directly with the client and injects a “success” message into the client’s receive buffer before triggering a renegotiation (with a Hello Request to the client), and the (new) server then comes on the line and sends its certificate to the client, the client will believe the MiTM’s (fake) success message because of the server’s cert.

    The attack hasn’t been reduced to practice (yet), but all it requires is a client that has a couple of characteristics:

    – TLS lib completes negotiation with any valid (but totally irrelevant) server cert
    – TLS lib automatically renegotiates when it receives a Hello Request
    – TLS lib doesn’t have a callback *during* negotiation to allow the app to verify the cert’s CN

    A valid cert with the wrong CN is still a valid cert from TLS’s perspective.

    Now, imagine the MiTM stuffing { Finished, “”, Hello Request } into a single TCP segment, for example. I’m leaving out a detail or two, but this is the gist.

    So, bottom line, the server does nothing wrong, but by providing his cert to an old client, he’s an unwitting accessory to the crime.

    Again, not saying this is a real attack, but there are enough sloppy implementations of TLS clients in the world that I’d be surprised if one couldn’t be found with this problem.

    More discussion on this topic on the IETF TLS list today.


    Comment by Steve Dispensa — 13 Jan 2010 @ 7:15

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress