This document describes how to configure the preference for Perfect Forward Secrecy (PFS) in Transport Layer Security (TLS) encrypted connections on the Email Security Appliance (ESA).
Cisco recommends that you have knowledge of Secure Sockets Layer (SSL)/TLS.
The information in this document is based on AsyncOS for Email version 9.6 and above.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
The ESA does offer Forward Secrecy (PFS). Forward secrecy means that the data is transferred via a channel that uses symmetrical encryption with ephemeral secrets, and even if the private key (long-term key) on one or both of the hosts was compromised, it is not possible to decrypt a previously recorded session.
The secret is not transferred through the channel, instead the shared secret is derived with a mathematical problem (Diffie Hellman (DH) Problem). The secret is not stored anywhere else than the hosts Random Access Memory (RAM) during the established session or key regeneration timeout.
The ESA supports DH for Key Exchange.
INBOUND - ESA Acts as TLS Server
These cipher suites are available on the ESA for INBOUND Simple Mail Transfer Protocol (SMTP) traffic that provide Forward Secrecy. In this example,cipher selection allows only cipher suites considered HIGH or MEDIUM and use Ephemeral Diffie Hellman (EDH) for Key Exchange and prefers TLSv1.2. The cipher selection syntax follows the OpenSSL syntax.
The Kx (= Key Exchange) section shows that DH is used in order to derive the secret.
The ESA supports these ciphers with the default sslconfig settings (:ALL), but does not prefer it. If you want to prefer ciphers that offer PFS, you need to change your sslconfig and add EDH or a combination EDH+<cipher or cipher group name> to your cipher selection.
Note: RC4 as a cipher and MD5 as a MAC is considered weak, legacy and in order to avoid the use with SSL/TLS, especially when it comes to higher data volume without key regeneration.
Recommended sslconfig Settings for INBOUND
This is a prevailing opinion and to only allow ciphers that are generally considered strong and secure.
A recommendable configuration for INBOUND that removes RC4 and MD5 as well as other legacy and weak options, namely Export (EXP), Low (LOW), IDEA (IDEA), SEED (SEED), 3DES (3DES) ciphers, DSS certificates (DSS), anonymous Key Exchange (aNULL), pre-shared Keys (PSK), SRP protocol (SRP), disables Elliptic Curve Diffie Hellman (ECDH) for Key Exchange and Elliptic Curve Digital Signature Algorithm (ECDSA) are the examples:
Note: The ESA that acts as a TLS server (INBOUND traffic) currently does not support Elliptic Curve Diffie Hellman for Key Exchange (ECDHE) and ECDSA Certificates.
OUTBOUND - ESA acts as TLS Client
For OUTBOUND SMTP traffic, the ESA in addition to INBOUND supports ECDHE and ECDSA Certificates.
Note: Elliptic Curve Cryptography (ECC) certificates with the ECDSA are not widely adopted.
When an OUTBOUND email is delivered, the ESA is the TLS client. A TLS-client certificate is optional. If the TLS-Server do not force (require) the ESA (as a TLS-client) in order to provide a ECDSA client certificate, the ESA can continue with a ECDSA secured session. When the ESA as the TLS-Client is asked for it's certificate, it provides the configured RSA certificate for the OUTBOUND direction.
Caution: The preinstalled Trusted CA Certificate Store (System List) on the ESA does not include ECC (ECDSA) Root Certificates! You might need to manually add ECC Root Certificates (which you trust) to the Custom List in orderto make the ECC Chain of Trust verifiable.
In order to prefer DHE/ECDHE ciphers that offer Forward Secrecy, you can modify the sslconfig cipher selection as follows.