SSL Decryption
The Virtual Traffic Manager can decrypt and re-encrypt SSL traffic dynamically as it proxies requests between clients and back-end pools, utilizing server and client certificates stored in the SSL Catalog.
After decrypting traffic, for example, to apply TrafficScript rules, the Virtual Traffic Manager can re-encrypt the data if required before passing it to the nodes. This allows flexible management of requests without compromising security requirements on potentially untrusted networks. The Virtual Traffic Manager thus provides a fully transparent SSL gateway.
As the computational resources available to cryptographic attackers increases, stronger keys are required to secure SSL/TLS sites. However, the processing time needed to use longer DSA and RSA keys increases rapidly with key length. To address this issue, the Virtual Traffic Manager provides the option of Elliptic Curve Cryptography (ECC) due to it's increased efficiency with stronger keys. Specifically, the Virtual Traffic Manager supports keys based on the Elliptic Curve Digital Signature Algorithm (ECDSA).
Setting Up SSL Decryption
To enable SSL decryption, click Services > Virtual Servers and then click the Edit button for a virtual server that supports SSL.
In the list of configuration options for the virtual server, click the Edit button for “SSL Decryption”.
The Virtual Traffic Manager displays a list of configuration options for SSL decryption for this virtual server.
To enable SSL decryption, set ssl_decrypt to “Yes” and click Update at the bottom of the page.
Use the certificate setting to select the certificates you want to use for the default SSL site. To add certificate mappings for additional SSL sites handled by this virtual server, use the "Add certificate mapping" section.
In all cases, choose either one or two certificates using the pair of drop-down lists provided. If you specify a single certificate, you can use any applicable certificate key type. However, if you specify two certificates, you must select a different key type for each one. For more details, see Using Multiple Certificates to Achieve Compatibility With More Clients.
You can also configure the following settings:
- ssl_headers: The Virtual Traffic Manager includes the option to add HTTP headers with details about the decryption performed (HTTPS decryption only). These describe the client cipher, session ID and whether a valid client certificate was provided, and can be inspected by the back-end application to determine what encryption parameters were used.
Header name | Sample Value |
|---|---|
SSLClientCipher | SSL_RSA_WITH_AES_128_CBC_SHA256, version=TLSv1.2, bits=128 |
SSLClientCertStatus | NoClientCert or OK |
SSLSessionID | 8723367551317ABE5443278C6E… (64 hex characters) |
- ssl_trust_magic: If you have a setup involving two distinct clusters of Virtual Traffic Managers, SSL traffic forwarded from one cluster to the other typically appears to originate from the first cluster. Use this setting to instruct your Virtual Traffic Managers to pass the true origin IP addresses of the connections to each other.
To use this setting, your Virtual Traffic Managers must be properly configured. For more information, see the ssl_enhance setting in your pool's SSL configuration.
- ssl_send_close_alerts: To avoid truncation attacks, the SSL specifications require that the client and server share the knowledge that a connection is ending by sending a close alert. This setting is enabled by default as some clients, especially FTP clients, are strict with close alerts and fail to function properly if the alerts are omitted. Note that close alerts can break some older SSL implementations, including some versions of Microsoft Internet Explorer. Ivanti recommends disabling this setting if your services are affected. You can also modify this behavior dynamically by using TrafficScript rules.
- ssl_ocsp_stapling: Enable this option to allow the virtual server to include an OCSP certificate status in the TLS handshake, provided that a status_request extension is sent by the client. It also triggers OCSP requests for each of the virtual server's certificates to be made in the background to the responders named in each certificate's “Authority Information Access” extension's OCSP URI. This option is disabled by default.
Click Update to apply the changes to the virtual server.
Serving Multiple Sites Using a Single Virtual Server
There are two ways that the Virtual Traffic Manager can distinguish between different services:
- Destination IP address: "secure.site1.com" and "secure.site2.com" could resolve to different IP addresses. The Virtual Traffic Manager can listen on both IP addresses and select the certificate to use based on the IP address the connection was received on.
- TLS Server Name Indication1: TLS has an optional capability where a client can provide the name of the service it is trying to contact (in plain text format) at the very beginning of the TLS handshake. The Virtual Traffic Manager can inspect this name and chose the certificate to use.
ATTENTION TLS Server Name Indication is scalable and easy to manage, as it does not require each SSL service to be running on a dedicated IP address. However, some older Web clients such as Internet Explorer 7 (Windows XP) do not support this feature and can receive the wrong certificate if they attempt to access a service that requires TLS server name support.
If your virtual server is managing traffic for more than one site, you must configure the virtual server with a certificate containing a Subject Alternative Name to match each site the client is trying to access. If the client is unable to locate a Subject Alternative Name that matches the DNS name of the service, the client can fall back to checking the Common Name (CN) field instead. The client warns the end user if there is no match.
Configuring Multiple Certificates
A single certificate can contain multiple Subject Alternative Names to match each SSL site served by the virtual server, in which case you need only configure the virtual server to use that certificate as it's default.
Alternatively, you can configure the virtual server with multiple certificates, each with a single Subject Alternative Name matching one of the SSL sites. You then configure the virtual server to use specific certificate mappings using the "Add certificate mapping" section.
Create a new certificate mapping by specifying either an IP address or host name in the first text box and then selecting a certificate from the drop-down list. To save this mapping, click Update at the bottom of the page.
When the Virtual Traffic Manager receives a request it checks the certificate settings to determine the certificate to send. If a connecting client provides a server name in their SSL handshake that matches the host name in a mapping, or if the client connects to an IP address specified in a mapping, they are given the nominated certificate rather than the default certificate.
The Virtual Traffic Manager chooses the first matching certificate. Exact matches of server name come first, then wildcard matches of server name, and finally exact matches of IP address. If there are no matches, the default certificate is used.
If more than one certificate mapping using a wildcard matches the server name, the Virtual Traffic Manager uses the mapping with the most non-wildcard characters first. For example, if the client sends the server name "www.foo.example.com", the Virtual Traffic Manager uses the certificate associated with a mapping for "*.foo.example.com" in preference to a mapping for "*.example.com".
Using Multiple Certificates to Achieve Compatibility With More Clients
When configuring the default certificate on a virtual server, or when configuring a certificate mapping for an IP address / hostname, the Virtual Traffic Manager allows you to configure two separate certificates. During the SSL handshake, the Virtual Traffic Manager chooses a combination of cipher suite, signature algorithm, and server certificate that the client has indicated support for. It can therefore be advantageous to provide the following:
- One certificate chain using an ECDSA key, and one using an RSA key to be used by pre-TLSv1.3 clients that don't support ECDSA ciphers
- One certificate chain using RSA-PSS signatures and one using only PKCS1-v1_5 signatures
If multiple certificate chains would be accepted by the client, the Virtual Traffic Manager sends the first chain that is compatible with its most preferred combination of cipher suite and signature algorithms. For more details, see Configuring Ciphers and TLS Versions.
Configuring Ciphers and TLS Versions
As cryptographic algorithms weaken naturally over time, SSL and TLS are able to negotiate between multiple potentially-supported algorithms, providing the following advantages:
- Authentication of endpoints
- Key exchange
- Bulk encryption
The Virtual Traffic Manager enables you to configure the algorithms available to be negotiated through your services, and in some circumstances to set priorities for the available algorithms.
The Virtual Traffic Manager contains global default settings for your security configuration, although this can be overridden on a per-virtual server or per-pool basis for dedicated control over particular services. The Virtual Traffic Manager also contains settings that control the configuration to be used for the Admin UI and REST API. The sections that follow describe the available controls.
Protocol Versions
The Virtual Traffic Manager supports SSLv3, TLSv1.0, TLSv1.1, TLSv1.2, and TLSv1.3 for all SSL connections.
When a client connects to a server, negotiation of a protocol version is one of the first actions performed. When acting as a server, the Virtual Traffic Manager always selects the highest supported version for which the client advertises support. Some of the subsequent elements of cipher selection have slightly different impacts for different protocol versions.
To configure which protocol versions are enabled, see the following pages of the Admin UI:
- For administration interface and control plane connections, click System > Security > SSL Settings for Admin Server and Internal Connections. Use the "admin!support_<version>" settings to configure protocol support.
- For global defaults for service connections, click System > Global Settings > SSL Configuration. Use the "ssl!support_<version>" settings to configure protocol support for your services.
- To override the global defaults for individual virtual servers, click Services > Virtual Servers > Edit > SSL Decryption and configure the "ssl_support_<version>" settings.
- To override the global defaults for individual pools, click Services > Pools > Edit > SSL Settings and configure the "ssl_support_<version>" settings.
Cipher Suites
The Virtual Traffic Manager allows you to configure a bespoke list of cipher suites (in preference order) available to be used by SSL connections. To see the full list of cipher suites currently supported by the Virtual Traffic Manager, view the UI Help for the System > Global Settings > SSL Configuration page.
Some cipher suites shown in the UI Help are marked as supported but disabled by default. To allow the Virtual Traffic Manager to use these cipher suites, you must explicitly add them into your cipher suites preference lists. Alternatively, use the special value "all" to force the Virtual Traffic Manager to enable the complete list of cipher suites.
The Virtual Traffic Manager uses separate cipher suites preference lists for different connection types. To configure cipher suite preference lists, see the following pages of the Admin UI:
- For administration interface and control plane connections, click System > Security > SSL Settings for Admin Server and Internal Connections and configure the "admin!ssl3_ciphers" setting. Leave this field blank to allow the use of all cipher suites enabled and supported by this Virtual Traffic Manager.
- To set a global preference list for all other connections, click System > Global Settings > SSL Configuration. Use the "ssl!cipher_suites" setting to configure a cipher suites preference list for your virtual servers and pools. Leave this field blank to allow the use of all cipher suites enabled and supported by this Virtual Traffic Manager.
- To override the global preference list for an individual virtual server, click Services > Virtual Servers > Edit > SSL Decryption and set "ssl_cipher_suites" to your dedicated cipher suite list. Leave this field blank to use the global list.
- To override the global preference list for an individual pool, click Services > Pools > Edit > SSL Settings and set "ssl_cipher_suites" to your dedicated cipher suite list. Leave this field blank to use the global list.
Prior to TLSv1.3, selection of a given cipher suite determined the following:
- The type of public key that the server must present as authentication. Supported key types are ECDSA, RSA, and DSA.
- The algorithm to be used for key exchange. Supported algorithms are ECDHE, DHE, and non-Diffie-Hellman RSA.
- The bulk encryption algorithm to be used. Supported algorithms are CHACHA20_POLY1305, AES-GCM, AES-CBC with HMAC, 3DES with HMAC, RC4 with HMAC, and DES with HMAC.
The names used by the Virtual Traffic Manager for pre-TLSv1.3 cipher suites are formed by replacing the "TLS_" prefix in the Internet Assigned Numbers Authority (IANA) TLS Cipher Suites registry (https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml) with the "SSL_" prefix.
For example, the Virtual Traffic Manager cipher SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA represents the IANA cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA. When using this cipher suite, the server must present an ECDSA public key in the server certificate as authentication. The key exchange algorithm in use is ECDHE, and 256-bit AES-CBC is used for bulk encryption.
For TLSv1.3 and later, the meaning of cipher suites has changed. Here, selection of a given cipher suite no longer affects public key or key exchange algorithms, and only determines the algorithm to be used for bulk encryption. The names used by the Virtual Traffic Manager for TLSv1.3 cipher suites are the same as the names in the IANA TLS Cipher suites registry.
When acting as a server and choosing a cipher suite, the Virtual Traffic Manager selects the available suite that appears first in the applicable cipher suites list. The selected suite must be compatible with a configured certificate and must have a compatible signature algorithm available; in this case, client preference is not taken into consideration. The Virtual Traffic Manager chooses a cipher suite before choosing a signature algorithm.
Signature Algorithms
Using a public key to verify a signature is a key concept in TLS. This approach is used to validate certificate chains and to authenticate remote entities in a TLS handshake by verifying a signature that is provided of some known content. The Virtual Traffic Manager typically supports signature algorithms based around ECDSA, DSA, and RSA. For RSA, the PKCS1 standard (https://tools.ietf.org/html/rfc8017) defines two signature schemes:
- PKCS1-v1_5
- PSS
The Virtual Traffic Manager supports both schemes when validating certificate chains. When signing/verifying handshake signatures, PKCS1-v1_5 is supported for TLSv1.2 and earlier, and PSS is supported for TLSv1.2 and later.
PSS is unsupported for TLSv1.2 CertificateVerify handshake messages.
The Virtual Traffic Manager uses signature algorithms to verify certificate signatures, and when signing or verifying handshake signatures (from TLSv1.2 onwards). To restrict the algorithms available for this purpose, set system-wide preference lists in the Global Settings, or set local override lists in your virtual server and pool SSL settings. When the Virtual Traffic Manager needs to choose a signature algorithm to use (for example, when generating a handshake signature) it uses the first signature algorithm listed that is compatible with the cipher suite.
To see the full list of signature algorithms currently supported by the Virtual Traffic Manager, view the UI Help for the System > Global Settings > SSL Configuration page.
To configure signature algorithm preference lists, see the following pages of the Admin UI:
- For administration interface and control plane connections, click System > Security > SSL Settings for Admin Server and Internal Connections and configure the "admin!ssl_signature_algorithms" setting. Leave this field blank to allow the use of all signature algorithms supported by this Virtual Traffic Manager.
- To set a global preference list for all other connections, click System > Global Settings > SSL Configuration. Use the "ssl!signature_algorithms" setting to configure a signature algorithms preference list for your virtual servers and pools. Leave this field blank to allow the use of all signature algorithms supported by this Virtual Traffic Manager.
- To override the global preference list for an individual virtual server, click Services > Virtual Servers > Edit > SSL Decryption and set "ssl_signature_algorithms" to your dedicated signature algorithms list. Leave this field blank to use the global list.
- To override the global preference list for an individual pool, click Services > Pools > Edit > SSL Settings and set "ssl_signature_algorithms" to your dedicated signature algorithms list. Leave this field blank to use the global list.
For the virtual server or pool "ssl_signature_algorithms" settings, enter the special value "default" to force the corresponding virtual server or pool to ignore any value set in the global preference list and instead use the default list of signature algorithms declared as supported (and not disabled) in the UI Help.
When acting as a server and choosing a signature algorithm, the traffic manager chooses the available algorithm that is first in the application signature algorithms list, that is compatible with the chosen cipher suite and with a configured certificate. The traffic manager chooses a signature algorithm after choosing a cipher suite.
When acting as a server and choosing a signature algorithm, the Virtual Traffic Manager selects the available algorithm that appears first in the applicable signature algorithm list. The selected algorithm must be compatible with the chosen cipher suite and with a configured certificate. The Virtual Traffic Manager chooses a signature algorithm after choosing a cipher suite.
Elliptic Curves
The Virtual Traffic Manager uses elliptic curves for ECDHE key exchange and for ECDSA authentication. The following curves are supported:
- NIST P-256 (also known as SECG secp256r1 or ANSI x9.62 prime256v1)
- NIST P-384 (also known as SECG secp384r1)
- NIST P-521 (also known as SECG secp521r1)
To restrict and prioritize the elliptic curves available for the Virtual Traffic Manager to use for ECDHE key exchange, or when signing/verifying ECDSA signatures, set system-wide preference lists in the Global Settings, or set local override lists in your virtual server and pool SSL settings.
To configure elliptic curve preference lists, see the following pages of the Admin UI:
- For administration interface and control plane connections, click System > Security > SSL Settings for Admin Server and Internal Connections and configure the "admin!ssl_elliptic_curves" setting. Leave this field blank to allow the use of all elliptic curves supported by this Virtual Traffic Manager.
- To set a global preference list for all other connections, click System > Global Settings > SSL Configuration. Use the "ssl!elliptic_curves" setting to configure an elliptic curves preference list for your virtual servers and pools. Leave this field blank to allow the use of all elliptic curves supported by this Virtual Traffic Manager.
- To override the global preference list for an individual virtual server, click Services > Virtual Servers > Edit > SSL Decryption and set "ssl_elliptic_curves" to your dedicated elliptic curves list. Leave this field blank to use the global list.
- To override the global preference list for an individual pool, click Services > Pools > Edit > SSL Settings and set "ssl_elliptic_curves" to your dedicated elliptic curves list. Leave this field blank to use the global list.
For the virtual server or pool "ssl_elliptic_curves" settings, enter the special value "default" to force the corresponding virtual server or pool to ignore any value set in the global preference list and instead use the full list of supported elliptic curves.
Client Certificates
While SSL server certificates are used to identify servers in an SSL transaction, SSL also allows for the use of Client Certificates so that clients can identify themselves when required.
By default, the Virtual Traffic Manager does not request a client certificate from clients that connect to a virtual server. If required, you can configure the virtual server to request that clients provide client certificates.
To control how clients are authenticated in an SSL transaction, use the following settings:
- request_client_cert: Specify whether the virtual server should request an identifying certificate from each client, and whether supplying a certificate should be optional or compulsory (in other words, all clients must present a valid client certificate). If request_client_cert is set to "Do not request a certificate" (the default setting), a client is prevented from sending a certificate whether it wants to or not.
- ssl_client_cert_headers: After the request has been decrypted, the Virtual Traffic Manager can optionally set HTTP headers that record the certificate fields from the SSL Certificate used:
Header Name | Sample Value |
|---|---|
SSLClientCertVersion | 3 |
SSLClientCertSerialNumber | ED41A8 |
SSLClientCertIssuer | C=US, ST=CA, L=San Jose, O=MyOrg |
SSLClientCertSubject | C=US, ST=CA, L=San Jose, O=MyOrg |
SSLClientCertNotValidBefore | 1155304575 (unixtime) |
SSLClientCertNotValidAfter | 1186840575 (unixtime) |
SSLClientCertSubjectPublicKey | RSA (2048 bit) |
SSLClientCertSignatureAlgorithm | sha256withRSAEncryption |
SSLClientCertHash | 873FECCB50E0C1D34711ABE65BA70BA7 |
SSLClientCertSHA1Fingerprint | 7D90A8EB6081183C0560970A7DA77306C40E5DD2 |
SSLClientCert (if enabled) | The entire PEM-encoded certificate text. |
- client_cas: When client certificates are in use, the Virtual Traffic Manager must be able to verify that the certificate it is given is legitimate. The Virtual Traffic Manager informs the client which CAs it trusts and the client sends a certificate signed by one of these CAs (if available). To use this setting, first configure your trusted CA certificates in the “Certificate Authorities and Certificate Revocation Lists Catalog” and then select the CAs here as required. If the client supplies a certificate that is not recognized by the CAs you specify, the Virtual Traffic Manager immediately closes the connection and sends an SSL error to the client.
The request_client_cert, client_cas, and ssl_client_cert_headers settings can be overridden if the TLS connection being made to the virtual server uses specified destination IP addresses or includes a Server Name Indication extension with specified DNS names.
Server Name Indication (SNI) is an extension defined for TLS handshakes that allows a TLS client to tell a TLS server which server it is connecting to. This can be useful if the DNS entries for several different servers resolve to the same IP address, as it allows multiple distinct applications to be served from that IP address.
Where SNI extentions are supported and used, the Virtual Traffic Manager enables you to add specific hostname or IP address mappings to apply to incoming connections. To add a mapping, use the Add hostname/IP address mapping for client authentication section.
Specify the map parameters using the following settings, then click Update to add the mapping:
Setting | Description |
|---|---|
Host or IP | This is the string used to match the incoming connection, and can be given as a DNS name if the contents of the SNI should be matched, or as an IP address if the destination IP address of the connection should be matched. In either case the "*" character can given be in place of multiple characters in the SNI or IP address being examined. |
Request Certificate | Whether the initial TLS handshake requests a client certificate. Choose from: No: No certificate request to be made. Yes, allow if absent: A certificate request to be made but to allow connection processing to continue if the client declines to provide a certificate. Yes, deny if absent: A certificate request to be made and the connection aborted if no client certificate is supplied. The option to not request a certificate can be used with connections made using TLS versions that support re-handshaking (TLS versions prior to v1.3) in conjunction with the TrafficScript functions ssl.requestCert() and ssl.requireCert(). |
Insert HTTP Headers (HTTP only) | The HTTP header fields, if any, that should be added to the request before it is sent to a pool node. Choose from: None: No header fields are inserted. Fields Only: Insert the header fields as described for ssl_client_cert_headers. Fields and PEM: As above, with the "SSLClientCert" header containing the full certificate. |
CAs | Which certificate authorities should be used in the certificate request, so that the client can decide whether it has one or more certificates issued by those authorities. Each checked certificate authority is included in the certificate request. If no certificate authorities are checked, any certificate supplied by the client is considered to authorize access and allow the connection to proceed. |
To remove a mapping, select the adjacent checkbox in the Remove column, and click Update.
The following settings allow the client certificate chain validation to ignore expiry dates for selected client certificate authorities:
- issued_certs_never_expire and issued_certs_never_expire_depth: For organizations experiencing issues with their public key infrastructure, use these settings to enable expert level control over your client certificate configuration. Use issued_certs_never_expire to define a subset of the CAs that are configured as part of the client_cas list. Ordinarily, if any certificate in a chain is expired the Virtual Traffic Manager fails to validate the chain, meaning that if a client certificate is required the TLS handshake fails. When a CA is configured under this setting, the Virtual Traffic Manager ignores the expiry of any certificates in a certificate chain that is built up to that given CA as a trust anchor. This property can be further constrained by configuring a value in issued_certs_never_expire_depth. This setting indicates how far removed from the trust anchor a certificate is permitted to be for its expiry to be ignored. The default setting is "1", meaning that only certificates directly issued by the CA are permitted to be expired in a validated client certificate chain.
Configuring OCSP
The Online Certificate Status Protocol (OCSP) can be used to check the revocation status of certificates from a centralized server called an OCSP responder. OCSP is commonly used as an alternative to Certificate Revocation Lists (CRLs). For further details, see Client Authentication.
The Virtual Traffic Manager provides a dedicated section under Virtual Servers > SSL Decryption for configuring OCSP. To configure OCSP, use the following settings:
Setting | Description |
|---|---|
ssl_use_ocsp | If set to yes, this virtual server will use OCSP to verify that client certificates have not been revoked. |
ssl_ocsp_timeout | When contacting an OCSP responder, the Virtual Traffic Manager waits for a response for the amount of time specified by this setting. If the OCSP responder has not replied within this time limit, the client's certificate will be rejected. |
ssl_ocsp_max_response_age | If an OCSP response's “thisUpdate” field is older than the number of seconds specified by this setting, the response will be considered invalid. If set to 0 (zero), the “nextUpdate” field of the response will be used to determine whether it has expired or not. If the time specified in the “nextUpdate” field of the response has passed, the response is considered invalid regardless of this setting. |
ssl_ocsp_time_tolerance | If the OCSP responder and Virtual Traffic Manager's clocks differ slightly then the times specified in the “thisUpdate” and “nextUpdate” fields of a response might cause the Virtual Traffic Manager to consider it invalid. If the responder's clock is a few seconds faster than the Virtual Traffic Manager's clock, for example, the “thisUpdate” field of a response might appear to the Virtual Traffic Manager to be in the future. This setting allows you to specify the number of seconds to permit for clock differences. |
The following OCSP responder settings are provided on a per-issuer basis. These allow you to specify different settings for certificates signed by particular issuers in the Certificate Authorities catalog.
Select a certificate authority in the Add Issuer Specific Settings section to add settings for that issuer. If the Virtual Traffic Manager receives a client certificate with an issuer that is not configured explicitly, the Default Settings will be used.
Setting | Description |
|---|---|
OCSP check | This setting is used to enable and disable OCSP checks for the issuer. Selecting 'Always' will cause remote connections to be dropped when an appropriate OCSP responder URL cannot be determined. |
Use AIA for URL | Issuers can embed an OCSP responder URL into their client certificates using the X.509 Authority Information Access extension. If this setting is enabled, and the extension is available, the Virtual Traffic Manager will use it. Otherwise it will use the Fallback URL. |
Fallback URL | If the responder URL cannot be determined by other means, this URL is used. |
Request signing certificate | OCSP requests can be signed so the responder can identify and authenticate the source of the request. You can select a certificate uploaded to the SSL Certificates catalog to sign the request, choose to use the certificate configured under Default Settings, or disable request signing. |
Use nonce extension | A unique sequence of data can be added to OCSP requests and responses to ensure an attacker cannot re-send a “good” OCSP response after a client certificate is revoked. When using the nonce extension you can require the responder to always return a nonce by using 'strict' mode. Otherwise the Virtual Traffic Manager will accept the response if it does not contain the nonce. Using this extension stops the responder from pre-generating responses to improve performance. Additionally, not all OCSP responders support this extension. If this is the case, a responder may return an 'unauthorized' response. |
Responder certificate | OCSP responses are signed by the responder to prove they are genuine. You can select a specific certificate that responses should be signed by, from those listed in the SSL Certificate Authorities catalog. You can instead configure the system to expect the response to be signed by the issuer’s certificate by selecting Issuing Certificate. Alternatively, you can select Signed by issuing certificate. This means the certificate must either be the issuer's certificate itself, or be signed by it and have the “id-kp-OCSPSigning” marker in its extendedKeyUsage extension, and also have the id-pkix-ocsp-nocheck extension. |
SSL Session Resumption
An SSL session can be defined as the details that allow a secure channel to be (re-)established between two parties – generated by a process (handshake) designed to establish the security properties required for that channel, including the secret from which all cryptographic keys used by the connection are derived. Both client and server store those details, and the server ascribes an identifier (session ID) to those details for both parties to use when referring to that specific session. If the SSL TCP connection is terminated and the client subsequently reconnects, the client can present this session ID to signal to the server that it wants to resume the previous SSL session, using the cached encryption parameters.
The Virtual Traffic Manager allows session resumption for all supported SSL/TLS versions.
The Virtual Traffic Manager manages two SSL session ID caches:
- When it is acting as an SSL server (in other words, using virtual servers with “SSL Decryption” enabled)
- When it is acting as an SSL client (in other words, using pools with “SSL encryption” enabled or when TrafficScript rules make outgoing https requests)
To modify the size and expiry time of these caches, click System > Global Settings > SSL Configuration. Update the settings ssl!cache!size, ssl!cache!expiry, ssl!client_cache!size, and ssl!client_cache!expiry for the server and client caches respectively.
To monitor the behavior of the SSL Session ID Cache, plot cache data items on the Current Activity graph, or monitor these values using SNMP. To use the Current Activity graph, click Activity > Current Activity. Then, select and plot cache data items on the graph by clicking Change data. From the list of values, expand Cache values > SSL Session ID Cache and select the desired cache data items. To update the graph, click Apply.
If the cache is full (comparing Entries with EntriesMax) and the Oldest value is significantly lower than the configured expiry time, it is likely that your cache is too small and the Virtual Traffic Manager is expiring cache entries too early. Consider increasing the cache size in System > Global Settings > SSL Configuration.
RFC 5077 (Transport Layer Security (TLS) Session Resumption without Server-Side State) introduced “session tickets” into versions of TLS earlier than 1.3. For TLSv1.3 onwards, the Virtual Traffic Manager additionally supports the more general definition of session tickets from RFC 8446 (TLSv1.3), which now fulfill the same function as both the earlier session tickets and session IDs.
Session tickets are a mechanism whereby SSL sessions can be resumed without the requirement for the server to store any state. The server instead uses a (symmetric) private key to encrypt the session information into a session ticket. All clients and network intermediaries not party to the private key cannot decrypt the contents of the ticket.
Rather than giving the client a short session ID, the server sends the client the longer session ticket. The client stores this session ticket instead of a session ID and presents it when it wants to resume the session. Provided the private key used to encrypt the ticket is still available, the server then decrypts the ticket, extracts the session information, and resumes the session with the client.
This scenario has the following advantages:
- The memory requirements for an SSL server to support session resumption are reduced.
- When multiple SSL servers act together in a cluster, if they share the ticket key, a session that was created on one server can be resumed against another server in the cluster without needing all session information to be shared between all cluster members.
The Virtual Traffic Manager supports TLS session tickets both when it is acting as a server and when it is acting as a client. When acting as a client, the session ticket is entered into the client session cache in place of a session ID, and the ticket is used to resume the SSL session instead of a session ID.
When acting as a server, the Virtual Traffic Manager must ensure that the keys used for encrypting tickets are changed sufficiently often to minimize the chances of a key becoming compromised, and to limit the damage done if one of the keys were compromised. To achieve this, the Virtual Traffic Manager automatically generates and rotates the keys used for ticket encryption.
The Virtual Traffic Manager maintains a database of historic ticket keys, each with a unique identifier. Each session ticket begins with a ticket key identifier, so when a session ticket is received by the Virtual Traffic Manager, it is able to locate the key used to encrypt that session ticket. If the Virtual Traffic Manager finds the ticket key in its database, it decrypts the session ticket and resumes the session (provided the session is valid).
Where multiple Virtual Traffic Managers join together as a cluster, the database of ticket keys is replicated across all cluster members. Each Virtual Traffic Manager in the cluster uses separate keys to encrypt the session tickets that it generates, with all current and historic keys being added to the centralized database shared between cluster members. In this way, an SSL session ticket from a client can be decrypted and resumed by any Virtual Traffic Manager in the cluster.
To configure the behavior of session tickets when the Virtual Traffic Manager is acting as an SSL server, click System > Global Settings > SSL Configuration. The following table describes the configuration settings available:
Setting | Description |
|---|---|
ssl!tickets!ticket_key_rotation | The time, in seconds, after which ticket keys are renewed. The previously used key is added to the database. |
ssl!tickets!ticket_key_expiry | The time, in seconds, after which ticket keys are deleted from the database. |
ssl!tickets!ticket_expiry | The total time, in seconds, after which a session ticket is considered expired. Any session resumption requests presented to the Virtual Traffic Manager using a ticket older than this value are refused. |
To fully disable automatic key generation and rotation of ticket keys, use the “ssl/ticket_keys” resource in the Virtual Traffic Manager REST API. For more details, see the Virtual Traffic Manager: REST API Guide. Ivanti recommends this procedure for advanced users only, with consideration for the following points:
- Ticket keys must be generated with a cryptographically strong random number generator. They must not be derived from static information like MAC addresses or serial numbers of servers.
- Ticket keys must be stored only for as short period of time as possible; if a ticket key is compromised, the forward secrecy of connections made using tickets encrypted with that key is also compromised. In particular, ticket keys should not be recorded in log files, and so on.
- When ticket keys are transmitted over a network link, they should be transmitted using ciphers that provide perfect forward security, such as ciphers using Diffie-Hellman or Elliptic Curve Diffie-Hellman key exchange algorithms.
TLSv1.3 replaces both session IDs and session tickets with a new style of session resumption (which offers improved security properties over the earlier forms). A TLSv1.3 session ticket is explicitly permitted to be either a "database lookup key" (similar to a session ID) or "a self-encrypted and self-authenticated value" (similar to a pre-TLSv1.3 session ticket).
By applying the configuration described in this section to decide whether to store a session/send a session ticket, or resume a session, the Virtual Traffic Manager considers the following actions equally based on the TLS version:
TLSv1.2 and Earlier | TLSv1.3 Onwards |
|---|---|
Saving a pre-TLSv1.3 session to the session cache and sending a session ID to the client | saving a TLSv1.3 session to the session cache and sending a ticket containing the lookup key |
Looking up a session from a pre-TLSv1.3 session ID | looking up a session from a ticket containing a lookup key |
Generating/parsing a pre-TLSv1.3 session ticket | generating/parsing a TLSv1.3 encrypted ticket The same ticket encryption keys are used for pre-TLSv1.3 and encrypted TLSv1.3 session tickets |
OCSP Stapling Cache
The Virtual Traffic Manager maintains a cache of OCSP responses for server certificates used by virtual servers that have ssl_ocsp_stapling enabled.
In the System > Global Settings > SSL Configuration section of the Admin UI, you can configure the Virtual Traffic Manager's OCSP response caching behavior:
- Set the size of the cache with ssl!ocsp_stapling!mem_size.
- Use ssl!ocsp_stapling!default_refesh_interval to control how long the Virtual Traffic Manager waits before making a new OCSP request, if no response with a "nextUpdate" time in the future is available in the cache.
- Use ssl!ocsp_stapling!maximum_refresh_interval to define the maximum interval that can elapse between OCSP requests. After a valid OCSP response is received, the next update is made this many seconds in the future, unless the "nextUpdate" time in the OCSP response is sooner.
- The Virtual Traffic Manager provides a signature verification option ssl!ocsp_stapling!verify_response. Set this to Yes to force the Virtual Traffic Manager to verify the signatures and validity periods of OCSP responses before using them for stapling. If verification fails, the Virtual Traffic Manager never uses the response for OCSP stapling.
- An OCSP response has a validity period defined by two fields in the OCSP response: "thisUpdate" and "nextUpdate". When ssl!ocsp_stapling!verify_response is enabled, responses outside this period are not cached and therefore not stapled. In some environments, clock skew might be a concern. This can cause the local current time to appear to be earlier than the "thisUpdate" field in the OCSP response, causing an incorrect validity failure. Use the ssl!ocsp_stapling!time_tolerance setting to define an allowed time margin (in seconds) outside this interval when the Virtual Traffic Manager should still consider responses to be valid.