A recent exchange amongst ALUG email list members about list etiquette resulted in a flurry of postings on a variety of related topics. I posted a flippant comment about top posting, but did so (deliberately) from my Galaxy tab using Samsung’s default email client which actually forces top posting. Steve responded suggesting that I look at K9, the android email client of choice for those who care about proper adherence to email standards.
Now I last used K9 around the tail end of 2011 but gave up because it had a silly little problem with my self signed TLS certificates and I told the list that. Steve wasn’t satisfied with that answer and pointed to a discussion about the issue which suggested that my certificates might be causing the problem if the IMAP/POP certificate used the same identifiers (for example, the CN) as the SMTP certificate when the certificates were actually different. In my case this turned out to be exactly what was wrong. Even though both my dovecot and my postfix X509 certificates contained exactly the same information, because I had generated them separately at different dates (purely by historic accident) the certificates and keys differed and it was this which caused K9 to barf. As bernhard, a member of the K9 project team said:
“the problem is that your imaps and your smtps certifcate don’t match. we store the certs with their CN. So if the CN is the same but the cert is different we get a problem.
The fix is complexe and breaks backward compability so we can’t apply it.
I know this does not sound good :/
there is some missing feature which is an blocker on this issue, but i can’t give you an timetable when this missing part is addressed.I fear the only thing you can do about this is to change your smtps cert to be the same as your imaps cert.”
So I did. I simply changed my dovecot SSL configuration to point to the same certificate and key as I had in place for postfix and bingo, my newly re-installed K9 stopped barfing. Of course, I hadn’t spotted this fix because I had given up on K9 before the fix was documented (he said…).
Now given that I have recently strengthened the SSL/TLS certificates I use and tightened up my lighttpd configuration to force use of stronger ciphers, I thought I ought to take a look at doing the same for my dovecot and postfix configurations. It turns out to be both possible and pretty simple to do so. Here’s how.
In dovecot the SSL/TLS configuration is handled by the file /etc/dovecot/conf.d/10-ssl.conf. The relevant sections of my file now contain the following:
# dovecot ssl configuration for IMAPS/POP3S mail.
ssl = yes
# PEM encoded X.509 SSL/TLS certificate and private key. They’re opened before
# dropping root privileges, so keep the key file unreadable by anyone but
# root. Note that the key and certificate file can be combined into one (as here).ssl_cert = </path/to/my/smtp-server-cert.pem
ssl_key = </path/to/my/smtp-server-cert.pem
# SSL ciphers to use
# (default)
# ssl_cipher_list = ALL:!LOW:!SSLv2:!EXP:!aNULL# (better)
ssl_cipher_list = TLSv1+HIGH !SSLv2 !RC4 !aNULL !eNULL !3DES @STRENGTH
#
# end
For postfix, the configuration is handled in the usual main.cf. I have updated the relevant section of my configuration file as below:
# TLS parameters
# where we get our entropy
tls_random_source = dev:/dev/urandom
smtpd_use_tls=yes
smtpd_tls_security_level = may
smtpd_tls_auth_only = yes
smtpd_tls_cert_file=/path/to/my/smtp-server-cert.pem
smtpd_tls_key_file=$smtpd_tls_cert_file
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
#
# use only the high grade ciphers (128 bit and higher AES)
#
smtpd_tls_ciphers = high
#
# and exclude known weaknesses
#
smtpd_tls_exclude_ciphers = aNULL, DES, 3DES, MD5, DES+MD5, RC4
#
# and limit the protocols to TLSv1, specifically excluding SSL version 2 and 3
#
smtpd_tls_protocols = TLSv1, !SSLv2, !SSLv3
#
Note that the postfix configuration documentation says that the full list of cipher grades available for opportunistic TLS (which we are using, mandatory is not advisable unless you wish to break your email) is:
null – encryption-less grades for authenticated loopback traffic
export – 90’s style “export” weak keys or stronger (i.e. deliberately broken…..)
low – Legacy single-DES keys or stronger
medium – 128-bit RC4 or stronger
high – 128-bit AES or stronger
Note also that opportunistic TLS defaults to “export”, which is probably not what you want these days. Here I have deliberately limited the ciphers to “high”.
Now after reloading our mail system we can check the configuration on dovecot with openssl thus:
openssl s_client -connect my.mailserver.com:993
and amongst the details returned we see the reassuring response:
—
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.1
Cipher : DHE-RSA-AES256-SHA
—
and the same check on our postfix mailer port thus:
openssl s_client -connect my.mailserver.com:25 -starttls smtp
gives us:
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.1
Cipher : ECDHE-RSA-AES256-SHA
Job done.