What makes mTLS different to standard TLS is that it is two ways. It is also helpful to understand how TLS on its own works using the public key cryptography that it uses to establish the trust between server and client and secure encryption.
In the OSI model TLS is built upon the TCP in the session layer. This provides the encryption for numerous application layer protocols such as HTTPS that we see when we brows the web.
Encryption
One might ask what is encryption?
Encryption is the process where plain text, such as what you are reading in this post, is converted into ciphertext in an attempt to protect the information from unauthorized access.
This process is done by using an encryption algorithm, and key. The key is kept secret by those parties involved in the communication.
The cipher text (encrypted data) can only be decrypted back into plane text and made readable to that person who has the corresponding decryption key.
For example, this will allow original plaintext to be transmitted securely over a network without a risk of being intercepted or read by any outside parties.
When network data is encrypted, this is known as “encryption in transit”, or “encryption on the wire.”
Encrypting data when its being stored, such as on a disk drive or cloud storage is known as “encryption at rest”.
When speaking about encryption int he context of TLS and mTLS, we are talking about encryption in transit.
- Symmetric Encryption
- Asymmetric Encryption
In terms of symmetric encryption the same key is used to encrypt and decrypt.
On the other hand with asymmetric encryption you a different key which is used for encryption and decryption.
Each of the above encryption methods have their own weakness as well as strengths, but both are often used together to provide a combination of security as well as convenience.
Symmetric Cryptography Using A Secret Key
In symmetric cryptography a single secret key is used to encrypt and decrypt any messages.
These secret keys are shared between the client and server, but these are to be kept secret, meaning that only the client and server know what the private key is since anyone that has this key can read the messages.
Symmetric cryptography is less computationally intensive over asymmetric encryption, but it comes with a few disadvantages in particularly with key management.
When it comes to client server communications, the key needs to be shared securely between both the client and server. This is tricky to do securely over a network especially when going over the internet.
It is important that the shared key is kept secret, because anyone that gets their hands on this key would be able to decrypt the ciphertext.
This is why TLS and mTLS use asymmetric encryption to establish the secure channel and then swap over the the more efficient symmetric cryptography in order to encrypt the rest of the communications.
Asymmetric Cryptography Using A Pair of Public & Private Keys
In asymmetric cryptography it uses a pair of public and private keys ot encrypt and decrypt the data.
Messages are encrypted using the public key, and the receiver decrypts them with a corresponding private key.
Client and servers share the public keys with each other while the private keys remain private.
When you have a client that sends a message to the server, the message is encrypted using the server’s public key. When the information gets to the server it uses the private key to decrypt the messages.
The same applies when the server sends a message to the client, the server encrypts the message with the client’s public key and on the clients end it uses the private key to decrypt the message from the server.
Given that neither the client or server need to share a secret key, their public keys do not need to be shared securely.
As a result asymmetric cryptography works great in an environment such as the internet.
The only downside is that asymmetric cryptography can be a magnitude more computationally intensive than symmetric cryptography.
Symmetric & Asymmetric Cryptography Used By TLS to Balance Security & Efficiency
Using a combination of symmetric & asymmetric cryptography, TLS uses both methods to strike a balance between security and computational efficiency.
The computationally expensive asymmetric encryption is used to generate and exchange the shared secret session keys during the handshake when the TLS connection is established.
Shared session keys are used by both the client and server to both encrypt and decrypt the remainder of their communication using the less computationally intensive symmetric encryption.
With each communication sessions, the session keys are unique and provide better security by ensuring that each session has its own set of keys. This limits the risk of session key compromise.
Once the communication session has ended the session keys are discarded and a new set of session keys gets generated for any subsequent sessions.
Public Key Certificates & Their Respective Certificate Authorities (CA), & The Public Key Infrastructure (PKI)
The use of public keys in asymmetric cryptography do not require to have the secret to be kept secret, but it can be shared publicly.
What is important that one must do is ensuring that the public keys are authentic and legitimate to the server you are actually connecting to and the server you think that it actually is, a not a threat actor having you connect to a fake server through a man in the middle attack and that the public given is not a fake.
In order for TLS to achieve this, it relies on a system of digitally signed certificates which are issued by a trusted 3rd party known as a certificate authority (CA) which is used to prove that a public key is authentic and that the identity that is being provided by the server is also authentic.
The public key infrastructure (PKI) has been established as a system which issues, validates and revokes public key certificates. This is based off of the ITU-T recommendation X.509 | ISO/IEC 9594-8, page 9.
TLS uses public key certificates that confirm to the X.509 standard. Such certificates contain the following information:
- Certificate issuing authority
- Identity of the server that is sharing this certificate
- public key that is used for encryption
- Digital signature to prove authenticity of the servers identity as well as the validity of the key
- Time window for the certificate prior to it expiring
When a TLS handshake takes place, the server presents the certificate to the client to prove the authenticity of the servers identity and its respective public key that is attached to the certificate.
The client in turn uses the public key that is attached to the certificate so it encrypts messages to the server.
Root Certificate Authorities (CAs) and Root Certificates
In order for the public key infrastructure to work, there must be an agreement between everyone and everything on a set of one or more trusted third parties.
The trusted third parties are known as root CA’s and they create and publish self signed “root certificate.”
Usually devices have a set of trusted root certificates securely installed in what is know as the “root store” or “root CA bundle.”
The presence of a root certificate in the root store of a device establishes trust in the root CA that issued the root certificate.
In terms of the public internet, the root CA’s are operated by the well known commercial or non profit organizations, but some organizations operate their own PKI with their own CA’s.
Intermediate Certificates & Subordinate CA's
Security of the private keys that are held by a root certificate authority is crucial, since there is no way to revoke a root certificate. As a result of this root certificate authorities are almost never online.
As a result of this root CA’s delegate their authority to subordinate certificate authorities by issuing an “intermediate certificate” to the subordinate Certificate authority.
The validity of these intermediate certificates can be traced back to the root CA that issued them.
As well intermediate certificates can be revoked and further authority can be delegated by subordinate Certificate Authorities also by issuing intermediate certificates.
Leaf Certificates & Certificate Chains
An “end entity” or “leaf” certificate is issued for individual server by a certificate authority.
The certificates are the “leaves” in a hierarchical tree of authority and is traceable from the leaf (Server) back up through the intermediate certificate finally getting back to the trusted root certificate.
On the client side the certificate is first validated to ensure that the certificate was issued by the CA and has not been tampered with, and then the below additional steps are carried out:
- Checks the status of the certificate: What gets checked is the expiration date any any other information such as domain name or the public key of the subject, ensuring that the certificate is still valid.
- Checks the certificate chain: The client follows the links in the certificate chain. It starts with the server leaf certificate, the intermediate certificates in the chain are then checked. This information in the certificate is used to verify the trustworthiness of the next certificate in the chain until you get to the root certificate.
- Validation of the root certificate: The client then validates the trusted root certificate. This is done by checking that it is in the list of trusted root CAs. This ensures that the root certificate is a trusted and authoritative source of information for other certificates.
Certificate Authority (CA) Bundle
A “CA bundle” is a list of trusted root TLS certificates installed on a clients machine.
This bundle is used to verify a server’s certificate signature and determine if it was trusted by the certificate authority.
If the signature is verified the client can trust the certificate that is associated with the server its communicating with.
Certificate Revocation
When working with a Public Key Infrastructure (PKI), certificate revocation is a process where a certificate is declared invalid prior to its expiration date.
This is usually done when a certificate is no longer trustworthy, such as with the private key associated with that respective certificate has been compromised or the subject of the certificate is no longer authorized to use it.
A client can ask a CA if the certificate that is being offered by a server is still valid or not.
There are 2 techniques that can be used.
- Certificate Revocation List.
- Newer online certificate status protocol (OCSP).
When using a certificate revocation list a certificate authority publishes a signed list of the revoked certificates that a client can check if the server certificate is still valid.
when using OCSP, a client can request the status of a particular certificate.
By allowing certificates to be declared invalid or untrustworthy, certificate revocation helps to protect against any security risks and helps to ensure that confidentiality and privacy of sensitive information is transferred over a secure connection.
TLS Handshake
When a client initiates a secure connection with a server a TLS handshake is negotiated to determine the TLS protocol to use, as well as establish the identity of the server as well as generate the shared session keys that are used for the symmetric encryption portion of the messages.
There are three steps that we can see in the image above to confirm that the certificate is valid, and that the transmission of information is secure and encrypted.
- A request from a client to a server that contains info such as the TLS version, and the password combination that is supported by the client. The server responds to the clients request and attaches the respective digital certificate.
- Client then verifies the status, validity, and the digital signature of the certificate and confirms the identity of the server. The client and server then agree on and exchange a shared secret session key.
- Lastly encrypted communication between the client and server can be done using the symmetric encryption with shared secret key.
Reference:
Leave a Reply