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.
Mutual TLS authentication (mTLS) is much more widespread in business-to-business (B2B)

applications, where a limited number of programmatic and homogeneous clients are connecting
to specific web services, the operational burden is limited and security requirements are usually
much higher as compared to consumer environments.
Better institution-to-customer authentication would prevent attackers from successfully

impersonating financial institutions to steal customers' account credentials; and better customer-
to-institution authentication would prevent attackers from successfully impersonating customers
to financial institutions in order to perpetrate fraud
Most Mutual authentication is machine-to-machine, leaving it up to chance whether or not users

will notice (or care) when the remote authentication fails (e.g. a red address bar browser padlock,
or a wrong domain name). Non-technical mutual-authentication also exists to mitigate this
problem, requiring the user to complete a challenge, effectively forcing them to notice, and
blocking them from authenticating with a false endpoint.
Mutual authentication is two types:
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:
• Owner's public key

• Owner's name or alias
• Expiration date of the certificate
• Serial number of the certificate
• Name of the organization that issued the certificate
• Digital signature of the organization that issued the certificate
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:
1. Is today's date within the certificate's validity period?

2. Is the issuing CA for the certificate a trusted CA?
3. Does the issuing CA's public key validate the issuer's digital signature?
4. Is the certificate's serial number NOT listed in the current CRL? Or, is the client certificate
found in the organization's LDAP directory?
5. Does the domain name in the server's certificate match the domain name of the server itself
(server authentication only)?
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.
Implementing your own Certificate Authority (CA)

A Certificate Authority is an entity that issues trusted digital certificates. A CA can be either a
third party or implemented internally within an organization using commercial or open source
software. A CA issues public key certificates, which states that the CA attests that a certificate's
public key belongs to the person, organization or entity noted in the certificate. A CA's obligation
is to verify an entity's credentials, so that relying parties can trust the information in the CA's
certificates. If the user trusts the CA and can verify the CA's signature, then they can also verify
that a public key belongs to the certificate owner.
You can purchase certificates from online CAs such as Verisign, Thawte or Comodo or you can
implement your own CA. Commercial vendors including Microsoft, Red Hat and Sun
Microsystems provide software to do so. You can also use OpenSSL, included free with most
Linux distributions. OpenSSL is an open source toolkit that implements the SSL v2/v3 and TLS
v1.x protocols as well as a general purpose cryptography library.

SSL/TLS Mutual Authentication Primer

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SSL/TLS Mutual Authentication Primer

Uploaded by

Copyright:

Available Formats

SSL/TLS Mutual Authentication Primer

Mutual TLS authentication (mTLS) is much more widespread in business-to-business (B2B)

Better institution-to-customer authentication would prevent attackers from successfully

Most Mutual authentication is machine-to-machine, leaving it up to chance whether or not users

Mutual authentication is two types:

• Owner's public key

1. Is today's date within the certificate's validity period?

Implementing your own Certificate Authority (CA)

You might also like