SSL appears to be broken in 8-STABLE/RELEASE

[Chris H]

Hello Maxim, and thank you again for your reply.
On Sat, December 19, 2009 3:54 am, Maxim Dounin wrote:
> 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>
>
>
> [...]
Indeed. I understand that. In fact my OP (original post) indicated my use was
in a "vhost" - eg;
NameVirtualHost host.ip.add.ress:443
<VirtualHost host.ip.add.ress:443>
SSLEnable
SSLVerifyClient (options 0-3;none work)
SSLRequireSSL
SSLNoV2
<IfModule apache_ssl.c>
SSLCACertificatePath /path/to/ca-file
SSLCertificateFile /path/to/cert-file
SSLCertificateKeyFile /path/to/key-file
</IfModule>
[...]
</VirtualHost>

Thank you again Maxim, for taking the time to respond.

--Chris H
>
>
> Maxim Dounin
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
>
>