Mutual TLS (mTLS)
mTLS is a feature of TLS for mutual authentication that enables the server to authenticate the client’s identity. mTLS authentication is a standard security practice that uses client TLS certificates to provide an additional layer of protection, verifying the client information cryptographically.
Why use mTLS?
mTLS helps ensure that traffic is secure and trusted in both directions between a client and server. This provides an additional layer of security for users who log in to an organization’s network or applications. It also verifies connections with client devices that do not follow a login process.
mTLS is a highly secure transport layer protocol that protects from attacks like on-path attacks, spoofing attacks, credential stuffing, brute force attacks, phishing attacks, and malicious API requests. Since it only provides a transport layer authentication, all the requests sent over the channel are then implicitly granted access assuming the origination is from the authentic client. This is why it can be extended by OAuth 2.0 (an authorization protocol) and OpenID Connect (an identity authentication protocol) improving security for all requests.
How does mTLS work?
Normally in TLS, the server has a TLS certificate and a public/private key pair, while the client does not. The typical TLS process works like this:
- Client connects to the server.
- Server presents its TLS certificate.
- Client verifies the server’s certificate.
- Client and server exchange information over encrypted TLS connection.
In mTLS, however, both client and server have a certificate, and both sides authenticate using their public/private key pair. Compared to regular TLS, there are additional steps in the mTLS to verify both parties:
- Client connects to the server.
- Server presents its TLS certificate.
- Client verifies the server’s certificate.
- Client presents its TLS certificate.
- Server verifies the client’s certificate.
- Server grants access.
- Client and server exchange information over encrypted TLS connection.
AWS Application Load Balancer (ALB) with ECS Fargate Tasks
One of our clients, autoSense AG – https://autosense.ch offers its users a range of digital assistants to enhance their driving experience, with the goal of establishing more efficient and safer mobility. Users can access information, such as vehicle diagnostics, statistics or driving behavior, directly in the app. Transaction-based services such as fueling, charging or CO2 compensation are accessible with the click of a button.
To support these various solutions, autoSense AG is running multiple container-based services on Amazon ECS using AWS Fargate, with an Internet-facing Application Load Balancer following the architecture highlighted below. All resources have been provisioned with infrastructure as code (IaC) using the core copebit CloudFormation templates.
The client’s core dev team came up with a feature request to introduce mTLS authentication for some of their services additionally to their existing authentication processes but without drastically affecting their existing AWS architecture, provisioning and deployment processes.
The Application Load Balancer (ALB) does not support mTLS at the moment. Since ALB has to terminate the TLS connection, there is no way to add TCP pass-through to the ALB. The reason why ALB needs to decrypt the request is because it operates at the application layer of the Open Systems Interconnection (OSI) model and needs to inspect the requests to perform request routing.
AWS Network Load Balancer (NLB) with TCP Pass-Through Listeners
At the beginning, we evaluated the idea of introducing a Network Load Balancer – NLB (or Classic Load Balancer) instead of ALB for the services requiring mTLS. NLB can handle all the TLS certificate matters on the services. This way we were able to configure TCP pass-through listeners with type NLB with TCP listeners on port 443 and with the Backend configured with TCP listeners on port 443 to pass through all requests to the services for TLS to be negotiated and terminated there. This approach indeed worked but the TLS handling in each of the services was not promoted as a scalable solution as it required several code changes.
As a next option, we started evaluating cloud native solutions – resources that support mTLS focusing on the AWS API Gateway resource. Historically, the API gateway has supported one-way TLS to ensure that API clients are able to verify the API gateway’s identity by validating its public certificate. At the moment, however, the API gateway natively supports mTLS. You can now configure a custom domain name to enforce two-way TLS or mTLS which enables certificate-based authentication both ways: client-to-server and server-to-client.
mTLS authentication for Amazon API Gateway
AWS supports certificate-based mTLS authentication for the Amazon API Gateway. This is a method for client-to-server authentication that can be used with the API gateway’s existing authorization options.
You can enable mTLS authentication on your custom domains to authenticate regional REST and HTTP APIs. You can still authorize requests with bearer or JSON Web Tokens (JWTs) or sign requests with IAM-based authorization.
To use mutual TLS with AWS API Gateway, you should upload a CA public key certificate bundle as an object containing public or private/self-signed CA certs. This is used for validation of client certificates. All existing API authorization options are available for use with mTLS authentication.
Below you can find the targeted architecture we concluded and implemented in regards to the certificate-based mTLS authentication for Amazon API Gateway in front of an Application Load Balancer (ALB) with ECS Fargate tasks. This allowed us to leave the existing AWS architecture and the services codebase untouched.
Please note that as the mTLS authentication (including the TLS termination) is handled by the HTTP API gateway, we are forwarding the traffic to an internal (private) ALB by introducing a VPC link (please refer to this AWS tutorial https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-private-integration.html for building an HTTP API with a private integration to an Amazon ECS service).
Certificate Authorities in mTLS
The organization implementing mTLS acts as its own certificate authority. This contrasts with standard TLS, in which the certificate authority is an external organization that checks if the certificate owner legitimately owns the associated domain.
For mTLS, a root TLS certificate is necessary, which enables an organization to be their own certificate authority. The certificates used by authorized clients and servers have to correspond to this root certificate. The root certificate is self-signed, meaning that the organization creates it themselves (this approach does not work for one-way TLS on the public Internet because an external certificate authority has to issue those certificates).
To configure mTLS (S3 Bucket Truststore) in the above architecture, please refer to this AWS blog post https://aws.amazon.com/blogs/compute/introducing-mutual-tls-authentication-for-amazon-api-gateway. You will have to create the private certificate authority and the client certificates. You will need the public keys of the root certificate authority and any intermediate certificate authorities. These must be uploaded to the API gateway to authenticate certificates using mTLS. The above AWS blog post uses OpenSSL to create the certificate authority and client certificate.
Summary
AWS API Gateway provides integrated mTLS authentication. You can enable mTLS authentication on your custom domains to authenticate regional REST and HTTP APIs additionally to any other existing authentication processes with bearer or JSON Web Tokens (JWTs) or sign requests with IAM-based authorization.
In the case of an AWS Application Load Balancer (ALB) with ECS Fargate tasks architecture that requires mTLS, you can implement mTLS in the API Gateway and then integrate the API Gateway with your ALB through a VPC link.