How TLS Communication and Digital Certificates Work Together?

Typical client - server communication

• Client says hello to server and server responds with hello + public key.
• Client receives the server’s public key.
• Client generates a symmetric session key at their end, this key is then encrypted with the server’s public key.
• This encrypted session key is transmitted back to server.
• Now server decrypts the encrypted session key usings the server’s private key.
• Server have the session key now, they both can encrypt their message using this session key and communicate with each other.

MITM (Man in the middle) attack

• Now consider an attacker intercepts the packet in between, the attacker receives server’s hello + public key.
• The attacker modifies the packet with its own public key (the attacker’s public key).
• Client receives the packet i.e. hello + attacker’s public key, there’s no way client know that the key is changed by attacker.
• Client encrypt the generated session key with attacker’s public key.
• Client transmits the encrypted session key to server.

• Attacker intercepts again and decrypts the encrypted session key using their own private key (feasible because it is encrypted using attacker’s public key).
• Attacker encrypts the session key with server’s public key and sends it to the server. (Note: attacker have server’s public key after first interception)
• Server receives the encrypted session key and decrypts it with using the server’s private key and now uses the session key for encrypted communication.
• But since attacker have the session key as well it can intercept and decrypt the information anytime!!

So to prevent such risk how can the client ensure that the public key is authentic and belongs to server?

Digital certificates to the rescue

A digital certificate consists of Owner’s Identity Information (SubjectName, CommonName, Organization, Country…), Owner’s Public Key Issuer Information, Serial Number, Validity etc.

CA(Certificate Authority) is a trusted third party that issues digital certificates. They strictly verify the owners (individuals or organisations) and issue a certificate signed by their own private key.

CA’s public key comes embedded with web browsers, operating systems, websites etc. which is used to verify certificates received from other party during communication.

In RSA public private keypair, one of the key can encrypt(usually the public key), the other key can decrypt (usually the private key). But in digital certificates private key is the used to sign (similiar to encrypt) and public key is used to verify (similar to decrypt). So everyone with CA’s public key can verify(or decrypt) the digital certificate but only CA can sign(or encrypt) it.

Signing process:

1. The information is hashed using cryptographic hash algorithms like SHA256.
2. This hash is now encrypted using CA’s private key!
3. The signature is then appended to the certificate.

1
2
3

msg_digest = HASH (info) 
digital_signature = ENCRYPT (msg_digest)
digital_certificate = info + digital_signature

Verification process:

1. Decrypt the digital signature using CA’s public key.
2. Hash the certificate
3. Compare both the digest. If someone modify any content the digests will not match.

1
2
3

	msg_digest1 = DECRYPT( digital_signature )
	msg_digest2 = HASH (info) 
	Compare msg_digest1 and msg_digest2

This is how digital certificates protect against MITM attack.

• Server have a digital certificate that is signed by CA.
• A digital certificate consists of server information and its public key and signature.
• Server sends Hello + Server’s digital certificate to the client.
• An attacker intercepts the packet and modify it with its own certificate and sends Hello + Attacker’s digital certificate back to client.

• When the client receives the certificate, it decrypts it using CA’s public key. It finds out that the certificate doesn’t belong to the server as the certificate have different owner’s identity then the server’s identity.
• In other case if the attacker modify the certificate and replaces server’s public key with its own public key in the certificate. So the client will receive forged info + original digital_signature
• At client end the hash of forged info msg_digest2 will not match the msg_digest1 (decrypted digital signature).
• Also the attacker can’t change the digital signature because it don’t have CA’s private key to sign it. Even if it signs it with its own key, the CA public key at client end will not be able to decrypt it hence it will be considered invalid certificate.
• In every case Client is able to ensure Trust with Server using digital certificates.

Digital certificates protects the data integrity from unauthorized modifications and also verify the authenticity of the certificate owner’s identity. Sometimes its also called a X.509 certificate, know that X.509 is widely accepted standard for digital certificates.