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? Did you successfully transmit email
mesages with "DES-CBC3-SHA" as the only client-side cipher-suite?
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.
> 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.
> 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.
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. Such retries happen only for "sufficiently old" messages,
so unless your queue is congested the first delivery will be
deferred, and the fallback to cleartext will happen on the second
delivery attempt. If an upgrade to the Postfix 2.12-20140406
snapshot is an option, that should solve the problem without tweaks.
20140209
Workaround: the Postfix SMTP client now also falls back to
plaintext when TLS fails after the TLS protocol handshake.
Files: smtp/smtp.h, smtp/smtp_connect.c, smtp/smtp_trouble.c.
20140218
Workaround: require that a queue file is older than
$minimal_backoff_time, before falling back from failed TLS
to plaintext (both during or after the TLS handshake).
Viktor Dukhovni. Files: smtp/smtp.h, smtp/smtp.c,
smtp/lmtp_params.c, smtp/smtp_params.c.
20140223
Workaround: when a session breaks after the TLS handshake,
do not fall back from TLS to plaintext when all recipients
were deferred or rejected during the TLS phase. Files:
smtp/smtp.h, smtp/smtp_rcpt.c.
--
Viktor.
