Date: Sat, 19 Dec 2009 02:47:17 -0800 (PST) From: "Chris H" <chris#@1command.com> To: freebsd-stable@freebsd.org Subject: Re: SSL appears to be broken in 8-STABLE/RELEASE Message-ID: <4ed595bc5648ccc655891c275dc2dba8.HRCIM@webmail.1command.com> In-Reply-To: <4B2C8FCA.9000105@infracaninophile.co.uk> References: <f196357e2f75a3f986ab0c4dd04a7697.HRCIM@webmail.1command.com> <4B2C8FCA.9000105@infracaninophile.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Greetings Matthew, and thank you very much for your reply. On Sat, December 19, 2009 12:33 am, Matthew Seaman wrote: > 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 WOW. I am /extremely/ grateful for your thoughtful, and very informative reply. All points well taken. Given an already well secured network. I'll opt for "door number 3" - back-patch openssl, and flag that section of the tree as HOLD. While closely monitoring openssl for the "new and improved" version. :) In all honesty, I'm quite impressed with openssl - that it took /so/ long for this "hole" to be found. Just wish a better "plug" could have been found during the interim. :) Thank you again Matthew, for taking the time to provide such an informative, and thoughtful response. --Chris H > > > -- > Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard > Flat 3 > PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate > Kent, CT11 9PW > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4ed595bc5648ccc655891c275dc2dba8.HRCIM>