SSL/TLS and Strong Authentication

SSL (Secure Sockets Layer) was created by Netscape Communications, to secure web traffic in its Navigator browser and web server products. It was also used in their LDAP directory server product.

 

History of SSL / TLS

SSL became widely used even with version 2.0. This version included server to client authentication (using a server digital certificate) and symmetric session key agreement (for privacy between client and server). Only one server certificate (per secure server) is required for this to work, and many Certification Authorities (such as VeriSign) managed to produce reliable, secure server certificate products and services. Millions of websites are protected by SSL today using only server to client authentication.

 

Client to Server Authentication

What about client to server authentication? With SSL 2.0 this must be provided independent of the SSL protocol. This is typically done with plaintext username/password authentication, protected from sniffing by sending this within the encrypted tunnel provided by SSL. This is fairly good protection against network sniffer attacks, but no protection at all against keyboard sniffer attacks (where a hacker can capture every key you type on your PC, including your login credentials). It also requires a centralized username/password database on the secure server, which can be captured and analyzed offline by a hacker (this is the source of most large scale site compromises, resulting in sometimes millions of compromised user credentials in a single operation). The worst aspect of this is that many people use the same credentials on many websites, and once the hacker obtains their credential from one compromised website, they will try those credentials against many other sites.

When SSL version 3.0 was introduced, the primary new feature was a second (option) phase in the handshake at the beginning of a session, to allow strong client-to-server authentication, using client digital certificates. This has never been widely used, due to the difficulty and expense of issuing and managing a potentially large number of client digital certificates. Unlike server certs, where only one is required per server, with client certs, one is required for each distinct user of a secure server. So, Amazon.com needs only one server cert, but potentially tens or hundreds of millions of client certs.

SSL was so widely adopted, that Netscape decided to release it as an IETF open standard. In addition to cleaning up the protocol somewhat (and supporting additional cipher suites, such as DSA), the name was changed to TLS (Transport Layer Security). Technically SSL/TLS does not exist in the Transport Layer (home of TCP and UDP) but as a "shim" between the Application Layer and the Transport Layer. In practice, the SSL/TLS code (as well as certificate handling) must be integrated into each protected application (both client and server), and this is a non-trivial process. The first release of TLS was RFC 2246, "The TLS Protocol Version 1.0", January 1999.

The second release of TLS was RFC 4346, "The Transport Layer Security (TLS) Protocol version 1.1", April 2006. This involved primarily minor technical fixes to the protocol. TLS v1.1 has been fairly widely adopted in client and server software, as well as SSL toolkits.

The third release of TLS was RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2", August 2008. This involved phasing out of SHA1 in favor of SHA-2 (specifically SHA256), better support for newer message digests, and inclusion of the AES symmetric algorithm in the main standard from the separate RFC 3268, "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", June 2002. Unfortunately, as of this time, TLS 1.2 has not been widely supported in client or server software, but it is starting to be supported in TLS toolkits. Some TLS 1.1 compliant products already support RFC 3268, in order to use AES in place of DES3 ("Triple DES"), even if they don't fully support TLS 1.2.

 

How SSL/TLS works

When an SSL/TLS client connects to an SSL/TLS server, it first does a "handshake" to achieve authentication and privacy. There are four phases in an SSL/TLS handshake (this is somewhat simplified, but contains the essential steps):

1. Negotiation - client and server agree on the strongest cryptographic algorithms and key lengths they have in common

2. Server to Client authentication - the server proves its identity to the client

3. Client to Server authentication (optional) - the client proves its identity to the server

4. Symmetric session key agreement - client and server agree upon a symmetric key to use in encrypting all further traffic between client and server.

Step 1 - Negotiation

The server sends the client a list of the cryptographic algorithms and key lengths it supports. The client chooses the strongest ones it also supports and sends its choices back to the server. This includes asymmetric key, symmetric key algorithms and message digest algorithms.

Step 2 - Server to Client authentication

