-<| Quoting Viktor Dukhovni <postfix-users@postfix.org>, on Thursday, 2014-04-24 13:15:54 |>- > On Thu, Apr 24, 2014 at 09:24:39AM +0200, Philipp Gesang wrote: > > > The system was patched appropriately and capable of making 3DES > > connections. It did, however fail to accept connections without > > tweaking due to the multitude of additional cipher suites > > available in OpenSSL 1.0.1g. > > Were the patches in question for Exchange 2003 or for Microsoft's > Schannel SSL/TLS library?
According to the client the entire system was on the latest
patchlevel. I'm afraid I can't be more specific than that.
> Did you successfully transmit email
> mesages with "DES-CBC3-SHA" as the only client-side cipher-suite?
We observed the email successfully being relayed using that
cipher according to the maillog. Here's the line with the host
anonymized:
Untrusted TLS connection established to XXX.FOO.ORG[NNN.NNN.NNN.NNN]:25:
TLSv1 with cipher DES-CBC3-SHA (128/168 bits)
> Please describe in as much detail as you have available the problems
> observed on systems believed patched to correct implementations of
> 3DES-CBC in Exchange 2003.
>
> > tls_export_cipherlist =
> > ALL:RC4:+3DES:+DSS:+IDEA:+SEED:+PSK:+DES:+RC2:+aNULL:+ADH
>
> On OpenSSL 0.9.8 systems this may be poorly sorted. Better would be:
>
> ALL:@STRENGTH:+RC4:+3DES:+DSS:+IDEA:...
>
> With OpenSSL 1.0.0 the "ALL" cipherlist is better sorted out of
> the box, but I prefer to not rely on this too much.
We use OpenSSL 1.x but with 3DES keysize patched to 128 instead
of 168. Also most servers override the client preferences anyways
so "@STRENGTH" seems to be of limited value for outgoing connections.
> > Also while there definitely is a maximum index up to which Win
> > 2003 will recognize RC4 in the list of cipher suites, it appears
> > to be higher than 64: In our tests the server would prefer
> > RC4-SHA even with the first suite containing RC4 at index 65 and
> > RC4-SHA at 69; ("ALL:RC4:+SEED:+PSK:+DES:+RC2:+aNULL"). We did
> > not track down the exact limit.
>
> That's because the client *does not* in fact send every cipher
> suite to the server, some are dynamically excluded, e.g. PSK and
> SRP cipher suites when the client has not registered values or
> callbacks for the relevant shared secret. If you captured the
> traffic with wireshark, you'd observe that RC4 fails as soon as it
> is in the 65th slot on the wire. The limit is 64.
Thanks a lot for the explanation! The observed behavior is much
clearer to me now.
> > We would welcome suggestions for better workarounds.
> > Unfortunately we don't have access to the machine in question any
> > longer so we won't be able to run further tests against a live
> > system.
>
> Exchange 2003 is no longer supported by Microsoft. Windows server
> 2003 reaches end of support in July 2015. Upgrades of the laggard
> systems are long overdue.
Absolutely.
> Postfix 2.12 will by default retry in cleartext not only when the
> TLS handshake fails, but also when TLS deliveries fail in data
> transfer. [...]
Thanks for the details. I'll continue lobbying for a Postfix
upgrade :)
Best regards,
Philipp
pgpf9lHZHxJjX.pgp
Description: PGP signature
