Am 21.10.2013 23:40, schrieb Viktor Dukhovni: > On Mon, Oct 21, 2013 at 11:17:25PM +0200, li...@rhsoft.net wrote: > >>> Instead of improving the world by finally supporting EC, they've >>> made things worse! Previously clients negotiated something other >>> than EECDH key exchange, now they negotiate it and fail! Sorry to >>> say so, but the RedHat engineers need adult supervision. >> >> since you sound very knowledgeable about SSL may you consider >> to make a comment there? >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1019251 > > I have enough fish to fry. The problem is obvious, client promises > EECDH support, server sends a standard curve name and the client > promptly fails because its list of supported curves is incomplete. > > Of course you should capture a session with wireshark and see what > curve the server sends back to confirm this obvious interpretation.
looking at the logs where ECDHE worked fine with the intermediate openssl and started to fail to "mx00.gmx.net" after the crippleded update i think the situation is clear >> fine: http://koji.fedoraproject.org/koji/buildinfo?buildID=471397 >> crippled: http://koji.fedoraproject.org/koji/buildinfo?buildID=471781 >> >> with the first build no single error > > I think you know what to do... maintain openssl at my own is above my scope i fear :-( well, i rebuild the package with "rpm --rebuild" but they strip parts out of the source-tarball and even in my situation building dovecot/postfix/httpd with complete own packages it leaves a bad taste of danger try to maintain a different openssl in context of other packages i hate it to ask but is there any change postfix avoids ECDHE for such destinations in case of this situation and continues to use DHE if the requested curve is not available in the linked openssl library? >> as far as i can see in all 8 cases currently to GMX >> >> Oct 21 22:29:22 mail postfix/smtp[12289]: SSL_connect error to >> mx00.gmx.net[213.165.67.99]:25: -1 > When I test connections to this host, I always get "AES256-SHA", > and no EDH or kEECDH ciphers are accepted. Did gmx.de change their > configuration to work around this? Can you build posttls-finger (from 2.11) > and test with: > > $ posttls-finger -t30 -T 180 -p TLSv1.2 -Ldebug \ > -o tls_medium_cipherlist='kEECDH:kEDH:kRSA' \ > "[213.165.67.99]" > > do you get handshake failures? no "posttls-finger" here but the logs below are a clear language i think Oct 21 20:16:43 Updated: 1:openssl-libs-1.0.1e-28.fc18.x86_64 Oct 21 19:08:27 mail postfix/smtp[13875]: Trusted TLS connection established to mx00.gmx.net[213.165.67.99]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Oct 21 19:36:37 mail postfix/smtp[15749]: Trusted TLS connection established to mx00.gmx.net[213.165.67.99]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Oct 21 19:59:48 mail postfix/smtp[17217]: Trusted TLS connection established to mx00.gmx.net[213.165.67.99]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) https://bugzilla.redhat.com/show_bug.cgi?id=1019390#c3
