TLS Client Authentication

One of the objectives (3.02) on the 301a exam blueprint talks about how to configure the various different SSL profile settings. One feature that you will struggle to find (or at least I have) utilised outside of some relatively focused and specialised situations, is that of Client Authentication (sometimes referred to as 'mutual TLS authentication').

Unlike the bog standard TLS connection we've all come to know and love whereby the client authenticates or verifies the server's certificate, Client Authentication works by the server requesting the client's certificate to verify. Madness.

The resulting TLS (v1.2) exchange ends up looking something like this, note the Client Certificate Request four steps down:

So why is this not used everywhere? This does appear to add another layer of security into the mix, although this has been debated. The most likely answers are that commercially, for most websites, this level of authentication is not needed. You also have to deploy this on mobile platforms which I would imagine would add a further layer of headache.

In business, however, there are times when it is beneficial, or even mandated by policy, that this form of 'mutual TLS authentication' is required. Business-to-business (B2B) transactions are a good example of where this technology might be employed. In fact, I know this because we implement mutual TLS authentication with some of our B2B partners. If a B2B partner wishes to consume some service within our network, the TLS handshake requires both parties to present and verify their certificates, anchored by a common 3rd party CA.

LTM TLS Client Authentication

So with that, we have the Client Authentication section of the Client SSL Profile on the LTM. This feature is disabled by default, that is, disabled on the parent clientssl profile. When enabled you get by default, the following settings which as they stand don't actually do very much. Indeed, enabling the feature without modifying is as practically useful as not enabling it at all. So you need to do something with it.

The first setting - Client Certificate has options thrice:

• Ignore (default): ignores any certificate presented and will not authenticate the client.
• Request: the system will request a certificate but will still establish a TLS session regardless of whether a valid certificate from a trusted CA is presented. Typically used alongside an iRule.
• Require: enforces client authentication. A session is established only if a valid cert from a trusted CA is presented.

For the purposes of this demonstration I will set this to require as this allows us to easily see what this feature actually does.

The next setting Frequency tells the system how often the client should authenticate a TLS session.

The Certificate Chain Traversal Depth  (default is 9) specifies how many certificates in the certificate chain presented to the LTM it should look through. For clarity, a chain represents the list of certificates from the root certificate all the way up to the end-device certificate itself. Here is an example of Amazon's certificate chain:



The Trusted Certificate Authorities setting allows you to specify which trusted CAs the LTM can use to verify the client certificate. It is here you'll probably want to take some further action to enhance the security posture of the overall connection. If you choose the system supplied ca-bundle you're widening, quite dramatically, the scope of what can be used to verify and ultimately trust the client certificate. For the purposes of this demonstration I have limited this to my lab CA server.

The Advertised Certificate Authorities setting allows you to specify to the client which CAs the server trusts. The use of this setting is optional and in most cases you won't actually need it. Firstly, in advertising a long list of CAs you increase the size of the TLS handshake message which is limited to 14,304 bytes. There may be limited cases where this setting is required as F5 K9839 describes. For the purposes of this demonstration I'll set this to the same CA as per the Trusted Certificate Authorities setting.

Finally, the Certificate Revocation List (CRL) allows you to specify a CRL file the LTM can use to verify the client certificate has not been revoked. The problem with using CRLs is the management overhead of constantly having to update them. An OCSP authentication profile may work better, however, I hang my head in shame as I have yet to successfully get this to work. The OCSP transaction is successful but the LTM resets the connection as soon as it gets back the OCSP response.

Putting it altogether we have the following profile:


Now when I (successfully) connect to the virtual server, in addition to the LTM sending the Certificate Request to the client it also sends across the CAs it will use to authenticate the session using the Distinguished Names parameter as shown:


If things go a little awry F5 have written a handy troubleshooting guide.

There is another thing to think about when using client authentication and that is of the end-user experience. In an enterprise environment a user may have more than one certificate in their personal certificate store that can be used for client authentication. I, for example, have two:



When a user targets an LTM virtual server configured for client authentication their browser may prompt them to select a certificate to use. This is the default behaviour for most browsers and looks something like this (Firefox prompt):


The choice of browser will determine what happens next. In Internet Explorer you can change a setting that tells IE not to prompt the user for a certificate selection if there is only one certificate in the Security Settings:


If there are more than two certificates then the user will always be prompted by IE.

In Firefox the behaviour is slightly different. You can set Firefox to automatically select a certificate:



When a connection is made Firefox will (unsurprisingly) automatically select one of the certificates. This behaviour may not be desirable as you may have certificates by more than one CA in the personal certificate store.

Chrome is a different beast as there is no obvious setting as per the other two browsers. I've done some digging around and it looks like a registry tweak to the AutoSelectCertificateForUrls is required although I haven't actually tested this out.

Summary

TLS Client Authentication on the LTM is fairly straightforward to setup and works well. The real challenge with this technology is a policy and process one. For example, if you need to make changes to the browser settings as above then obviously this will need to be discussed with your customers or your own group security department first to get buy-in.