How switching off SSLv3 in Courier-IMAP server affects old Mail User Agents?

Solution 1:

Having tried this last week, my experience was it breaks a lot of clients. It's true that modern Outlook supports TLS, but it thinks this means start in plaintext then escalate to encryption. The idea that TLS can be used as an ab initio cyphersuite seems to have escaped it; whenever I selected TLS, it insisted that it wanted to use IMAP port 143, not IMAP/S port 993. Though I confess to being no Windows admin, I was unable to persuade it otherwise, and since I have no desire whatsoever to expose port 143, that rather stymied me.

K-9 mail (v5.001) on Android phones broke as well. ALPINE (2.11) under Linux was fine, of course. I can't speak for Thunderbird on any platform, because by the time my users (including my wife) had finished bending my ears, I was persuaded to switch back.

Most of the analysis I've seen suggests that there are no known IMAP/POP-based SSLv3 exploits at this time. My new plan is to set up a second dovecot on port 994, doing only TLS, and gently chivvy my users into finding clients that work for them. If I see any reports of mail-based exploits in the wild, that "gently" might get a bit more forceful.

Edit to address mc0e's comment below:

Yours is a common misconception, and indeed one I suffered from for many years. However, the belief that TLS can only be used for encryption via escalation-from-plaintext is as wrong as it is common.

Consider: POODLE mitigation relies on disabling SSLv3 for HTTPS servers; mitigated servers can only speak TLS. Unless you think that HTTPS has just got itself a plaintext-first phase which was not there before POODLE, and that all the world's web browsers have suddenly changed behaviour when they connect to TCP port 443 (it hasn't, and they haven't; fire up wireshark and see), then TLS is being used for sessions which are encrypted from the start. TLS certainly supports uprating from plaintext, but it can also be used for ab initio encryption - despite what various client software packages think.

Edit 2: mc0e, I agree that STARTTLS is definitely restricted to initially-plaintext services. However, that's not what's under discussion, and it's not the terminology that many clients use. For them, as for many, STARTTLS and TLS are the same thing; my point is that they are not; the latter is a pure superset of the former.

People who think that the switch of encrypted non-web services away from SSLv3 will be easy "because the client supports TLS" may run into problems because what the client really means is that it supports "STARTTLS for encryption uprating", rather than "TLS as a cryptosuite for both ab initio encrypted connections and uprating from plaintext".