From owner-freebsd-security@FreeBSD.ORG Thu Dec 10 18:36:25 2009 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 249DA1065676 for ; Thu, 10 Dec 2009 18:36:25 +0000 (UTC) (envelope-from chris@noncombatant.org) Received: from strawberry.noncombatant.org (strawberry.noncombatant.org [64.142.6.126]) by mx1.freebsd.org (Postfix) with ESMTP id 04A4A8FC18 for ; Thu, 10 Dec 2009 18:36:24 +0000 (UTC) Received: by strawberry.noncombatant.org (Postfix, from userid 1001) id 29F127751DE; Thu, 10 Dec 2009 10:37:19 -0800 (PST) Date: Thu, 10 Dec 2009 10:37:18 -0800 From: Chris Palmer To: freebsd-security@freebsd.org Message-ID: <20091210183718.GA37642@noncombatant.org> References: <4B20D86B.7080800@default.rs> <86my1rm4ic.fsf@ds4.des.no> <4B20E812.508@default.rs> <4B2101D8.7010201@obluda.cz> <86hbrylvyw.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86hbrylvyw.fsf@ds4.des.no> User-Agent: Mutt/1.4.2.3i Subject: Re: FreeBSD Security Advisory FreeBSD-SA-09:15.ssl X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 18:36:25 -0000 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.