SSL Profiles Part 9: Server Authentication

This is the ninth article in a series of Tech Tips that highlight SSL Profiles on the BIG-IP LTM. 

1. SSL Overview and Handshake
2. SSL Certificates
3. Certificate Chain Implementation
4. Cipher Suites
5. SSL Options
6. SSL Renegotiation
7. Server Name Indication
8. Client Authentication
9. Server Authentication
10. All the "Little" Options

This article will discuss the concept of Server Authentication, why it's important, and how the BIG-IP system allows you to configure it for your environment.

Server Authentication

During a TLS handshake, a client and server exchange information and ultimately create a secure (encrypted) connection.  My previous article in this series (client authentication) discussed the need for the server to authenticate the client.  Many customers want to know that the correct user is accessing their server, so client authentication is important for them.  Well, in many cases, the same is true on the client side.  If a client accesses a server, he wants to know that he is connected to the right server.  While the TLS handshake establishes a secure connection between the client and server, it does not inherently prove that the client has connected to the correct server.  Server authentication is a feature that allows the client to know that he is accessing the correct server.

To illustrate the concept of server authentication, let's start with a simple example of a client connecting to a server using the TLS handshake.  But, in this example, let's say another server steps in and attempts a "man in the middle" attack on the connection.  This scenario is illustrated in the following diagram.

In this scenario, the client wants to establish a secure connection with Server 1.  But Server 2 intercepts the connection request and sends its certificate back to the client instead.  In the meantime, Server 2 establishes it's own secure connection with Server 1.  When the client receives the certificate from Server 2, it checks the certificate against its list of trusted Certificate Authorities (CA).  Since the certificate from Server 2 is signed by a trusted CA, the client establishes the secure connection.  For more on SSL certificates, see article 2 of this series.

Now that Server 2 has a secure connection with the client and Server 1, he can intercept (and manipulate) all subsequent communications between the two.  So far nothing has violated the TLS protocol, but we still have a problem, right?  After all, the client is connected to the wrong server!  I probably don't have to spend too much time convincing you this is less than ideal.  A quick example using your personal or business bank website should be more than enough evidence to prove that we need to do something about all this.

The Server Authentication feature has been introduced to help avoid these problems.  As discussed earlier, server authentication provides a way for the client to know that he is connected to the correct server.  In server authentication, the client establishes a secure connection with the server using the TLS handshake, but before the client sends any data it checks to make sure the Common Name [CN] of the server matches the CN of the certificate.  If these names don't match, the client terminates the session immediately.  The following diagram shows this process.

In this example, the client initiates a TLS handshake with Server 1, but the handshake is intercepted by Server 2.  As in the previous example, Server 2 acts as a "man in the middle" and is potentially able to manipulate data flowing to/from the client and Server 1.  When server authentication is used, the client will inspect the CN of the certificate it receives and compare it to the CN of the server it is trying to reach.  In this example, let's say the CN for Server 1 is www.server1.com and the CN for Server 2 is www.server2.com.  When the client receives the server certificate as part of the TLS handshake process, the CN on the certificate will say www.server2.com.  When the client compares that CN to the server he was trying to reach (www.server1.com), the CN will not match and the connection will be terminated immediately.  This protects the client from establishing a connection with an unknown server.

BIG-IP Configuration

Now that we've established the foundation for server authentication, let's figure out how the BIG-IP is set up to handle this feature.  The following screenshot shows the user interface for configuring Server Authentication.  To get here, navigate to Local Traffic > Profiles > SSL > Server.

The Server Certificate setting specifies the way the system handles server certificates and has two values: Ignore and Require. The Ignore value is the default and it specifies that the system ignores certificates from server systems.  The Require value specifies that the system requires a server to present a valid certificate.  These settings effectively turn on and off the server authentication feature of the BIG-IP.  If you select Require as the Server Certificate value, you will also need to specify a value in the Authenticate Name setting as well. A blank Authenticate Name field means that every server is authenticated even though you have specified Require as the Server Certificate value.

