SSL appears to be broken in 8-STABLE/RELEASE

[Chris H]

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 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"
>
>