Date: Sat, 19 Dec 2009 08:33:14 +0000 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: Chris H <chris#@1command.com> Cc: freebsd-stable@freebsd.org Subject: Re: SSL appears to be broken in 8-STABLE/RELEASE Message-ID: <4B2C8FCA.9000105@infracaninophile.co.uk> In-Reply-To: <f196357e2f75a3f986ab0c4dd04a7697.HRCIM@webmail.1command.com> References: <f196357e2f75a3f986ab0c4dd04a7697.HRCIM@webmail.1command.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] 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 [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkssj88ACgkQ8Mjk52CukIwfCwCeIWTQxuxOFOK9yE92ttwNifJO 4ukAn3zBpsJogDrFLD+anNHatkco4T3V =FomH -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B2C8FCA.9000105>