Date: Sat, 19 Dec 2009 02:31:24 -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: <4633ce386bdc08fa31018598b2457bda.HRCIM@webmail.1command.com> In-Reply-To: <20091219081605.GA23586@lava.net> References: <f196357e2f75a3f986ab0c4dd04a7697.HRCIM@webmail.1command.com> <20091219081605.GA23586@lava.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Greetings Clifton, and thank you for your reply. On Sat, December 19, 2009 12:16 am, Clifton Royston wrote: > On Fri, Dec 18, 2009 at 05:32:41PM -0800, 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: >> > ... > >> So, if I understand things correctly. The patch prevents >> (re)negotiation. Making the likelihood of a successful "handshake" >> near null (as the log messages above show). I'm sure that some may be quick to >> point the finger at the self-signed cert being more likely the cause, I should >> add that while in fact quite unlikely, I too didn't completely rule that out. >> So I purchased one from startssl - >> money wasted. The results were the same. So it would appear that until >> something else is done to overcome the hole in current openssl, my only >> recourse is to back the patch out, and rebuild openssl && all affected ports - >> no? > > You might want to check up on a security list to get a full > understanding of the issue, and indeed depending on your application and network > you may conclude that the best solution for your environment is to reverse out > the patch. > > However, it's unlikely that the patch will be removed from > circulation - most OSes and applications using TLS/SSL are undergoing a similar > experience - because the security problem it prevents is both genuine and, as I > understand it, an inherent design error in the protocol specification. If you > allow renegotiation during the session, you also allow a man-in-the-middle > attack to inject arbitrary data into the session. Depending on your app, the > likelihood of this could be anywhere from small to huge, and the impact could be > anywhere from negligible to disastrous. Indeed. I /do/ understand that the patch was an effort to thwart a potential "hole" in current openssl's implementation. I also took some time comparing the patch against the code's /former/ state. While the patch /does/ "plug" the hole. It also /nearly/ closes the intended entry point for it's intended target - the client initiating communication. As it is, it /won't/ permit communication as it was intended to. So it can't be used as a reliable protocol for secure communication. I fully realize that the hole needed to be plugged ASAP. But until the source has been "re-worked", it's of nearly no value. I discovered I'm not the only one w/o the ability to use SSL after the "patch". I spent quite some time trying to track down the reason communication shut down immediately after accepting the cert in my UA. Searching the web, and newsgroups indicates that /many/ others are w/o the ability to use SSL for their needs either - unless, reverting to a "pre-patchd" state. Given an extremely reliable DNS, and well secured network, the only immediate solution seems to be to check out the pre-2009-12-03 source, and re-build it, and all affected. Then, of course monitor openssl for a "new improved" version. So as to be able to lift a HOLD on the back-patched version in my current tree. Thank you again Clifton, for taking the time to respond. --Chris H > > -- Clifton > > > -- > Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net > President - I and I Computing * http://www.iandicomputing.com/ > Custom programming, network design, systems and network consulting services > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4633ce386bdc08fa31018598b2457bda.HRCIM>