On Tue, Oct 22, 2013 at 03:19:41AM +0200, li...@rhsoft.net wrote:
> > This is NOT progress. No support for EC is better than broken
> > support for EC. Either implement EC support or don't.
>
> yes, frustrating, but better start with something crippled and
> hope it improves than wait another 6 years.
I disagree. Shipping non-interoperable broken code that everyone
else is forced to work-around is not progress.
> > > also interesting, from one postfix to another using the same
> > > postfix/openssl builds exactly the same previously to GMX used
> > > ciphers are still fine - leaves the question open what exactly does
> > > "mx00.gmx.net" differently to fail now
> > >
> > > Oct 21 23:52:45 localhost postfix/smtp[27178]:
> > > Trusted TLS connection established to *****:25:
> > > TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> >
> > I don't understand what you mean, feel free to elaborate.
>
> My two postfix servers are using exactly the same ciphers as
> was used before the change with success to GMX, but maybe I
> am not knowledgeable enough to understand the deep details...
I can't connect to gmx's SMTP servers on port 25 from my laptop
since I am on a residential dynamic IP. On port 587 however, I
can definitely confirm that [smtp.gmx.de]:587 is using secp521r1,
which is one of the curves removed by RedHat. It seems likely
that they do the same on port 25.
If you have a server that negotiates EECDH with gmx.de, either your
OpenSSL runtime is not crippled, or they're using a different curve
on that server.
In wireshark, if you select the server Certificate packet for a fresh
(not resumed) session, it will contain multiple Handshake messages.
One of these will be the "Server Key Exchange" message, if you
click on its length field, wireshark will show the corresponding
3 bytes in the hex packet dump. Immediately after these, is the
actual payload, which for an ECDHE ciphersuite with a named curve
will start with "03" and then a 2-byte curve id. The ids of
interest are:
sect163k1 (0x0001), sect163r1 (0x0002), sect163r2 (0x0003),
sect193r1 (0x0004), sect193r2 (0x0005), sect233k1 (0x0006),
sect233r1 (0x0007), sect239k1 (0x0008), sect283k1 (0x0009),
sect283r1 (0x000a), sect409k1 (0x000b), sect409r1 (0x000c),
sect571k1 (0x000d), sect571r1 (0x000e), secp160k1 (0x000f),
secp160r1 (0x0010), secp160r2 (0x0011), secp192k1 (0x0012),
secp192r1 (0x0013), secp224k1 (0x0014), secp224r1 (0x0015),
secp256k1 (0x0016), secp256r1 (0x0017), secp384r1 (0x0018),
secp521r1 (0x0019)
The "strong" and "ultra" curves for Postfix SMTP servers default
to (and *really* should not at this time be changed from) secp256r1
(or 0x0017) and secp384r1 (or 0x0018) respectively. The wireshark
trace from gmx.de has a Server Key Exchange payload starting with:
03 00 19
so their PRISM knee-jerk response was to switch to secp521r1, thus
ensuring non-interoperability with RedHat's OpenSSL client software.
I don't believe gmx.de runs Postfix, so I can't accuse them of
failing to read the tls_eecdh_strong_curve and tls_eecdh_ultra_curve
parameter documentation. They're shooting themselves in the foot
without ignoring my advice. :-)
--
Viktor.
