SSL/TLS Mutual Authentication Primer
SSL/TLS Mutual Authentication Primer
Secure Sockets Layer (SSL) is a cryptographic protocol, which provides secure communications
for e-commerce, e-mail and other data transfers without eavesdropping, tampering or message
forgery. Netscape first introduced SSL in 1996 with version 3.0 of the Netscape browser. It's
successor, Transport Layer Security (TLS), is an IETF standard protocol first defined in RFC
2246. The term SSL generally applies to both protocols unless otherwise specified.
Mutual authentication or two-way authentication refers to two parties authenticating each other at
the same time, being a default mode of authentication in some protocols (IKE, SSH) and optional
in others (TLS). By default the TLS protocol only proves the identity of the server to the client
using X.509 certificate and the authentication of the client to the server is left to the application
layer. TLS also offers client-to-server authentication using client-side X.509 authentication.[1] As
it requires provisioning of the certificates to the clients and involves less user-friendly experience,
it's rarely used in end-user applications.
Certificate based
User name-password based
From a high-level, SSL has three capabilities that may be used independently or in combination
to secure content transport (or the network pipe). These capabilities are:
1. Authenticating a (web) server to a client (usually a browser)
2. Encrypting client/server communications
3. Authenticating a client to a server
SSL implementations rely on the user of digital certificates, which verify the identity of people and
organizations. Certificates are electronic credentials that bind the identity of the certificate owner
to a pair (public and private) of electronic keys that can be used to encrypt and sign information
digitally. These electronic credentials assure that the keys actually belong to the person or
organization specified. Messages can be encrypted with either the public or the private key and
then decrypted with the other key.
Each certificate contains at least the following information:
Certificates can also contain other user-supplied information, including a postal address, an email
address and basic registration information, such as the country or region, postal code, age and
gender of the user.
Most public web sites only use SSL to authenticate the web server to the client while the client
remains unauthenticated to the web server. Web server authentication is easily implemented and
sufficient for establishing an SSL connection while requiring users to install X.509 client
certificates is prohibitively expensive and difficult for general Internet use. However, web servers
can be configured to request or require that the client authenticate using an X.509 certificate.
This is known as mutual authentication and is required when configuring Cams to use X.509
certificate authentication within a login module. In other words, Cams relies on successful SSL
client authenticate so that the client certificate is automatically transmitted with the HTTPS
request.
Web servers include instructions on how to configure them for SSL. Though instructions vary
depending upon the web server, the basic ingredients are the same. An X.509 certificate, which
has been signed by a trusted certificate authority (CA) or intermediary, must be installed in the
web server. The word trusted implies that the browser must be configured to trust the CA that
signed the web server certificate by importing its publicly available root or top-level certificate.
Popular CA root certificates are pre-installed by default in all browsers and as such are
intrinsically trusted. You must manually install root certificates for any CA you implement.
These root certificates establish a chain of trust with the X.509 certificates they sign. If you don't
install a root certificate for your CA in a browser, then your browser will prompt you to ask if you
want to accept or trust the web server certificate. That's not the case for client certificates
supplied from your browser to the web server. In that case, you MUST install the
CAs root certificate in the web server or SSL authentication will fail (e.g., there's no practical way
for a web server to prompt an administrator to accept or trust client certificates on a one by one
basis). Also, CAs distribute Certificate Revocation Lists (CRLs), which are lists of serial numbers
for certificates that have been revoked by the CA. Both browsers and web servers can be
configured to reference or import CRLs.
When properly configured, the browser and web server use a process known as handshaking that
requires no human interaction:
• The browser sends a request for SSL communication to the web server and negotiates the
cryptographic algorithms that will be used.
• The web server provides its certificate to the browser and (optionally) requests a certificate
from the browser.
• The browser validates the web server certificate using the CA's public key and checks the
CRL, if available.
• If the web server's certificate is valid, the browser creates a master secret key, encrypts it
with the web server's public key and transmits it to the web server. If the web server
requested client authentication, the browser also includes its certificate (the user may be
prompted to select a client certificate to use if so configured).
• If the browser transmitted a certificate, the web server verifies it using the CA's public key and
the CRL.
• The browser and web server use the master secret key to generate the symmetric session
keys. The use of symmetric keys instead of the public keys from the digital certificates
provides better performance.
When a browser or web server receives a certificate, successful authentication requires that the
following questions evaluate to true:
There is quite a bit more complexity under the hood, but we'll leave it up to you and your Google
skills to find out more. The following sections provide some starting points.