Date: Sat, 19 Dec 2009 03:18:21 -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: <c92b2b73348fd5c7cd4d2c1f1d027515.HRCIM@webmail.1command.com> In-Reply-To: <20091219101408.GG43547@mdounin.ru> References: <f196357e2f75a3f986ab0c4dd04a7697.HRCIM@webmail.1command.com> <20091219101408.GG43547@mdounin.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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. The problem appears (after examining the patch), is that it is not possible to be presented with the option to accept the cert, and /then/ continue with the session. As it is, you are permitted to initiate communication, but /any/ "decision making" may /only/ be made to determine a mutually acceptable crypt - eg; AES;DES;ETC... So Apache (or any other cryptographically aware server) using /current/ openssl, has no say in the matter - period. Thanks again Maxim, for your thoughtful reply. --Chris H > > Maxim Dounin > _______________________________________________ > 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?c92b2b73348fd5c7cd4d2c1f1d027515.HRCIM>