Date: Sat, 19 Dec 2009 14:54:24 +0300 From: Maxim Dounin <mdounin@mdounin.ru> To: Chris H <chris#@1command.com> Cc: freebsd-stable@freebsd.org Subject: Re: SSL appears to be broken in 8-STABLE/RELEASE Message-ID: <20091219115424.GI43547@mdounin.ru> In-Reply-To: <c92b2b73348fd5c7cd4d2c1f1d027515.HRCIM@webmail.1command.com> References: <f196357e2f75a3f986ab0c4dd04a7697.HRCIM@webmail.1command.com> <20091219101408.GG43547@mdounin.ru> <c92b2b73348fd5c7cd4d2c1f1d027515.HRCIM@webmail.1command.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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:
<VirtualHost _default_:443>
...
<Location /test/>
SSLVerifyClient required
</Location>
</VirtualHost>
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:
<VirtualHost _default_:443>
...
SSLVerifyClient required
</VirtualHost>
[...]
Maxim Dounin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091219115424.GI43547>