On Tue, Oct 22, 2013 at 06:07:49AM +0000, Viktor Dukhovni wrote:
Follow-up, comments after a brief email discussion with Paul Wouters
of RedHat:
> * Firstly, client TLS extensions are not possible when the client starts
> with an SSLv2 compatible SSL HELLO. So the list of supported curves
> is not sent by clients that are backwards compatible with SSLv2 (though
> of course by now SSLv2 should be disabled in most clients).
This is still an issue, but nobody should enable SSLv2, so perhaps
breakage when you do is tolerable. RedHat could disable client-side
ECDH ciphers for SSL connections for which SSLv2 is enabled.
> * Secondly, the OpenSSL server API does not expose the client's
> supported EC curves to the server application which is expected
> to configure the EECDH curve. Thus the extension from RFC 4492
> is almost never used, most servers choose the EECDH curve blindly.
While OpenSSL does not currently allow the server's choice of curve
to adjust to client capabilities, it does in fact check whether
the server's curve is on the client's list, and if not, the OpenSSL
server code with disable ECDH cipher-suites.
The problem turns out to be that RedHat's patch did not prune the
list of curves advertised by the TLS client! They're going to
update the code to only advertise secp{256,384}r1, which will make
connections to gmx.de work again (but without EECDH).
--
Viktor.
