Traffic Server can be configured to allow only certain clients to use the proxy cache.
Basic SSL Termination¶
The Traffic Server SSL termination option enables you to secure connections in reverse proxy mode between a client and a Traffic Server and/or Traffic Server and an origin server.
The following sections describe how to enable and configure the SSL termination option.
Enable and configure SSL termination for client/Traffic Server connections: Client and Traffic Server Connections
Enable and configure SSL termination for Traffic Server/origin server connections: Traffic Server and Origin Server Connections
Client and Traffic Server Connections¶
The figure below illustrates communication between a client and Traffic Server (and between Traffic Server and an origin server) when the SSL termination option is enabled and configured for Client/Traffic Server connections only.
The figure above depicts the following:
The client sends an HTTPS request for content. Traffic Server receives the request and performs the SSL handshake to authenticate the client (depending on the authentication options configured) and determine the encryption method that will be used. If the client is allowed access, then Traffic Server checks its cache for the requested content.
If the request is a cache hit and the content is fresh, then Traffic Server encrypts the content and sends it to the client. The client decrypts the content (using the method determined during the handshake) and displays it.
If the request is a cache miss or cached content is stale, then Traffic Server communicates with the origin server via HTTP and obtains a plain text version of the content. Traffic Server saves the plain text version of the content in its cache, encrypts the content, and sends it to the client. The client decrypts and displays the content.
To configure Traffic Server to use the SSL termination option for Client/Traffic Server connections, you must do the following:
Obtain and install an SSL server certificate from a recognized certificate authority. The SSL server certificate contains information that enables the client to authenticate Traffic Server and exchange encryption keys.
Set the appropriate base path for your SSL certificates and private keys in
ts: ssl: server: cert: path: /opt/ts/etc/ssl/certs/ private_key: path: /opt/ts/etc/ssl/keys
Add an entry to
ssl_multicert.configfor each certificate and key which your Traffic Server system will be using to terminate SSL connections with clients.
dest_ip=22.214.171.124 ssl_cert_name=example.com.pem dest_ip=* ssl_cert_name=default.pem
Optional: Configure the use of client certificates using the variable
records.yaml. If you configure Traffic Server to require client certificates, then Traffic Server verifies the client certificate during the SSL handshake that authenticates the client. If you configure Traffic Server to not require client certificates, or if you configure certificates to be optional and the connecting client does not present one, then access to Traffic Server is managed through other Traffic Server options that have been set (such as rules in
ts: ssl: client: certification_level: 0
This variable permits one of the following values to be set:
Client certificates not required.
Client certificates optional. If present, will be used to validate.
Client certificates required, and must validate based on configured CAs.
Optional: Configure the use of Certification Authorities (CAs). CAs add security by verifying the identity of the person requesting a certificate. The list of acceptable CA signers is configured with
ts: ssl: CA: cert: path: /opt/CA/certs/private-ca.pem
Restart Traffic Server.
Traffic Server and Origin Server Connections¶
The figure below illustrates communication between Traffic Server and an origin server when the SSL termination option is enabled for Traffic Server/origin server connections.
The figure above depicts the following:
If a client request is a cache miss or is stale, then Traffic Server sends an HTTPS request for the content to the origin server. The origin server receives the request and performs the SSL handshake to authenticate Traffic Server and determine the encryption method to be used.
If Traffic Server is allowed access, then the origin server encrypts the content and sends it to Traffic Server, where it is decrypted (using the method determined during the handshake). A plain text version of the content is saved in the cache, if Traffic Server deems the content cacheable.
If SSL termination is enabled for Client/Traffic Server connections, then Traffic Server re-encrypts the content and sends it to the client via HTTPS, where it is decrypted and displayed. If SSL termination is not enabled for Client/Traffic Server connections, then Traffic Server sends the plain text version of the content to the client via HTTP.
To configure Traffic Server to use the SSL termination option for Traffic Server and origin server connections, you must do the following:
Ensure first that your origin server responds properly to SSL requests, and configure it for client certificate validation if you intend to use that as part of your access control scheme.
Refer to your origin server’s documentation for details. If your origin server is another Traffic Server system, then you may follow the steps outlined in Client and Traffic Server Connections for configuring the origin server to validate client certificates.
Optional: Obtain and install an SSL client certificate from a recognized certificate authority, if your origin server requires client certificate validation for access control. Your client certificate must be signed by a Certificate Authority recognized by your origin server.
ts: ssl: client: cert: filename: client.pem path: /opt/ts/etc/ssl/certs/
You must also provide the paths to the private key for this certificate, unless the key is contained within the same file as the certificate, using
ts: ssl: client: private_key: filename: client.pem path: /opt/ts/etc/ssl/keys/
Add the collection of authorized Certificate Authorities to the Traffic Server configuration in
records.yamlusing the settings
Restart Traffic Server.
Traffic Server allow for the fine-grained specification for TLS client certificates for both client to Traffic Server connections and Traffic Server to origin server connections.
Rotating TLS Session Ticket Keys¶
TLS sessions can be resumed through session tickets which are encrypted with a session ticket key and stored on clients. For better security, the ticket keys can be rotated periodically, say, every 24 hours. The ticket keys are stored in a ticket key file as a reverse queue in 48-byte chunks.
OCSP Stapling is an alternative approach to checking the revocation status of an SSL certificate using the Online Certificate Status Protocol.
Under the original OCSP implementation, clients requested a certificate’s revocation status directly from the Certificate Authority (CA) that issued the certificate. This could cause significant load on the CA servers since they were required to provide a response to every client of a given certificate in real time.
Enabling OCSP Stapling instructs Traffic Server to retrieve and cache the revocation status of all configured SSL certificates, and present them to the client when the client requests the status. Traffic Server will automatically query the OCSP responder specified in the SSL certificate to gather the latest revocation status. Traffic Server will then cache the results for each configured certificate. The location of the OCSP responder is taken from the Authority Information Access field of the signed certificate. For example:
Authority Information Access:
OCSP - URI:http://ocsp.digicert.com
CA Issuers - URI:http://cacerts.digicert.com/DigiCertSHA2SecureServerCA.crt
Traffic Server can also use prefetched OCSP stapling responses if ssl_ocsp_name parameter
is used in
ssl_multicert.config. Take into account that when using prefetched
OCSP stapling responses, Traffic Server will not refresh them and it should be done
externally. This can be done using OpenSSL:
$ openssl ocsp -issuer ca.crt -cert cert.crt -host ocsp.digicert.com:80 \
-header "Host=ocsp.digicert.com" -respout /var/cache/ocsp/cert.ocsp
Support for OCSP Stapling can be tested using the -status option of the OpenSSL client:
$ openssl s_client -connect mozillalabs.com:443 -status
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Details of the OCSP Stapling TLS extension can be found in RFC 6961.
To configure Traffic Server to use OCSP Stapling, edit the following variables
The Split DNS option enables you to configure Traffic Server to use multiple DNS servers, as dictated by your security requirements. For example, you might configure Traffic Server to use one set of DNS servers to resolve hostnames on your internal network, while allowing DNS servers outside the firewall to resolve hosts on the Internet. This maintains the security of your intranet, while continuing to provide direct access to sites outside your organization.
To configure Split DNS:
Specify the rules for performing DNS server selection based on the destination domain, the destination host, or a URL regular expression. These rules are located in
Run the command
traffic_ctl config reloadto apply the configuration changes.