The server sends its server certificate to the client. The client validates the server certificate. It has to check validity period (it must currently be after the start date & time, and before the end date & time in the certificate). It must also verify the certificate's signature (which requires the higher level certificates in the certificate's hierarchy, all the way to a trusted root cert, which normally the client must already know and trust, e.g. by it being embedded in the browser). It must also verify that the URL surfed to matches the FQDN in the certificate's subject DN. Finally the client is convinced that the server has presented a valid certificate to it.

The client must now determine if the presented certificate belongs to this server. It does this by creating a challenge string (of random characters) and encrypting it with the public key from the server cert. It sends the encrypted string to the server. The server decrypts it with its private key and returns the result. If this result matches the original challenge string, this is proof that the server owns the private key associated with the presented server certificate, without revealing that private key. This establishes server to client authentication.

The client can extract information from the server cert if needed, such as the validity period, the issuer (Certification Authority that issued this cert), etc.

Step 3 - Client to Server authentication

This step was first introduced in SSL 3.0, and is still optional. It works just like Server to Client authentication with roles reversed. This can be disabled, be allowed (optional) or required (mandatory). If allowed, the user can still fall back to username/password authentication if they have a valid password. If mandatory, username/password authentication is disabled.

The server requests the client to send its client certificate to the server. If there are multiple client certs, the user can choose the appropriate one, which is then sent. The server validates the client certificate. It has to check validity period (it must currently be after the start date & time, and before the end date & time in the certificate). It must also verify the certificate's signature (which requires the higher level certificates in the certificate's hierarchy, all the way to a trusted root cert, which normally the server must already know and trust, e.g. by it being embedded in the server). Finally the server is convinced that the client has presented a valid certificate to it.

The server must now determine if the presented certificate belongs to this client. It does this by creating a challenge string (of random characters) and encrypting it with the public key from the client cert. It sends the encrypted string to the client. The client decrypts it with its private key and returns the result. If this result matches the original challenge string, this is proof that the client owns the private key associated with the presented client certificate, without revealing that private key. This establishes client to server authentication.

The server can extract information from the client cert if needed, such as the user's name, email address or (if present) UserID. It can also read the validity period and the issuer DN (to determine who issued this certificate). It can decide whether or not to trust the client cert based on this information. There is no need for the client to supply a password (they are already authenticated far better than any password scheme). There is also no need for them to supply their login, as this can be determined from the information in the cert (UserID, or mapped from the email address using a database). The user is immediately granted access to the secure site, and the server knows who he is.

Step 4 - Symmetric session key agreement. The client creates a symmetric key for the agreed upon symmetric algorithm. It encrypts it with the public key from the server certificate. It sends the encrypted session key to the server, which decrypts it with its private key. This can now be used by either end to encrypt traffic, and the other end to decrypt it. The optional client to server authentication is not required for this step to be done.

Without Step 3, the client can still authenticate to the server, but typically by using a username/password scheme, the same as without SSL/TLS. The difference is this is sent through an encrypted tunnel. However, a hacker can still see any key pressed on the client computer, and assume the user's identity.

With Step 3 (a.k.a. "strong client authentication"), the hacker could see everything typed on your keyboard, and sniff all traffic between the client node and server node, and still not be able to assume the client's identity (without obtaining possession of the client's private key, and any passphrase used to protect it).

 

Client Cert Deployment

For each client cert applicant, the issuer must verify the submitted client identification information (name, email address, location, organization, department within organization, etc). They must then create a certificate from this information and send it securely to the applicant. The applicant must then install it in their client software (web browser, email client, etc). The client and server software needs to be able to verify that the client certs are trusted (the digital signature checks, and chains up to a trusted root cert). It also needs to verify that the cert has not been revoked.

All certificates are issued with a fixed validity period. Root certs usually are good for 25-30 years, intermediate certs for about 5 years, and end-user certs usually are good for one year. When a certificate expires, it must be renewed. With server certs, this is handled by a system administrator so that the end-user doesn't even know it happened (unless the server admin forgets to do it in time!). With client certs, renewal must be handled for each user, and often users do not have much expertise with this kind of thing. The more certificate renewal can be automated and hidden from the users, the better.