At work I recently have been irritated by a problem that was exposed with Apple's mail app, both on IOS and Yosemite. Among other things, I maintain an imap server (using dovecot ) for our office email.

First some background

Dovecot makes it easy to enable TLS, and disallow unencrypted logins. It actually uses openssl under the hood, so whatever cyphers your version of ssl supports are the set dovecot will support. By default, dovecot has TLSv1.0, TLSv1.1, and TLSv1.2 enabled by default. In the web-browser world, for about the last year, there have been known crypto-attacks against TLSv1.0 and some concern about TLSv1.1. Recommendations for server operators have been to completely disable TLSv1.0. For instance, Qualys has an awesome free ssltest that gives poor grades to 1.0 deployments.

More importantly, for my installation, the "Payment Card Industry" security standard - aka PCI - now strongly discourage the use of what they call "SSL/early TLS". See page 47 of this pdf. When you dig in to what this means, you find that SSLv2 and SSLv3 (which predate TLS) and TLSv1.0 are specifically what they are talkign about. These crypto standards are all pre-Y2K, and have been replaced by newer, better, more secure protocols. Technically my email system is completely isolated from my payment-related systems, and thus might get a pass during any PCI scan/audit. But, to save the hassle, and argument about "compensating controls" from 3rd party vendors who help validate our compliance, I recently disabled TLSv1.0 on dovecot.

In dovecot this is easy. In /etc/dovecot.conf.d/10-ssl.conf you add !TLSv1 to your ssl_protocols. Currently mine looks like this:

ssl_protocols = !SSLv2 !SSLv3 !TLSv1

Now the Real Problem

As soon as I did this every iphone in the company, and every mac user using the mail app on Yosemite all were unable to get their email. The IOS app gives a vauge error about not being able to "connect to the server" and the desktop app gives a 'timeout' error, and the mail connection doctor shows the connection appear to hang during setup.

It turns out that mail.app can only speak TLSv1.0. There is no support for 1.1 or 1.2. TLSv1.0 was first defined as a spec in 1999, 1.1 in 2006 and 1.2 in 2008. 8 years ago. Isn't it time for an update? I've found a few people complaining about this in Apple's support forums, but only recently has 1.0 been deprecated. I expect more people will feel the pain as time progresses.

To be fair to Apple, my 2 year old HTC One M7's mail app has the same issue - I'm told that versions 4.5 and later have TLSv1.2 support.

Testing Notes

While for https there are a few great free tools out there, for other tls-enabled protocols, it is much less fun. Openssl has a nice command line tool you can use for such things. Note that the version on Yosemite is old. Thus you'll need to make sure and test from a more recent version. I used the a linux server on the same network segment as my mail server.

Here is how I tested:

To make a simple connection test:

openssl s_client -connect servername:143 -startls imap

This will connect to "servername" on port 143 and initiate the imap version of starttls. You should get a response back that gives details of the cert and any certificate chain, a copy of the server certificate, some debugging info and a block that might look something like this:

    New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-GCM-SHA384
    Server public key is 2048 bit
    Secure Renegotiation IS supported
    Compression: NONE
    Expansion: NONE
    SSL-Session:
        Protocol  : TLSv1.2
        Cipher    : DHE-RSA-AES256-GCM-SHA384
        Session-ID: 03C689EDC9EC7F09BA904D44DAB8AB9E9CA835B4AED350E8147466FF62B211AF
        Session-ID-ctx:
        Master-Key: 5620257CDF5223C53F3A830B4078F78AAB40C2BDF2D3F41750879642E3C31A29A6BD8802CA8815B494141FBA76830C79
        Key-Arg   : None
        Krb5 Principal: None
        PSK identity: None
        PSK identity hint: None
        TLS session ticket lifetime hint: 300 (seconds)
        TLS session ticket:
        0000 - a4 dc 2e 63 45 fa 69 3c-06 13 23 43 67 09 a5 3c   ...cE.i<..#Cg..<
        0010 - fb e1 93 47 b8 17 95 f8-ee 84 cb 1d 89 c5 a3 a6   ...G............
        0020 - 8d 7e 20 94 f3 35 10 8d-de 55 eb 4b b2 64 9c 2b   .~ ..5...U.K.d.+
        0030 - 33 5a 5a 57 30 20 17 65-8f 20 43 7c 1d 32 ec fe   3ZZW0 .e. C|.2..
        0040 - 80 1c 1a d5 ae 17 97 13-78 b4 b1 01 43 43 27 1e   ........x...CC'.
        0050 - 9a 46 24 84 88 c7 37 9e-58 0e a7 b0 c0 a5 1f f8   .F$...7.X.......
        0060 - f4 90 3b 2c b8 00 65 55-51 8a 6d 36 0e 27 c1 5b   ..;,..eUQ.m6.'.[
        0070 - 03 c1 d9 25 a9 ae 2a 36-37 66 ad cf ea e4 72 b3   ...%..*67f....r.
        0080 - fb 9e 1b a7 6a 00 c3 96-b5 04 ea 0f f7 f9 5a 5f   ....j.........Z_
        0090 - ce d2 03 75 ec 6b 36 2c-01 94 ae 47 28 66 65 7d   ...u.k6,...G(fe}

        Start Time: 1441902734
        Timeout   : 300 (sec)
        Verify return code: 0 (ok)
    ---
    . OK Capability completed.

At this point, if you know the imap protocol you can start typing commands.... For my purposes, seing . OK was enough to know that I had connected.

If you want to see if a specific version of tls is supported you can specify on the command line which version of tls to use:

    openssl s_client -connect servername:143 -starttls imap -tls1

    ....
    SSL-Session:
        Protocol  : TLSv1
        Cipher    : DHE-RSA-AES256-SHA
        Session-ID: B73943E3C764F2A08120794941F3E314A758F8FB6D6D037B31B7ECF7F197C7ED
    ....

That is of course if you haven't disabled TLSv1.0.

If you have, the response looks something like:

    openssl s_client -connect servername:143 -starttls imap -tls1

    CONNECTED(00000003)
    write:errno=104
    ---
    no peer certificate available
    ---
    No client certificate CA names sent
    ---
    SSL handshake has read 271 bytes and written 0 bytes
    ---
    New, (NONE), Cipher is (NONE)
    Secure Renegotiation IS NOT supported
    Compression: NONE
    Expansion: NONE
    SSL-Session:
        Protocol  : TLSv1
        Cipher    : 0000
        Session-ID:
        Session-ID-ctx:
        Master-Key:
        Key-Arg   : None
        Krb5 Principal: None
        PSK identity: None
        PSK identity hint: None
        Start Time: 1441903081
        Timeout   : 7200 (sec)
        Verify return code: 0 (ok)
    ---

Openssl s_client also supports other tls-enbled protocols - see the documentation for details.

Hopefully this will help you test your own servers.

Lousy Workaround

How to work around this? Well, for us, a separate vlan, with a secondary IP address for the mail server, and special vpn access to that vlan. Dovecot lets you have different ssl_protocol settings per IP that the daemon is listening on, so I have a block in my 10-ssl.conf that looks like this:

    ssl_protocols = !SSLv2 !SSLv3 !TLSv1

    local 192.168.128.139 {
    ssl_protocols = !SSLv2 !SSLv3
    }

which disabled TLSv1.0 on the public interface, but leaves it enabled on the more tightly controlled vlan. Theoreticlly this is enough of a compensating control to keep the PCI auditors happy. Yes, to check mail, my iphone users have to VPN in. Ugh. Hopefully Apple will fix this soon.