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.
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
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
vulnerability and still allow useful things like renegotiation -- see 

  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
         than using SSL client certificates.  Likely to require significant 
         re-engineering of your site, and probably quite a lot of user re-education
         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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091219/ffff60a0/signature.pgp