Date: Fri, 18 Dec 2009 22:16:06 -1000 From: Clifton Royston <cliftonr@lava.net> To: Chris H <chris#@1command.com> Cc: freebsd-stable@freebsd.org Subject: Re: SSL appears to be broken in 8-STABLE/RELEASE Message-ID: <20091219081605.GA23586@lava.net> 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
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.
-- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091219081605.GA23586>