Secure your application traffic with Application Gateway mTLS

I am happy to share that Azure Application Gateway now supports mutual transport layer security (mTLS) and online certificate status protocol (OCSP). This was one of the key questions from our customers as they were looking for more secure communication options for the cloud workloads. Here, I cover what mTLS is, how it works, when to consider it, and how to verify it in Application Gateway.

What is mTLS?

Mutual transport layer security (TLS) is a communication process where both parties verify and authenticate each other’s digital certificates prior to setting up an encrypted TLS connection. mTLS is an extension of the standard TLS protocol, and it provides an additional layer of security over TLS. With traditional TLS, the server is authenticated, but the client is not. This means that anyone can connect to the server and initiate a secure connection, even if the client or user is not authorized to do so. By using mTLS you can make sure that both the client and the server must authenticate each other prior to establishing the secure connection, this will make sure there is no unauthorized access possible on either side. mTLS works on the framework of zero trust—never trust, always verify. This framework ensures that no connection should be trusted automatically.

How does mTLS work?

mTLS works by using a combination of secure digital certificates and private keys to authenticate both the client and the server. The client and the server each have their own digital certificate and private key, which are used to establish trust and a secure connection. The client verifies the server's certificate, and the server verifies the client's certificate—this ensures that both parties are who they claim to be.

How are TLS and mTLS different?

TLS and mTLS protocols are used to encrypt network communication betweenclient and server. In TLS protocol only the client verifies the validity of the server prior to establishing the encrypted communication. The server does not validate the client during the TLS handshake. mTLS, on other hand, is a variation of TLS that adds an additional layer of security by requiring mutual authentication between client and server. This means that both the client and server must present a valid certificate before the encrypted connection can be established. This makes mTLS more secure than TLS as it adds an added layer of security by validating authenticity of client and server.

TLS call flow:

mTLS call flow:

When to consider mTLS

◉ mTLS is useful where organizations follow a zero-trust approach. This way a server must ensure of the validity of the specific client or device that wants to use server information. For example, an organization may have a web application that employees or clients can use to access very sensitive information, such as financial data, medical records, or personal information. By using mTLS, the organization can ensure that only authorized employees, clients, or devices are able to access the web application and the sensitive information it contains.

◉ Internet of Things (IoT) devices talk to each other with mTLS. Each IoT device presents its own certificate to each other to get authenticated.

◉ Most new applications are working on microservices-based architecture. Microservices communicate with each other via application programming interfaces (APIs), by using mTLS you can make sure that API communication is secure. Also, by using mTLS you can make sure malicious APIs are not communicating with your APIs

◉ To prevent various attacks, such as brute force or credential stuffing. If an attacker can get a leaked password or a BOT tries to force its way in with random passwords, it will be of no use—without a valid TLS certificate the attacker will not be able to pass the TLS handshake.

At high level now you understand what is mTLS and how it offers more secure communication by following zero trust security model. If you are new to Application Gateway and have never setup TLS in Application Gateway, follow the link to create APPGW and Backend Servers. This tutorial uses self-signed certificates for demonstration purposes. For a production environment, use publicly trusted CA-signed certificates. Once end-to-end TLS is set up, you can follow this link for setting up mTLS. To test this setup the prerequisite is to have OpenSSL and curl tool installed on your machine. You should have access to the client certificate and client private key.

Let’s dive into how to test mTLS Application Gateway. In the command below, the client's private key is used to create a signature for the Certificate Verify message. The private key does not leave the client device during the mTLS handshake.

Verify your mTLS setup by using curl/openssl

◉ curl -vk https://<yourdomain.com> --key client.key --cert client.crt

<Yourdomain.com> -> Your domain address

client.key -> Client’s private key

client.crt -> Client certificate

In the above output, we are verifying if mTLS is correctly set up. If it is set up correctly, during the TSL handshake server will request the client certificate. Next, in the handshake, you need to verify if the client has presented a client certificate along with the Certificate Verify message. Since the client certificate was valid, the handshake was successful, and the application has responded with an HTTP "200" response.

If the client certificate is not signed by the root CA file that was uploaded as per the link in step 8, the handshake will fail. Below is the response we will get if the client certificate is not valid.

Alternatively, you can verify the mTLS connectivity with an OpenSSL command.

◉ openssl s_client -connect <IPaddress> :443 -key client.key -cert client.crt

Once the SSL connection is established type as written below:

GET / HTTP/1.1

Host: <IP of host>

You should get the Response code—200. This validates that mutual authentication is successful.

Source: microsoft.com