Client Certificate Authentication in SSL/TLS and its interaction with Web Application Firewalls

In a previous blog post I discussed about Client Certificate Authentication and possible implementation methods. In this post I’m going to delve deep into TLS protocol implementation, specifically the Client Certificate part. During the setup of Client Certificate Authentication on a web application I faced various issues and when a piece of technology is just a black box in your view, there’s not much tuning or debugging that can take place when things stop working. So I spent a handful of time studying the underlying technology and I’m sharing the gist of it here.

I’m also going to briefly go through the process of enabling “SSL Proxy” feature on F5 BIG-IP and deploy the device as a WAF and Load Balancer.

Two Factor Authentication In Conjunction With Web Application Firewalls [Skip to Implementation]

If your application is vital enough that you’re thinking about using two factor authentication and client certificates, chances are that you’re also going to invest in a WAF (Web Application Firewall) along with other network security and monitoring devices. This was true in our case. Unfortunately there are not so many WAFs that support Client Certificate Authentication. I learned this the hard way. We piloted a WAF which was able to offload SSL so the topology looked like this:

Client <—HTTPS—> WAF <—HTTP—> Web Server

SSL Offloading is a common feature offered by WAFs which enables you to serve your site over https and have the WAF handle the encryption/decryption of data so there’s less computational stress on your webservers. The cryptographic methods are sometimes implemented at circuit level known as ASICs which will give you better performance. This is also known as SSL Acceleration. Some WAFs let you encrypt the traffic again and your webserver will still have to decrypt the traffic. The WAF that we were testing didn’t offer this feature out of the box.

When setting up client certificate authentication on IIS server, it’s required to have SSL enabled. So obviously the scenario above wasn’t going to work. Our initial guess was that if we could encrypt the traffic again at WAF’s internal interface and deliver it to IIS things would work fine. I decided to dig deeper into this hypothesis so I started searching the web and got to the following results:

• https://blogs.technet.microsoft.com/nettracer/2013/12/30/how-it-works-on-the-wire-iis-http-client-certificate-authentication/

This looked exactly like what I was looking for, a packet capture of client certificate authentication.

The link said that there’s something going on with SSL protocol, and client certificates are handled as a part of it as shown in the image below:

As seen above the “Certificate Request” is part of the Handshake Protocol, I kept searching for more information and got to an article titled “How SSL/TLS Works?” which dated back to 2003. This article turned out to be one of the best sources of information on this topic which depicted clearly how the protocol works.

TLS Record Protocol and TLS Handshake Protocols

As defined in RFC 5246, TLS Protocol v1.2 there are two sub protocols for TLS, one being the handshake protocol and the other being the record protocol.

“SSL/TLS Protocol” messages are show below in the form of Sender -> Receiver, messages that are directly related to “Client Certificate Authentication” are marked as red:

1. Client -> Server: “Client Hello” message which contains:

• Version Number (SSL 2.0/3.0, TLS 1.0, 1.1, 1.2)
• Client Random (4 byte number: client’s date and time + 28byte csprng, used later on to calculate Master Secret)
• Session Id (Optional, used to resume sessions to prevent recalculation of CPU intensive cryptographic calculations)
• Cipher Suite (List of cipher suites supported by the client in order of preference, e.g TLS_RSA_WITH_AES_256_SHA)
• Compression Algorithm (Optional)

2. Server -> Client: “Server Hello“:

• Version Number (Highest number supported by both sides)
• Server Random (4byte number: server’s date and time + 28byte csprng, used along with client random to generate Master Secret)
• Session id (New Session Id, Resumed Session Id, Null)
• Cipher Suite (Chosen by server, supported by client and server)
• Compression Algorithm (If used)

2.1. Server Certificate:

• Server’s Certificate List (First certificate in list contains server’s public key)
• Other validation certificates (Except for root)

2.2. Server Key Exchange Message (Optional):

2.3. Client Certificate Request Message (Optional):

• List of Accepted CAs (The client has to send client certificates signed by one of these CAs)

2.4. Server Hello Done

3. Client->Server: Client Certificate Message (Required if requested):

• Client certificate requested by the server

3.1. Client Key Exchange:

• Client’s protocol Version
• Pre Master secret (Client generated number encrypted by servers public key)

3.2 Certificate Verify Message (Required if Client Certificate is sent)

• For RSA, the signature consists of:
  • MD5 hash of all previous handshake messages
  • SHA-1 hash of all previous handshake messages
  • Both hashes are concatenated and encrypted with client’s private key
