Postfix and TLS

Support for TLS in Postfix is provided by a set of patches written by Lutz Jänicke. You can follow the link for Add-on Software from the Postfix home page to download the patches. (See Appendix C for information on building Postfix with the TLS patches.) If you are using a prebuilt Postfix package for your platform, make sure that it has the TLS patches built in.

In addition to compiling Postfix to support TLS, you must also create and configure TLS certificates. You need both a private key and a public key. The public key is a signed certificate identifying your server. It is validated and digitally signed by a certificate authority (CA), which attests that your certificate does, in fact, identify your system (see sidebar in TLS Certificates Brief Overview). In addition to your own certificates, you must also have the public key of the CA that signed your certificate.

You can register with any of the many CAs to obtain a signed certificate, or you can act as your own CA. The clients connecting to your TLS-enabled server must recognize and acknowledge the CA you use and agree to accept it as an authority to attest to your identity. Generally, it is a fairly simple configuration option in email clients to accept a certificate and have the CA public key added to its list of trusted authorities if it isn't listed already.

TLS Certificates Brief Overview

TLS uses public-key cryptography to allow a client and a server to communicate privately. It also provides assurance that no one has tampered with transmitted information and that the information is not forged because the protocol allows for both the client and server to authenticate each other. Always keep in mind, however, that the benefits of TLS are limited to just the end points of a given TLS connection. What happens to any data before or after it passes between the client and server is not protected by TLS.

Public-key cryptography uses a pair of complementary keys. One can be widely distributed and the other is a secret key. Data encrypted with one key can be decrypted with the other key and vice versa. Others can send you data encrypted with your public key that only you can decrypt with your private one. In most implementations, the private key can be used to create a digital signature of a block of data. The public key can then be used to verify that a particular private key created a given signature.

Moreover, your public key is associated with an identifier, referred to as its common name (often the hostname of your server). Others can be sure your server is what it claims to be by comparing the common name associated with its public key against its DNS hostname or a name supplied during connection handshaking. In general, you want everyone to have your public key, but your private key must be guarded at all costs.

Public keys are digitally signed by CAs to create certificates. CAs are usually third-party organizations that are trusted by both sides of the exchange. In theory, the CA's digital signature indicates that it has verified the identity of the public-key holder and attests that this public key belongs to this server.Chapter 13 A public key validated by a CA is often referred to as a signed certificate. Your trust in a certificate should extend only as far as your faith in the CA that signed it. The only assurance that exists with certificates comes from the CA that attests to a certificate holder's identity.

The public/private keys are actually used only at the beginning of a connection to determine identities and to encrypt a randomly chosen session key. This single key is used by both sides to encrypt and sign the rest of the exchange. A session key can be used only for a single session, and then it is discarded.

Let's take a look at the exchange between a client and server. The client contacts a server and requests an encrypted connection. On the Web, the client uses https; with email, the client issues the STARTTLS command to indicate that it wants an encrypted connection.

In practice, this has turned out to be a very difficult aspect of public-key cryptography systems. There have been a number of high-profile failures revealing that trust in a trusted certificate authority might be misplaced.

The server obliges by sending back its signed certificate, which indicates its common name and the CA that has validated it. The client verifies the server's identity. It checks to see if the signing CA is listed among those it trusts and that the common name on the certificate is what it expects. If the certificate checks out, the client and server determine a key agreement to generate a session key to be used for this exchange and then discarded. The key agreement determination differs depending on the type of cypher in use. The conversation continues with both sides now using the private session key to encrypt and verify all transmissions.