From owner-freebsd-stable@FreeBSD.ORG Sat Dec 19 11:54:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E54C5106566B for ; Sat, 19 Dec 2009 11:54:26 +0000 (UTC) (envelope-from mdounin@mdounin.ru) Received: from mdounin.cust.ramtel.ru (mdounin.cust.ramtel.ru [81.19.69.81]) by mx1.freebsd.org (Postfix) with ESMTP id A29858FC19 for ; Sat, 19 Dec 2009 11:54:26 +0000 (UTC) Received: from mdounin.ru (mdounin.cust.ramtel.ru [81.19.69.81]) by mdounin.cust.ramtel.ru (Postfix) with ESMTP id 29E821702A; Sat, 19 Dec 2009 14:54:24 +0300 (MSK) Date: Sat, 19 Dec 2009 14:54:24 +0300 From: Maxim Dounin To: Chris H Message-ID: <20091219115424.GI43547@mdounin.ru> References: <20091219101408.GG43547@mdounin.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: SSL appears to be broken in 8-STABLE/RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 11:54:27 -0000 Hello! On Sat, Dec 19, 2009 at 03:18:21AM -0800, Chris H wrote: > Hello Maxim, and thank you for taking the time to reply. > On Sat, December 19, 2009 2:14 am, Maxim Dounin wrote: > > Hello! > > > > > > 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? > > > > If you are using Apache as server, you may consider using > > server-wide SSLVerifyClient (instead of per-location ones which require > > renegotiation). > Indeed. I tried that on an Apache server, but "no joy". :( > > SSLVerifyClient provides the following options: > 0 - Verify the client:no > 1 - Verify the client:optional > 2 - Verify the client:required > 3 - Verify the client:required - but CA is optional > > However, none of the options worked - even with the purchased cert. It doesn't matter what you specify in option. The thing that matters is where you specify option itself. The following won't work: ... SSLVerifyClient required as SSLVerifyClient in Location context requires renegotiation. But moving it to VirtualHost level should resolve the issue, as certificate exchange will happen in initial handshake. The following should work: ... SSLVerifyClient required [...] Maxim Dounin