Mutual Authentication

Mutual Authentication

Introduction

Mutual authentication, also called two-way authentication, is a process for both entities in a communications link to authenticate each other. In network environments, client authenticates the server and vice-versa to ensure that they are doing business with legitimate entities. With mutual authentication, SSL connection can occur only when the client trusts the server's digital certificate and the server trusts the client's certificate. The exchange of certificates is carried out by means of the Transport Layer Security (TLS) protocol.

A well-designed mutual authentication solution also protects against online fraud such as man in the middle attacks, shoulder surfing, Trojan horses, key loggers and pharming.

To ensure optimum security, mutual authentication can be used in conjunction with other countermeasures such as firewalls, antivirus software and anti-spyware programs.

Configure SSL Mutual (Two-way) Authentication

Let’s explore how to create a 2 way authentication (mutual authentication) in SSL reverse proxy balancer gateway. This configuration is useful in any enterprise environment where it’s requested to separate clients, the frontend and the backend, and when the traffic between clients and the gateway, and between the gateway and the backbends must be encrypted which ensures the clients and the backbends to be authentic, and avoids Man in the Middle attacks.

Since the reverse proxy is in the middle between the clients and the backbends, it’s requested for the clients to send a known client certificate to the gateway (apache), so that the gateway can recognize them. This is done with X509 certificates.

For the same reason, each backend contacted by the gateway is requested to respond with a valid and known server certificate. This is also done with X509 certificates.

Generally, the clients and the backbends will also check their peer’s (apache) certificate to be known and valid, so that if someone is going to impersonate the gateway, it will be found and will not be considered authentic.

To do so, we’ll use:

• apache httpd
•  mod_ssl
•  mod_proxy_balancer + mod_proxy + mod_proxy_http
• openssl

Everything is done with a simple and single virtual host in apache to be included in httpd.conf or ssl.conf file.

Mutual Authentication flow

Mutual Authentication Using Self Signed Certificate

Apache 2 and OpenSSL provide a useful, easy-to-configure and cost-effective mutual SSL/TLS authentication development and test environment with the help of the following components

·         Apache 2.0 web server with built-in mod_ssl support on Linux/UNIX

·         OpenSSL on Linux/UNIX

Creating the CA Key and CA Certificate

Do the steps below to generate the root CA certificate.

$ openssl genrsa –out ca.key 1024
$ openssl req -new -key ca.key -out ca.csr
$ openssl x509 -req -days 365 -in ca.csr -signkey ca.csr -out ca.pem

To verify the certificate we can execute the command

$ openssl x509 –in ca.pem –text

Creating Client Key and Client Certificate

Do the steps below to generate the root CA certificate.

$ openssl genrsa –out client.key 1024
$ openssl req –new –key client.key –out client.csr
$ openssl ca -in client.csr –cert ca.pem –keyfile ca.key –out client.pem

To verify the certificate we can execute the command

$ openssl x509 –in client.pem –text

Importing the client certificate in PKCS#12 format

Firefox and Internet Explorer 6.0 support the PKCS#12 certificate format. Use the following command to convert the user certificate to this format.

NOTE: During the conversion process, you’ll be asked for an export password. Enter anything you can remember, but don’t let it be empty because the file will contain your private key.

$ openssl pkcs12 –export –clcerts –in client.pem –inkey client.key –out client.p12

Intermediate Certificate

An intermediate certificate is the certificate, or certificates, that go between your site (server) certificate and a root certificate. The intermediate certificate, or certificates, completes the chain to a root certificate trusted by the browser.

We can create several intermediate certificates during authentication process the chain has to be completed and client must be signed by root CA.

Configuring Apache to Support Mutual Authentication

<VirtualHost *:443>
    # Apche server certificate
    SSLCertificateFile “/opt/apache/conf/ssl/server.pem”
   # Apache server private key
   SSLCertificateKeyFile “/opt/apache/conf/ssl/key.pem”
   # Apache server CA certificate (certificate of who released your server certificate)
   SSLCertificateChainFile “/opt/apache/conf/ssl/ca.pem”
   # Client’s CA certificates (list of certificates of who released your client’s certificates)
   SSLCACertificateFile “/opt/apache/conf/ssl/ca.pem”
   # It’s mandatory for apache to authenticate the client’s certificate
   SSLVerifyClient require

   <Location /url/to/be/restricted>
         SSLVerifyDepth <exact_numeric_value>
         # If CN verification is required
          SSLRequire %{SSL_CLIENT_S_DN_CN} in {  "ABC"}
   </Location>

</VirtualHost>

Note:  SSLVerifyDepth value is very important if root CA signed the client certificate it will be 2. If any intermediate CA is involved we need to add those.

Mutual Authentication for Trusted Certificate

If root CA is trusted we can also use SSLCACertificatePath which ideally will be /etc/ssl/certs where all the ca certs symbolic hash is created during ca-certs package installation.

Testing

$ curl -v --cert client.pem:<client_pem_password> --key client.key -X POST '<SECURE_URL>'

Console output will display some message which includes

* About to connect() to <host_server_details> 443 (#0)

*   Trying <ip_address_of_host>...

* Connected to < host_server_details > <ip_address_of_host> port 443 (#0)

* successfully set certificate verify locations:

*   CAfile: none

  CApath: /etc/ssl/certs

<handshaking_details>

* Server certificate:

*      <server_certificate_info>

*      SSL certificate verify ok.

> POST <URL> HTTP/1.1

> User-Agent: curl/7.32.0

> Host: <host_name>

> Accept: */*

>

<Sslv3 TLS handshaking_details>

< HTTP/1.1 200 OK

< Set-Cookie: JSESSIONID=940071268FF51D4D4E2B70887FAF2DBA.oopsnode1; Path=/; Secure; HttpOnly

< Access-Control-Allow-Origin: *

< Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE

< Access-Control-Max-Age: 3600

< Access-Control-Allow-Headers: Authorization,Origin,X-Requested-With,Content-Type,Accept,merchantAccessKey,requestSignature

< Content-Length: 0

< Vary: Accept-Encoding

< Content-Type: text/plain; charset=UTF-8

<

* Connection #0 to host <host_name> left intact

Important Notes

1.       If using intermediate certificates for SSLCACertificate then we need to concatenate those certificates in a single large file according to reverse creation order like

$ cat ca-certificates.crt > ca-extended.crt
$ cat ca.pem root.pem   >> ca-exetnded.crt

(root.pem is the root CA and ca.pem is an intermediate created from root ca)

2.       Based on Apache and openssl version it may be required to put  SLCACertficate,SSLVerifyClient  and SSLVerifyDepth outside VirtualHost.