Postfix/TLS - Security Considerations

The following sections cover some (possible) security issues with regard to Postfix/TLS.

Server/Client private key file

Postfix/TLS uses authentication for the server side (mandatory) and the client side (optional). In order to authenticate itself, the according process (smptd/smtp) must be able to access the private key, which must however be kept secret. As these processes are started from 'master' without the possibility of user interaction, it is not possible to supply a password, so that the private key can not be encrypted.

The only protection can therefore come from filesystem access rights, which should be set to 'owner root' and 'readable for owner only':

-rw-------   1 root       sys            887 Apr 29  1999 /etc/postfix/key.pem

This protection is only as good as your host is protected against root exploits.

You also should be aware, that people having physical access to your system might be able to 'steal' the private key if they can boot into single user mode without password protection or can move the disk to another computer, on which they have root rights. (Yes, I know there are such things as encrypted filesystems, but they are not in wide spread use today.)

Disk based session cache

If you run disk based session caching (the default) people being able to get hold of the files might be able to figure out security relevant communication parameters. The security situation is however not more dramatic than the private key issue explained above, so I don't consider any additional danger coming from saving session information to stable storage.

As breaking the code with public key cryptography is just a matter of time (even though it might be a very long time), sessions should not be used for an infinite duration. The default value for Postfix/TLS is 1h; RFC2246 (TLSv1) recommends to not use sessions for more than 24h.

DNS issues

One weak point in authentication is the use of the DNS to find out the MX information. Since we do (E)SMTP, we must use the MX information!

As we have to authenticate the server retrieved via MX, somebody able to spoof a wrong MX entry might be able to receive the email, if his host can present a certificate issued by an acceptable CA. The last part is not too difficult if 'standard' CAs like Verisign, Thawte,... are included.

The only way to protect against this problem is that for those recipients, for which we want to enforce encryption and authentication, the MX lookup must be overridden with an appropriate entry in the /etc/postfix/transport table:

important.dom.ain smtp:[mailserver.important.dom.ain]
Postfix/TLS - Security Considerations

Postfix/TLS - Security Considerations

The following sections cover some (possible) security issues with regard to Postfix/TLS.

Server/Client private key file

Postfix/TLS uses authentication for the server side (mandatory) and the client side (optional). In order to authenticate itself, the according process (smptd/smtp) must be able to access the private key, which must however be kept secret. As these processes are started from 'master' without the possibility of user interaction, it is not possible to supply a password, so that the private key can not be encrypted.

The only protection can therefore come from filesystem access rights, which should be set to 'owner root' and 'readable for owner only':

-rw-------   1 root       sys            887 Apr 29  1999 /etc/postfix/key.pem

This protection is only as good as your host is protected against root exploits.

You also should be aware, that people having physical access to your system might be able to 'steal' the private key if they can boot into single user mode without password protection or can move the disk to another computer, on which they have root rights. (Yes, I know there are such things as encrypted filesystems, but they are not in wide spread use today.)

Disk based session cache

If you run disk based session caching (the default) people being able to get hold of the files might be able to figure out security relevant communication parameters. The security situation is however not more dramatic than the private key issue explained above, so I don't consider any additional danger coming from saving session information to stable storage.

As breaking the code with public key cryptography is just a matter of time (even though it might be a very long time), sessions should not be used for an infinite duration. The default value for Postfix/TLS is 1h; RFC2246 (TLSv1) recommends to not use sessions for more than 24h.

DNS issues

One weak point in authentication is the use of the DNS to find out the MX information. Since we do (E)SMTP, we must use the MX information!

As we have to authenticate the server retrieved via MX, somebody able to spoof a wrong MX entry might be able to receive the email, if his host can present a certificate issued by an acceptable CA. The last part is not too difficult if 'standard' CAs like Verisign, Thawte,... are included.

The only way to protect against this problem is that for those recipients, for which we want to enforce encryption and authentication, the MX lookup must be overridden with an appropriate entry in the /etc/postfix/transport table:

important.dom.ain smtp:[mailserver.important.dom.ain]