Am 23.10.2013 22:57, schrieb Viktor Dukhovni:
> 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:
thank you so much for that!
>> * 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.
understood
>> * 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.
understood
> 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)
sounds good and thank you again to point this out
so "we" can expect a fixed package soon and disable workarounds
in the meantime "smtp_tls_policy_maps" works like a charme
sooner or later i will have the whole postfix-documentatin in my configs :-)
/etc/postfix/tls_policy
gmx.de encrypt exclude=ECDH
gmx.at encrypt exclude=ECDH
gmx.net encrypt exclude=ECDH
gmx.com encrypt exclude=ECDH
