On Tue, Oct 22, 2013 at 03:19:41AM +0200, li...@rhsoft.net wrote:
> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1019390#c3
> >
> > The author of comment #4 is not getting it. The problem is NOT
> > that Postfix fails to negotiate EECDH, rather the problem is that
> > it does! Once EECDH is negotiated, the server (gmx) selects an
> > unsupported (by RedHat's crippled OpenSSL) curve and the handshake
> > fails.
>
> this guy did the abusive change too :-(
Not knowing how TLS works in real life, should disqualify one from
meddling with TLS implementations. From the bug report:
---
Reading RFC 4492 (https://tools.ietf.org/html/rfc4492#section-4),
there is either a bug in the server or the client isn't offering
the extension advertising the curves it supports.
---
* 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).
* 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.
* Auto-configuration of the server curve (in response to client
extensions) is coming in OpenSSL 1.0.2 which is not yet released!
---
You need to get the protocol message trace in order to determine
which. If it's client-side, the bug is (probably) against
Postfix. If you want openssl to support more curves, you should
file a new bug.
---
Postfix just calls SSL_connect() after configuring the protocol mask
and cipherlist. It has little influence over the SSL HELLO extension
processing (with DANE in 2.10 it may request SNI).
The RedHat OpenSSL EC implementation with most of the curves missing
is worse than no EC. I don't care whether a new bug report is
filed or not, but they need to fix the mess.
--
Viktor.
