Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 10 Dec 2009 10:37:18 -0800
From:      Chris Palmer <chris@noncombatant.org>
To:        freebsd-security@freebsd.org
Subject:   Re: FreeBSD Security Advisory FreeBSD-SA-09:15.ssl
Message-ID:  <20091210183718.GA37642@noncombatant.org>
In-Reply-To: <86hbrylvyw.fsf@ds4.des.no>
References:  <4B20D86B.7080800@default.rs> <86my1rm4ic.fsf@ds4.des.no> <4B20E812.508@default.rs> <4B2101D8.7010201@obluda.cz> <86hbrylvyw.fsf@ds4.des.no>

next in thread | previous in thread | raw e-mail | index | archive | help
Dag-Erling Sm??rgrav writes:

> Do you use client-side certificates?

This is probably the original poster's problem. FreeBSD Security Advisory
FreeBSD-SA-09:15.ssl made clear that the patch fixes the protocol bug by
removing the broken feature (session renegotiation), but stated incorrectly
that session renegotiation is rarely used. In fact, client certificates work
using renegotiation as the underlying mechanism, and client cert auth is
pretty common. The advisory stated:

"""NOTE WELL: This update causes OpenSSL to reject any attempt to
renegotiate SSL / TLS session parameters.  As a result, connections in which
the other party attempts to renegotiate session parameters will break.  In
practice, however, session renegotiation is a rarely-used feature, so
disabling this functionality is unlikely to cause problems for most
systems."""

So, yeah, everybody: This patch breaks all your client cert-powered apps.
Probably the advisory should have mentioned that. :)

That's why we'll all be really happy when the new, fixed version of TLS
comes out and our TLS libraries all support the new version. Until then,
we'll have to either stop using client cert auth, or continue to use it with
some risk, or continue to use it while also employing flimsy mitigiation
methods like allowing only whitelisted client IPs to connect (increasing the
attacker's hassle somewhat, but not making attacks impossible). It might
also, or might not, help to require another form of auth from the client,
such as passwords or magic strings in the SOAP header or whatever.

Finally, the exploit scenarios I've heard of so far resemble cross-site
request forgery, in that the attacker can insert bad messages into an
otherwise good session. If you're protecting a web app with TLS client cert
auth, you'll need to audit that app for bugs like XSS and CSRF regardless of
this TLS problem. Depending on my mood, and please note I haven't had any
coffee yet, I might even say that this TLS problem is the least of the
average web application's woes (even though this TLS problem is not
insignificant).

Ok, coffee time.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091210183718.GA37642>