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 > > > _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