• For DSS, the signature consists of:
  • SHA-1 hash of all previous messages
  • Encrypted with client’s private key

3.3. Change Cipher Spec:

• Informs the server that all future messages including Client Finished message are encrypted using keys and algorithms just negotiated.

4. Server-> Client: Server Finished:

• Notifies the client that server will begin encrypting messages with the keys that were previously negotiated.
• Server switches to record layer with symmetric encryption using session keys.

4.1. Finished:

• This message is a hash of entire exchange to this point using the session key and MAC secret, if the client can decrypt this message and validate its hashes then the handshake was successful and the keys computed by client match those of the server.

5. Application Data Flow

Is Client Certificate Authentication and Traffic Inspection at WAF Even Possible?

The answer is, yes!

Item 3.2 in TLS protocol definition simply tells us that TLS traffic that contains Client Certificates contains session specific data and dealing with it requires much more than simply decrypting and re-encrypting the traffic at WAF and sending it to the web server. At this point after discussing this information with the companies’ developers they estimated that implementing this feature in their WAF is going to take some time and effort. So we started looking for alternatives.

After some research I found some devcentral (F5) forum posts claiming that iRules can be used in order to read the client certificate and add a custom header to http requests which the webserver could interpret and authenticate the clients. This would require the web application to undergo some changes in its authentication mechanism and was not the perfect solution. Under one of these posts someone said that in newer firmware versions of BIG-IP you can use a feature called “Proxy SSL” to have an end-to-end SSL session to your webserver and not worry about client certificates. This was the thing! (Youtube video explaining Proxy SSL Feature)

The design for SSL’s client certificate authentication prevents you from doing a man-in-the-middle at your WAF or any other intermediary device. What F5 Big-IP does is that takes the server’s certificates and keys from you asks you to disable ephemeral keys allowing only RSA to be used and then it gets to decrypt the SSL session and inspect the traffic applying its WAF rules while leaving the main traffic intact and the channel between client to IIS doesn’t get tampered with.

Implementing F5 Big-IPs Proxy SSL Feature

It’s rather easy to setup Big-IP using a guide like this. Briefly speaking the steps are as follows:

1. Setup your “Nodes”
   1. For now let’s assume there is one node (web server) and there’s no load balancing
   2. Enter a name for the node and its ip address
2. Setup a “Pool”
   1. Enter in a name for the pool and under the members tab add your Node
3. Setup a “Virtual Server”
   1. Enter in your source addresses (normally 0.0.0.0/0 which means any)
   2. Enter your destination address and port (ip address you assigned to your VS and https port)
   3. Import your SSL Certificates onto your BIG-IP device and import them here as client and server SSL. (Refer to SSL Profiles)
   4. Set Source Address Translation to Auto Map
   5. Under Resources tab select your pool and your policies (ASM Policies)

Creating SSL Profiles

Under Local Traffic>Profiles>SSL, you need to create both the Client and Server SSL Profiles.

First you need to import your SSL Certificates to your BIG-IP. Export them from your web server along with its private key and import them to your device.

Creating Client SSL Profile:

1. Choose your parent profile to be clientssl
2. Select advanced configuration mode and add your Certificate Key Chain imported earlier onto the device (This is the certificate used by your web server)
3. Set ciphers as “default” (List of default ciphers can be found here, this is firmware version specific)
4. Check the “Proxy SSL” box
5. If you want to passthrough the traffic in case BIG-IP fails to decrypt the ssl session check “Proxy SSL Passthrough”

Creating Server SSL Profile:

1. Choose your parent profile to be serverssl
2. Select your certificate and key (This is the certificate used by your web server)
3. Set ciphers as “default”
4. Check the “Proxy SSL” box

The Virtual Server has to use these profiles. Client SSL Profile is responsible for the traffic between the client (end-user) and BIG-IP while the Server SSL Profile is responsible for the traffic between BIG-IP and your web server.

Disabling Diffie-Hellman and Ephemeral Keys on web server

In order for BIG-IP to be able to decrypt and inspect the traffic you have to disable DH and Ephemeral Keys. I’ll show you how to do this under Windows Server/IIS, the same procedure has to be done for Apache, Nginx and other web servers.

Configuring IIS

SSL settings, namely versions, cipher suites, key exchange algorithms and hash functions are configured in Schannel under registry. One easier method for modifying these settings is to use Nartac IIS Crypto software to set things up using the GUI.

As depicted, only RSA cipher suites are left enabled along with PKCS key exchange algorithm.

Now your users can use their client certificates to authenticate themselves to the web server while BIG-IP ASM is actively applying rules and signatures to the traffic.