You know about SSL/TLS certificates. You know that they’re pretty damn important. And you also know that they’re installed on servers. But what if we turn the tables and install an SSL cert on your PC? Sounds cool? Well, it is. Typically, SSL/TLS certificates are installed on servers, and that’s why some call them “SSL server certificates.” But not many are aware of SSL/TLS with client authentication.
SSL/TLS client authentication, as the name implies, is intended for the client rather than a server. In server certificates, the client (browser) verifies the identity of the server. If it finds the server and its certificate are legitimate entities, it goes ahead and establishes a connection. The entire process happens during SSL/TLS handshake.
Now, let’s turn the tables.
What if a server does a client’s verification? Sounds unheard of? Well, it’s a thing. SSL/TLS client authentication works pretty much the same way as SSL server authentication—but in the opposite direction.
In client authentication, a server (website) makes a client generate a keypair for authentication purpose. The private key, the heart of an SSL certificate, is kept with the client instead of the server. It’s stored in the browser. The server confirms the authenticity of the private key and then paves the way for secure communication.
Where it can be used?
The typical application of client authentication is where one wants to restrict the access to authenticated users. This is very helpful against attacks emitting from outside sources. Attackers tend to play the imitation game by stealing users’ credentials. It’s no secret that passwords aren’t good enough; you need more than that. That’s why technologies such as two-factor authentication are on the rise.
This is precisely where client authentication comes in.
As only the client is in possession of the private key, the need of the password can be eliminated. However, we don’t recommend it. If you want best results, using both together can give you top-notch security that is extremely hard to crack in.
Another splendid use of client authentication can be done in IoT devices. In a massive IoT infrastructure, you can issue one certificate for each device to eradicate the possibility of unauthorized access.
In a client handshake, after the client hello and server hello messages, the server requires the client to present itself with a certificate. The server then verifies it, and encryption takes place through symmetric encryption.
Why isn’t it popular?
The TLS based client authentication looks great on paper, but when it comes to walking the walk, it disappoints us. There are plenty of reasons behind this. Here are some of them:
Lack of convenience: As we said, a client certificate is stored in a browser. This limits its usage to one particular system. In a day and age when we have plenty of devices on our hands, this becomes inconvenient. And what if that device stops working? What if it gets stolen?
Complex for ordinary users: When it comes to installing SSL certificates on servers, it’s server administrators who are in command. They have the technical capability to configure and manage it. On the other hand, deploying client certs on a larger scale requires ordinary users to do the technical stuff. It’s asking too much from most of the users.
Two-factor authentication: To counter against the pitfalls of passwords, we’ve come up with two or multi-factor authentication. Unlike client authentication, MFA is pretty easy-to-use. That’s why we’re witnessing a rapid adoption of it almost everywhere. As 2-FA does the job, most organizations don’t feel the need or desire to get client authentication involved.
To put it in simple terms, TLS client authentication has a lot of moving parts. Unless some of them get fixed (highly unlikely), most users will stay unaware of this excellent-yet-impractical method.