Excluded cipher causing interoperability issues with outlook.

[zeyadtamimi]

While looking at my server logs I noticed that the mail coming in from outlook resulted in: warning: TLS library problem: error:0A0000C1:SSL routines::no shared cipher:ssl/statem/statem_srvr.c:2220:

Further examining the logs seemed to indicate that the connection fell back to an unencrypted mode as I don't see any reference to an SSL connection being established or cipher being negotiated.

After disabling the cipher blacklist smtpd_tls_exclude_ciphers I sent another test email and through the logs I can see that the connection was using TLSv1.2 and the negotiated cipher suite was ECDHE-ECDSA-AES256-GCM-SHA384

Reading more into this, I could not find anything sub optimal about this particular cipher suite. Is the blanket exclusion of everything using ECDSA warranted here?

[LukeSmithxyz]

I've temporarily disabled the cipher list until I can check some more things.

I noticed that mails from other major sites were not going through if they had obsolete ciphers. (Even major banks and institutions.)

I think it's best to let the servers receive the mail obviously, so until I discern which should actually be excluded, I will not use the cipher blocklist.

[hasanparasteh]

@LukeSmithxyz can you provide a patch?

[ploprof]

@LukeSmithxyz

Perhaps exclude eNULL and aNULL ?

These provide no security whatsoever and so having the connection falling back to unencrypted wouldn't hurt with these.

Weak encryption is of course better than no encryption, however as far as I can tell postfix by default already requires ciphers to be at least medium strength and so excluding LOW is superfluous as is EXP, furthermore the newest openssl in the newest debian version doesn't include ciphers using MD5, CAMELLIA128, 3DES, CAMELLIA256 or RSA+AES

The only ciphers that are now not excluded as compared to your original exclude list are the ECDSA ones which I realize are controversial, however they are still widely used and I don't think them being excluded is merited when faced with the worst case scenario of the connection as a result falling back to being unencrypted.

Therefore I suggest the following:

postconf -e 'tls_preempt_cipherlist = yes
postconf -e 'smtpd_tls_exclude_ciphers = aNULL, eNULL'

The reason for also enabling server side cipher preferences is to ensure that ciphers that guarantee forward secrecy are preferred. With these settings Postfix will first offer TLS v1.3 ciphers (which all afford forward secrecy) before falling back to TLS v1.2 ciphers starting with those that provide forward secrecy and only opting for ones that do not if the client doesn't support those that do.

EDIT:

The CAMELLIA and the RSA_WITH_AES ciphers are used when using my suggested configuration, however I fail to see the problem with them, Camellia seems to be as secure as AES at 128bit and 256bit, if a given server only wants to communicate using Camellia it's surely better than falling back to plaintext, no?