IT Security Notes

While religion is totally irrelevant in security, this quote is fun nonetheless:

In God we trust
Everyone else must have an X.509 certificate.

Intro
Secure applications use HTTPS for transport to ensure privacy and integrity. SSL used in HTTPS encrypts and signs all communication between the client and the server.

In a classic HTTPS connection, the client verifies the authenticity of the server X509 certificate (a.k.a. SSL Certificate) by ensuring that all the signatures in the "chain of trust" are valid and all the signer's certificates are trusted. This step is simply to ensure that the server is really who it claims to be. What we are going to discuss is the use of the same method to authenticate the client.

It's not new, it has been there for as long as SSL exists in fact. It's just that very few people use it, or know how it works. Some choose not to use it because of the drawbacks.

How does it work?
An SSL session always, like all polite protocol conversations, begins with formal introductions (think of it as an exchange of name-cards...). The process is called an SSL handshake.

The SSL handshake allows the server to "present" itself (authenticate itself) to the client by using public-key techniques. The client and server then cooperate in creating symmetric keys that will be used for encryption, decryption, and integrity validation during the SSL session that follows. The SSL handshake also allows the client to authenticate itself to the server, which is the part that interests us really.

There is no need to explain in details how it works when others do it so well... A regular SSL handshake involves the server authenticating itself to the client, while the client does not authenticate itself to the server. A detailed explanation along with schematics can be found here

The SSL server can be configured to request authentication of the client, in which case the client has to send a certificate to be authenticated. The same "chain of trust" verification will be performed. So the SSL handshake with client authentication has a few additional steps. Again, a detailed explanation can be found here

How is the actual user authentication done?
You need to have a central in-house certificate authority. You can use command-line tools like openssl or CA.pl which are part of the OpenSSL package. Or you can use OpenCA PKI software which is designed just for that.

You have to

• Generate a Certificate Authority keypair (key + certificate)
• Get the users to generate their keypair (key + certificate signing request)
• Sign each user's certificate using the Certificate Authority keypair

Now since the authentication of the client is performed by SSL as part of the handshake, you don't need to authenticate the user further (of course you can if you want to). In other words, either the client has a valid keypair (key and valid certificate signed by your Certificate Authority) and he can connect. Or he doesn't have any, in which case the SSL connection will fail at handshake time.

Smart Card
The most secure way to go about this is to store your keypair on a smart card. The private key remains on the smart card at all time, while the public key (the certificate) can be installed in the browser, or any other public key or certificate store.

This way, when you want to connect to the server, you have to have your smartcard reader plugged-in and the card properly inserted before you can even connect. The browser will pop-up a window asking you for your smart card pin. Once the pin is entered, the SSL handshake can be done properly.

Nowadays, online services requiring heavy security prefer to use USB smart card + smart card reader devices. It looks like a regular USB mass storage key, except that it's a smart card reader and smart card combined. It's easier to carry, and you just have to install the driver for it to work.

Drawbacks
Obviously, the main problem is that the user must have his certificate + key wherever he roams.

Sometimes, some companies with ultra-strict security policies will force their proxy to play man-in-the middle, so they can still intercept your SSL connections. It will break the server SSL certificate authentication but you can still choose to ignore your browser's warning. This will break the SSL client certificate authentication too but the server will obviously not ignore it and won't let you connect.

Finally, most of the integrated USB smart card reader + smart card dongles have no driver for Linux, *BSD or Solaris.

Conclusion
Although client certificates are more troublesome to set up than username and passwords, they offer a lot more security and resistance to targeted attacks. While they are inconvenient to the road-warriors users, they are perfect authentication tokens for workstation-based employees.