Postfix Encryption

I've been tinkering with the encryption options in Postfix for a while. Encryption between clients and their SMTP server and between SMTP servers is necessary to protect the to, from, and subject fields, along with the rest of the header, of an email. The body of the message is also protected but it's always better to utilize PGP or S/MIME cryptography to provide end-to-end protection; encryption between clients and SMTP servers doesn't provide this.

As rolled out now, encryption between SMTP servers is opportunistic encryption and is generally not required. While doing a review of my mail log I seem to be receiving most personal mail via some encrypted circuit while much of the mail coming out of listservs, like Yahoo! Groups, is not negotiating encryption on connect. I've also noticed that some email providers actually run their incoming email through an external service, I suspect for spam control, before accepting the message into their servers. Some of these spam services don't support encryption making it difficult to protect mail in transit.

Postfix documentation is pretty decent. The project seems to document most settings but sometimes they don't actually put the entire picture together. Encryption is one of those things where a complete picture is difficult to put together just by looking at a single page of documentation.

Postfix's documentation on TLS is fairly complete. What they miss on that page, forward security, must be found else where. Until last night, I had missed that last page and now have fixed my configuration to include, what I consider, acceptable settings.

Here's what I've got:

main.cf

### TLS

smtpd_tls_security_level = may

smtpd_tls_eecdh_grade = ultra

tls_eecdh_strong_curve = prime256v1

tls_eecdh_ultra_curve = secp384r1

smtpd_tls_loglevel = 1

smtpd_tls_cert_file = /etc/pki/tls/certs/mail.crt

smtpd_tls_key_file = /etc/pki/tls/private/mail.key

smtpd_tls_CAfile = /etc/pki/tls/certs/mail-bundle.crt

smtpd_tls_session_cache_timeout = 3600s

smtpd_tls_session_cache_database =

btree:${queue_directory}/smtpd_scache

smtpd_tls_received_header = yes

smtpd_tls_ask_ccert = yes

smtpd_tls_received_header = yes

tls_random_source = dev:/dev/urandom

#TLS Client

smtp_tls_security_level = may

smtp_tls_eecdh_grade = ultra

smtp_tls_loglevel = 1

smtp_tls_cert_file = /etc/pki/tls/certs/mail.crt

smtp_tls_key_file = /etc/pki/tls/private/mail.key

smtp_tls_CAfile = /etc/pki/tls/certs/mail-bundle.crt

master.cf

submission inet n - - - - smtpd

-o smtpd_tls_security_level=encrypt

-o smtpd_sasl_auth_enable=yes

-o smtpd_sasl_type=dovecot

-o smtpd_sasl_path=private/auth

-o smtpd_sasl_security_options=noanonymous

Those familiar with setting up TLS in Apache will notice a few differences here. We haven't defined ciphers or SSL protocols. This is because this is opportunistic encryption. We're just happy if encryption happens, even using EXPORT ciphers, since the alternate is plaintext. In a more controlled setting you could define the ciphers and protocols and enforce their use. Until encryption becomes the norm on the Internet (and why shouldn't it be?) I'll have to stick with just begging for encrypted connections.

It should also be noted that client-to-SMTP server connections are forced to be encrypted in master.cf as seen in the submission portion. This was a quick and dirty way of forcing encryption on the client side while allowing opportunistic encryption on the public (port 25) side.

It should be noted that ECC keys can be used with Postfix, which forces good ciphers and protocols, but most email servers have RSA keys established so problems could arise from that. Dual keys can always be used to take advantage of both ECC and RSA.

As SSLLabs is for testing your web server's encryption settings, so is CheckTLS for checking your SMTP encryption settings. These tools are free and should be part of your regular security check of your infrastructure.

Sparks's Journal

Other articles

How to really screw up TLS

Ability to remove TLS 1.0 from httpd in CentOS 6

256 Bits of Security

Kicking RC4 out the door

How secure are those SSL and SSH keys anyway?

Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010

Trusting Trusted CAs

Inadvertant data leakage from GnuPG