Re: Another Protocol Bites The Dust

[wolfoftheair]

(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 <iang@...> 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-security@...
> https://lists.mozilla.org/listinfo/dev-security
>

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[Victor Duchovni]

On Thu, Nov 05, 2009 at 11:00:42AM -0800, Kyle Hamilton wrote:

> (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.

This is not a general fix. One can't always "drop all data". If
renegotiation is allowed in the middle of data transfer, one cannot drop
all accumulated data. One may want to not apply any client credentials
gathered post renegotiation to data obtained before, but that does not
address all pertinent attacks.

> 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.

Are you sure your app is immune?

Can you describe your application protocol (once SSL is established what
is the client<->server message flow)?

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...