ietf
[Top] [All Lists]

Re: IETF mail server and SSLv3

2016-02-05 09:45:40
On Fri, Feb 05, 2016 at 06:42:34AM -0800, Ned Freed wrote:

The implementation and documentation of this was joint work with
Wietse back in early 2006.  These days, when STARTTLS fails, Postfix
tries other MX hosts first and if they all fail, defers the mail
initially. Cleartext fallback kicks in on the second delivery
attempt if STARTTLS fails again.

Actually, I consider this approach as unacceptable unless the second delivery
attempt occurs within a minute or two. (Which, incidentally, is a much shorter
retry period after deferral than the standards recommend.)

The default is 5 minutes, with doubling exponential backoff up to
a cutoff of somewhat over an hour:

    $ postconf -d {min,max}imal_backoff_time
    minimal_backoff_time = 300s
    maximal_backoff_time = 4000s

(These, combined with per-destination concurrency limits to avoid
overwhelming remote systems that come back after a period of
downtime, and throttling of destinations when enough back-to-back
deliveries fail, do a better job of avoiding hammering remote
systems than the recommendations in the standards, while substantially
reducing delay when transmission fails on the first attempt).

I typically override these to min/max = 225s/7200s (this reduces
congestion delay if the queue happens to hold enough long-term
deferred mail, since with these settings the fraction that is active
at any given time is reduced by a factor of 2 or so).

As for "unacceptable", you might find the below fall into that
category:

  * IIRC Sendmail never falls back to cleartext if STARTTLS is
    advertised.

  * Microsoft's Schannel TLS stack at outlook.com and in Exchange
    by default solicits client certs it does not use and then rejects
    client connections that happen to present a certificate chain with
    an MD5 signature, even when it the self-signature of a root CA
    as with CAcert.org.

  * The ancient SChannel implementation in Exchange 2003 ignores all
    but the first 64 ciphers in the client's TLS hello, and has a
    broken DES3-CBC implementation that fails post-handshake with
    trailing garbage in the TLS response to EHLO that breaks the
    established TLS connection after "MAIL FROM".  Only RC4-SHA
    and RC4-MD5 work (but modern Schannel at outlook.com refuses
    to negotiate RC4).

    $ posttls-finger -o tls_medium_cipherlist=RC4-SHA -c -Ldebug microsoft.com
    posttls-finger: initializing the client-side TLS engine
    posttls-finger: setting up TLS connection to 
microsoft-com.mail.protection.outlook.com[207.46.163.138]:25
    posttls-finger: 
microsoft-com.mail.protection.outlook.com[207.46.163.138]:25: TLS cipher list 
"RC4-SHA:!aNULL"
    posttls-finger: SSL_connect:before/connect initialization
    posttls-finger: SSL_connect:SSLv2/v3 write client hello A
    posttls-finger: SSL_connect error to 
microsoft-com.mail.protection.outlook.com[207.46.163.138]:25: lost connection

  * DANE/DNSSEC at mail.mil and the many domains it is MX for is
    fubar'ed, because their firewall "protects" the DNS servers by
    blocking lookups for exotic records such as TLSA.

    $ dig -t tlsa +noall +comment +ans _25._tcp.pri-jeemsg.eemsg.mail.mil.
    ;; connection timed out; no servers could be reached

    $ dig -t a +noall +comment +ans _25._tcp.pri-jeemsg.eemsg.mail.mil.
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 14873
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

  * Despite being notified at the beginning of Aug 2015, isphuset.no
    still has has upgraded from a buggy PowerDNS version that
    botches TLSA record denial of existence for the domains of all
    their DNSSEC hosted customers.  [ In the example below, the
    name internot.no seems rather apt ]

    $ unbound-host -t tlsa -v _25._tcp.internot.no.
    _25._tcp.internot.no. has no TLSA record (BOGUS (security failure))
    validation failure <_25._tcp.internot.no. TLSA IN>: nodata proof failed 
from 195.35.82.103

As for a delay of < 5 minutes delivering email to such broken sites
it is, for most users, a reasonable trade-off to reduce needless
TLS fallback in the face of routine transmission glitches.

Though in the case of mail.mil, internot.no and the like, one has
to explicitly disable DANE support for those domains, since in
order to avoid downgrade attacks there is no fallback when TLSA
record lookups timeout or servfail.

-- 
        Viktor.