(replying to a message on dev-security at mozilla, but since this affects OpenSSL more than Mozilla, I'm sending this one directly to openssl-users and bcc:ing dev-security. I hope the spam filter lets it through.)
When handled properly (i.e., you don't rely on anything before the renegotiation, except the single boolean fact that a renegotiation must occur), there's no problem. This is a problem with the HTTP/HTTPS protocol and mod_ssl/IIS, not TLS. The fix is obvious: once the renegotiation is finalized, drop all prior data and send the request again. That's the essence of this attack, and the fact that Ben Laurie seems to think that it's perfectly acceptable to disable all renegotiation in OpenSSL 0.9.8l (ell) (including 'anonymous negotiation followed by renegotiation to protect the X.509 certificates from passive eavesdroppers') suggests that he's more short-sighted than the protocol developers he's trying to cover up for. Thanks for destroying my non-HTTP app, Ben. -Kyle H On Thu, Nov 5, 2009 at 8:02 AM, Ian G <i...@iang.org> wrote: > > > -------- Original Message -------- > <http://www.links.org/?p=780> > > Links > > > Ben Laurie blathering > > > Another Protocol Bites The Dust > > 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 > This entry was posted on Thursday, November 5th, 2009 at 8:03 and is > filed under Crypto, Open Source, Security. You can follow any > responses to this entry through the RSS 2.0 feed. You can leave a > response, or trackback from your own site. > > > > _______________________________________________ > dev-security mailing list > dev-secur...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