Expire Certificate Response Control specifies how to handle connections from a client whose server certificate is expired. The two values for this setting are Ignore and Drop.  The Ignore value specifies that the system ignores the expired server certificate and still allows the connection.  The Drop value is the default and it specifies that the system drops connections with expired server certificates.

Untrusted Certificate Response Control specifies how to handle connections from a server whose certificate is untrusted (i.e. signed by an invalid CA). The two values for this setting are Ignore and Drop.  The Ignore value specifies that the system ignores the untrusted server certificate and still allows the connection.  The Drop value is the default and it specifies that the system drops connections from servers with untrusted certificates.

Frequency specifies the frequency of server authentication for an SSL session. This setting offers two values: Once and Always.  The Once value is the default and it specifies that the system will authenticate the server only once for an SSL session.  The Always setting specifies that the system will authenticate the server once when the SSL session is established as well as each time the session is reused.

The Retain Certificate box is checked by default.  When checked, the server certificate is retained for the SSL session.

Certificate Chain Traversal Depth specifies the maximum number of certificates that can be traversed in a server certificate chain to find a trusted CA. The default for this setting is 9.  For more on certificate chains, see article 3 of this SSL series.

Authenticate Name specifies a CN that is embedded in a server certificate.  The BIG-IP authenticates a server based on the specified CN.  The CN must be a valid Fully Qualified Domain Name [FQDN], so the Authenticate Name must also be a FQDN.  Remember, if you select the Require value in the Server Certificate setting, you should also specify a value in the Authenticate Name setting as well.

The Trusted Certificate Authorities setting is used to specify the BIG-IP's Trusted Certificate Authorities store.  These are the CAs that the BIG-IP trusts when it verifies a server certificate that is presented during server authentication.  The default value for the Trusted Certificate Authorities setting is None, indicating that no CAs are trusted.  Note that if the Server Certificate menu is set to Require and the Untrusted Certificate Response Control is set to Drop, you must select an option other than None for the Trusted Certificate Authorities setting...otherwise, all SSL connections will be dropped.  The drop down list in this setting includes the name of all the SSL certificates installed in the BIG-IP's /config/ssl/ssl.crt directory.  A newly-installed BIG-IP system will include the following certificates:  default certificate and ca-bundle certificate.  The default certificate is a self-signed certificate used when testing SSL profiles. This certificate is not appropriate for use as a Trusted Certificate Authorities certificate bundle.  The ca-bundle certificate is a bundle of CA certificates from most of the well-known PKIs around the world.  This certificate may be appropriate for use as a Trusted Certificate Authorities certificate bundle.  However, if this bundle is specified as the Trusted Certificate Authorities certificate store, any valid client certificate that is signed by one of the popular Root CAs included in the default ca-bundle.crt will be authenticated.  This provides some level of identification, but it provides little access control since almost any valid client certificate could be authenticated.  If you want to trust only certificates signed by a specific CA or set of CAs, you should create and install a bundle containing the certificates of the CAs whose certificates you trust.  The bundle must also include the entire chain of CA certificates necessary to establish a chain of trust.  Once you create this new certificate bundle, you can select it in the Trusted Certificate Authorities drop down menu. 

The Certificate Revocation List (CRL) setting allows you to specify a CRL that the BIG-IP will use to check revocation status of a certificate prior to authenticating a server.  If you want to use a CRL, you must upload it to the /config/ssl/ssl.crl directory on the BIG-IP.  The name of the CRL file may then be entered in the CRL setting dialog box.  Note that this box will offer no drop down menu options until you upload a CRL file to the BIG-IP.  Since CRLs can quickly become outdated, you should use either OCSP or CRLDP profiles for more robust and current verification functionality.

Conclusion

Well, that wraps up our discussion on Server Authentication.  I hope the information helps, and I hope you never establish a secure connection with a malicious web server again! 

Be sure to come back for our last article in the SSL series.  As always, if you have any questions, feel free to comment here or contact us directly atDevCentral - Contact Us.