When you create a Client SSL profile, you can specify OCSP stapling to improve the certification response time. OCSP stapling is when a TLS server (acting as OCSP client) asks the OCSP server for a valid revocation status of its TLS certificate ahead of time and "staples" the signed OCSP response to the TLS handshake. The TLS client sees the stapled OCSP response and verifies the signature, thus validating the TLS server’s certificate and eliminating the round trip at the client for fetching the certificate status. It also helps protect the identity of the client.
By default, OCSP stapling is disabled. You can enable OCSP stapling by selecting an OCSP Stapling profile, when you create a Client SSL profile. There is no default OCSP Stapling profile, so you must create one that specifies the parameters you want to use. For example, the default OCSP stapling profile setting is to use a DNS resolver to fetch the OCSP response, and you must specify the DNS resolver to use. Alternatively, you can choose to use a proxy server to fetch the OCSP response, and then you must specify the proxy server pool. After you create and save an OSCP Stapling profile, it appears in the OCSP Stapling Parameters list on the Client SSL profile screen.
|Select||If you want the BIG-IP system to use the Proxy Server Pool. Use when there are one or more servers that can proxy a HTTP request to an external server and fetch the response.|
|Clear (default)||If you want to use the DNS Resolver. Use when the OCSP responder can be reached on one of BIG-IP interfaces.|
You can manage the way that the BIG-IP system processes SSL application traffic by configuring two types of SSL profiles: A Client SSL profile, a Server SSL profile, or both. These profiles affect the way that the system manages SSL traffic passing through the system.
When you configure Client SSL or Server SSL profiles and assign them to a virtual server, the BIG-IP system offloads SSL processing from the destination server. This offloading not only conserves resource on destination servers, but enables the BIG-IP system to customize SSL traffic processing according to your configuration specifications.
When you want the BIG-IP system to process application traffic over SSL, you can configure the system to perform the SSL handshake that destination servers normally perform. This ability for the BIG-IP system to offload SSL processing from a destination server is an important feature of the BIG-IP system.
The most common way to configure the BIG-IP system is to create a Client SSL profile, which makes it possible for the BIG-IP system to decrypt client requests before sending them on to a server, and encrypt server responses before sending them back to the client.
Within a Client SSL profile specifically, you can specify multiple certificate/key pairs, one per key type. This enables the system to accept all types of cipher suites that a client might support as part of creating a secure connection. The system then decrypts the client data, manipulates any headers or payload according to the way that you configured the Client SSL profile, and by default, sends the request in clear text to the target server for processing.
For those sites that require enhanced security on their internal network, you can configure a Server SSL profile. With a Server SSL profile, the BIG-IP system re-encrypts the request before sending it to the destination server. When the server returns an encrypted response, the BIG-IP system decrypts and then re-encrypts the response, before sending the response back to the client.
The BIG-IP system supports a large set of cipher suites that offer various combinations of encryption algorithms and authentication mechanisms, including RSA (Rivest Shamir Adleman), DSA (Digital Signature Algorithm), and ECDSA (Elliptic Curve Digital signature Algorithm).
Within an SSL profile, you can specify either a particular string to indicate the cipher suites that you want the BIG-IP system to use or not use for SSL negotiation. If you do not specify a cipher string, the BIG-IP system uses the default cipher string, DEFAULT. Examples of cipher values that you can specify are: ECDHE, or DEFAULT:!ECDHE. The ECDHE and DEFAULT:!ECDHE values instruct the BIG-IP system to either negotiate with elliptic curve Diffie-Hellman Ephemeral (DHE) cipher suites, or negate the use of those cipher suites.
It is important to note that if you are assigning both a Client SSL and a Server SSL profile to the virtual server, the connections on each side of the BIG-IP system must use common ciphers. Otherwise, the handshake between the virtual server and the server fails and the connection closes.
The list of supported ciphers that you can specify varies depending on whether the transport layer being used is TCP or UDP.
For client-side traffic specifically, you can configure a Client SSL profile to specify multiple certificate key chains on the BIG-IP system, one for each key type: RSA, DSA, and ECDSA. By configuring a Client SSL profile with different digital certificates and keys, the system can accept all types of cipher suites that clients might request as part of creating a secure connection. The system supports OCSP stapling for all certificate and key types.
The BIG-IP system supports a large suite of ciphers. Some of these ciphers are included in a default cipher suite named DEFAULT. The DEFAULT cipher suite appears as the default value in the Ciphers setting of the Client SSL and Server SSL profiles.
If you want the BIG-IP to accept ciphers that are not included in the DEFAULT cipher suite, or you want the system to reject ciphers that are included in the DEFAULT cipher suite, you can configure an SSL profile accordingly.
You perform this task when you want to display the entire list of ciphers included in the DEFAULT cipher set.
This table lists the RSA ciphers in the DEFAULT cipher suite that include AES, DES, and RC4 ciphers.
This table lists all ECDHE ciphers in the DEFAULT cipher suite. In the DEFAULT cipher suite, Elliptic Curve (EC) ciphers are the only ciphers that include DHE as the key exchange method.
The BIG-IP system supports the Diffie-Hellman Ephemeral key exchange method, as well as other Diffie-Hellman variations. A Diffie–Hellman key exchange method is an alternative to RSA key exchange and allows the client and the BIG-IP system to establish a shared secret session key to use for communication.
The BIG-IP system supports all three Diffie-Hellman key exchange methods. They are:
The Diffie-Hellman Ephemeral (DHE) key exchange method provides Perfect Forward Privacy (PFP). With standard Diffie-Hellman, multiple key exchanges all use the same session key, which can compromise security. By contrast, DHE uses PFP, which generates a disposable key per session and thereby ensures that the same session key is never used twice. No key remains to be disclosed, and if the private key of the server is discovered, past communication remains secure.
Because Diffie-Hellman key exchange methods do not include authentication, use of Diffie-Hellman Ephemeral (DHE) requires that it be paired with an authentication mechanism. The DHE ciphers that the BIG-IP system supports are:
The BIG-IP system supports Elliptic Curve Cryptography (ECC). Because Elliptic Curve key sizes are significantly smaller than those of other key types, ECC is ideally suited for smaller, mobile devices for which key storage is an issue. On the BIG-IP system, ECC works with the SSL offload feature.
The BIG-IP system supports multiple ciphers that use Elliptic Curve Cryptography (ECC) encryption with Diffie-Hellman key exchange. On the BIG-IP system, EC is used with DHE to establish the shared secret; however, the subsequent bulk encryption of data cannot be done with any ECC-based algorithm and must be done using conventional crypto algorithms such as AES and 3DES. For example, a typical Elliptic Curve cipher is: ECDHE-RSA-AES128-CBC-SHA.
The specific ECC ciphers that the BIG-IP system supports are:
Because ECC with Diffie-Hellman does not include a mechanism for digitally signing handshake messages, the RSA or DSA algorithms are used to digitally sign the handshake messages to thwart Man-in-the-Middle attacks. For example, an ECDHE-ECDSA-* cipher suite uses the ECC DSA certificate specified in the Client SSL profile to digitally sign the handshake messages.
There are several settings that you can configure on an SSL profile to manage client-side SSL authentication.
You can cause Local Traffic Manager to handle authentication of clients or servers in certain ways. For client-side processing, the possible behaviors are:
For server-side processing, the possible behaviors are:
You can configure an SSL profile to require authentication either once per SSL session (once), or once upon each subsequent re-use of an SSL session (always). The default setting for this option is once.
Whether you set this value to once or always depends on your application. A well-designed web application should need to verify a certificate only once per session. F5 recommends for performance reasons that you use the default setting (once) whenever possible.
You can modify the SSL profile to require authentication not only once per session, but also upon each subsequent re-use of an SSL session.
You can use the Certificate Chain Traversal Depth setting of an SSL profile to configure the maximum number of certificates that can be traversed in the certificate chain. The default value is 9. If a longer chain is provided, and the client has not been authenticated within this number of traversals, client or server certificate verification fails. If the authentication depth value is set to zero, then only the client or server certificate, and one of the chain files, are examined.
For client-side and server-side SSL processing, you can use the Trusted Certificate Authorities setting on an SSL profile to configure an SSL profile to verify certificates presented by a client or a server. You can specify a client trusted CAs file name, which the BIG-IP system then uses to verify client or server certificates. If you do not configure a trusted CAs file, the system uses a default file.
The trusted CAs file that you specify for certificate verification contains one or more certificates, in Privacy Enhanced Mail (PEM) format. Built manually, this file contains a list of the client or server certificates that the SSL profile will trust. If you do not specify a trusted CAs file, or the specified trusted CAs file is not accessible to the BIG-IP system, the system uses the default file name.
For client-side profiles only, if you intend to configure the SSL profile to require or request client certificates for authentication, you will want the profile to send to clients a list of CAs that the BIG-IP system is likely to trust.
This list, known as the Client Certificate CA file, is different from the client Trusted CAs file. This is because, in some cases, you might have a client that does not possess a valid client certificate, in which case you might not want to reveal the actual list of CAs that the BIG-IP system trusts. The client certificate CA file solves this problem by allowing the BIG-IP system to advertise a list of CAs that is different from the actual client trusted CAs file configured as part of certificate verification.
Although the contents of the Client Certificate CA file can differ from that of the Client Trusted CAs file, it is best, for compatibility reasons, to set the Advertised Certificate Authorities setting to match the Trusted Certificate Authorities setting. This is because modern browsers might not permit SSL session negotiation to proceed if the peer that requests the client certificate does not provide a list of trusted CAs.
For server-side profiles only, Local Traffic Manager supports name-based authentication, which guards against man-in-the-middle attacks. When you configure the Authenticate Name setting for a server-side profile, Local Traffic Manager checks the name against the Common Name (CN) listed in the certificate that the target server presents to the BIG-IP system. If the name attribute that you specify does not match the CN in the server certificate, Local Traffic Manager closes the connection. An example of a CN is www.f5.com.
The Certificate Revocation List (CRL) setting of an SSL profile allows Local Traffic Manager to use CRLs to check revocation status of a certificate prior to authenticating a client or server.
As an alternative to using CRLs, you can use the Online Certificate Status Protocol (OCSP) feature, which ensures up-to-date information on certificate revocation status.