Re: SSL appears to be broken in 8-STABLE/RELEASE

[Matthew Seaman]

Chris H wrote:

Greetings,
 A recent (cvs checkout of src/ports on 2009-12-09) install of 8 seems to 
indicate
that changes in SSL have made it virtually unusable. I've spent the past 3 days
attempting to (re)create an SSL enabled virtual host that serves web based 
access
to local mail. Since it's local, I'm using self-signed certs following a scheme
that
has always worked flawlessly for the past 9 yrs. However, now having installed 
8,
it isn't working. The browser(s) throw "ssl_error_handshake_failure_alert"
(ff-3.56).
Other gecko based, and non-gecko based UA's throw similar, as well as openssl's
s_client. After immense research, the only thing I can find that might best 
explain
it is a recent SA patch applied to FreeBSD's src (SA-09:15). After reading what 
the
patch provides. I am able to better understand the error messages thrown to
/var/messages when attempting to negotiate a secure session in a UA:

Your analysis is correct.  You've hit the exact problem used as the test case
in all the investigations into the SSL injection attach mitigated in SA-09:15.

actions), the SSL site requires the user side to authenticate itself by 
presenting
a certificate.  This authentication process entails renegotiating the whole 
client
-> server SSL connection, and that is precisely what was diked out of
openssl-0.9.6m as it is the route to exploiting the security flaw.

There is an update to the SSL protocol in the works that will properly close the

 https://datatracker.ietf.org/idtracker/draft-ietf-tls-renegotiation/

This has taken what seems like a veritable age for the IETF to process, but in
reality it is moving with all dispatch to get the fix in place.

So, at the moment, we have a band-aid that fixes the vulnerability, but that 
breaks
some sites.  In the future we will have a correct fix that restores the 
desirable
functionality.  Between now and then, your site is going to have difficulties.

Options:

      * Just wait. Leave the site broken (but invulnerable to the attack) until
        the proper fix comes out.  I somehow doubt that this will be acceptable.

      * Temporarily (or permanently) switch to some other form of authentication

        and other chores.

      * Accept the risk of the SSL injection attack, downrev to openssl-0.8.6l
        and put in place whatever other mitigation you can think of to protect
        the site.  For instance, fire-walling off all access except to known
        good IP numbers.

To find out more about the attack, see Marsh Ray's blog at 
http://extendedsubset.com/
which has links to many useful resources.

        Cheers,

        Matthew

--
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                 Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
                                                 Kent, CT11 9PW

Essentially what happens is that your clients make an initial anonymous (on the client side) connection to the SSL site. Then (as a consequence perhaps of user vulnerability and still allow useful things like renegotiation -- see than using SSL client certificates. Likely to require significant re-engineering of your site, and probably quite a lot of user re-education

signature.asc
Description: OpenPGP digital signature