Mutual Transport Layer Security (mTLS) can be used to enforce secure connections between a client and web server over a network. But when, and how, should you use it?
What is mTLS?
For Enterprise 8.9, Loadbalancer.org added a new SSL Terminator for HAProxy, allowing for mutual Transport Layer Security (mTLS) configurations. But what does that mean?
Mutual Transport Layer Security (mTLS) is an extension of the more commonly used Transport Layer Security (TLS) protocol, used to secure connections such as HTTPS. But mTLS is not actually another protocol. Instead, with mTLS, authentication occurs at both ends of the handshake - rather than just one.
What is an SSL Terminator?
An SSL Terminator, such as STunnel, HAProxy or Pound, is essentially a proxy server that acts as an intermediary between client and server applications, and is used to decrypt and encrypt communications.
The actual process of decrypting encrypted traffic (otherwise known as SSL termination) can be handled in the following ways:
1.On the Real Servers (recommended) - aka SSL pass-through.
2.On the load balancer - aka SSL offloading.
3.On the load balancer with re-encryption to the backend servers - aka SSL bridging.
For more information, refer to pages 159-174 in our admin manual.
How does mTLS differ from TLS?
Essentially, mTLS adds an additional layer of security, by requiring the use of digital certificates to authenticate the client AND the server.
Secure Socket Layer (SSL) encryption protocol
The original encryption protocol for web servers was SSL. However, due to its acknowledged security vulnerabilities and inefficiencies, this has now been replaced by the more modern Transport Layer Protocol (TLS) that now exists on most websites.
Note: Certificates are separate to protocols. Hence, the "SSL certificate", known to many, might also be referred to as a "TLS certificate". So, because this is simply a difference in naming convention, you don't need to 'switch' your website's "SSL certificate" to a "TLS certificate" - it will apply to both protocols. In other words, the handshake that the server makes with the client is independent of the "SSL/TLS certificate", and is instead determined by the protocol enabled on the server.
Transport Layer Security (TLS) encryption protocol
Transport Layer Security (TLS) encrypts data sent over the Internet. This keeps your private and sensitive data, such as passwords and financial information, safe.
In most cases, for a scalable solution, terminating TLS on the real servers is the best option, meaning that it's there that data is encrypted/decrypted before then passing through the load balancer. TLS termination can be performed on the load balancer, but it can be very CPU intensive.
TSL/SSL termination is where a full public certificate, along with its private key, is uploaded to the load balancer and aligned to a TLS/SSL termination virtual service. Data is encrypted from the client to the load balancer but is decrypted at the load balancer, becoming plain text HTTP.
Mutual Transport Layer Security (mTLS) authentication
With TLS, only the server is required to present its certificate to the client. However, with mTLS, the client is also required to present its certificate to the server. Hence mutual certificate authentication occurs.
This double layer of client and server authentication provides an additional layer of protection against impersonation attacks. And it is only once this two-way authentication has taken place that a secure connection is established, leading to the exchange of data.
When should you use mutual authentication?
At a basic level, mTLS should be used when you need strong security.
1.Use mTLS to protect against man-in-the-middle attacks
With man-in-the-middle (MitM) attacks, an attacker seeks to intercept and modify the communication between the client and the server. Enhanced protection against impersonation attacks is achieved using mTLS through a combination of certificate authentication and encryption.
mTLS prevents an attacker from posing as the client or the server by validating the certificates. So attackers attempting to act as middlemen will be unable to authenticate because they lack a valid certificate.
Meanwhile, the session key is used to encrypt all correspondence between the client and the server. In the event that data is intercepted, the only thing that is visible to the attacker is encrypted ciphertext, which is impossible to decrypt without the session key. As a result, the attacker cannot access or alter the data.
2.Use mTLS to keep communications between dispersed systems secure
With mTLS, communications between dispersed systems are secured with end-to-end encryption, authentication, and integrity verification, protecting microservices in a distributed architecture. This ensures that only authorized systems can securely communicate, safeguards the integrity and confidentiality of data, and reduces the likelihood of network-level attacks.
In addition to the end-to-end encryption and certificate-based authentication described above, cryptographic hash functions are also generated for the data being transmitted. These are then verified by the receiving system which recalculates the expected function and compares it to the hash signature provided. A match confirms the integrity of the data.
Furthermore, mTLS allows for secure key exchange protocols to be applied during the initial handshake between systems. The key is shared and used for mirrored encryption and decryption.
3.Use mTLS to maintain data confidentiality and integrity
This relies on a combination of encryption and cryptographic mechanisms, authentication, and non-repudiation.
Mirrored encryption algorithms encrypt the data transmitted between two systems, with a shared key issued during the initial handshake. This means the sender and receiver have a matching key, protecting data confidentiality because only the intended receiver will be able to decrypt and read the data.
Data integrity can also be verified using cryptographic hash functions such as the Secure Hash Algorithm (SHA). As explained previously, this test ensures that the data received hasn't been altered in transit. Finally, certificates issued by trusted Certificate Authorities (CAs) verify that each system holds a valid and authentic certificate, thus protecting data confidentiality.
4.Use mTLS to secure API communication
Application Planning Interfaces (APIs) exchange data between the client and the server. This data exchange can be secured using mTLS through enforced client authentication (in other words, a digital certificate shared during the TLS handshake is presented and validated, giving only authorized users access to the API). In the same way, the server's digital certificate must also be validated to ensure its authenticity.
In addition, prevention of network-level attacks such as MitM can be achieved through end-to-end encryption (those mirrored encryption algorithms again...) and integrity protection (think validation of the hash generated by the server vs. the response received by the client).
5.Use mTLS to safeguard IoT device communication
In the same way mTLS can be used to keep communications between dispersed systems secure, it can also be used to safeguard IoT device communication.
Digital certificates issued by trusted Certificate Authorities (CA) during the TLS handshake can be used to verify the identities of IoT devices. Communication is then established via an encrypted channel using mirrored encryption algorithms and a secure session key generated during the handshake. These authentication mechanisms mean only authenticated devices and users can access, read, and exchange data.
What are the limitations of mTLS?
As with TLS, the additional CPU resources required for mTLS can have an impact on network latency and performance, so it must make sense for the use case to which it's being applied.
It can also be complicated to implement and manage, especially at scale, where a large number of server and device certificates are in play at any one time.
Finally, compatibility and interoperability issues with legacy systems can also be an issue. Legacy devices may lack support for TLS protocols or certificate authentication, and systems may not be compatible with one another. And, with debugging made even more challenging with mTLS-secured communications, this may be one support headache too many for your in-house IT teams.
So, again, the old adage, "just because you can, doesn't mean you should", applies.
How do you configure mTLS on a Loadbalancer.org appliance?
If you're thinking about giving mTLS a go, why not try it for yourself by following the steps outlined in this blog: How to configure mTLS on a Loadbalancer.org appliance.
There are a number of different options to consider:
- Enabling mTLS on the front-end (between the client and the load balancer)
- Enabling mTLS on the back-end (between the load balancer and the Real Servers)
- Combined in a chain
For full details check out our admin manual.
If you get stuck, feel free to reach out to our Support team with any issues.
Ready to try it?
With mTLS, both the client and server have digital certificates that they use to verify their identities to each other before exchanging any data. This helps to ensure that the connection is secure and that the data being transmitted between the client and server cannot be intercepted or tampered with by any unauthorized parties.
If you don't already have one of our appliances and want to try it for yourself for FREE, just download and have a go!