Background
In the first article of this series, I gave a high-level overview of TLS handshake. It covers many complex concepts like encryption/decryption hash function public key private key and digital certificate. These concepts are defined in the framework of Public Key Infrastructure (PKI).
Let’ continue exploring the PKI. This article focuses on understanding the certificates used to establish trust between clients and servers.
Symmetric plus Asymmetric
Last post examined the TLS handshake. What is remarkable in this process is both symmetric encryption and asymmetric encryption are used.
symmetric encryption and asymmetric encryption are the two broad categories of cryptographic algorithms.
Symmetric key encryption uses the same key on both sides of the communication channel to encrypt or decrypt data. In HTTPS case, the client and server agree upon new keys to use for symmetric encryption, called session key. The HTTP messages are encrypted by this symmetric session key.
It has the advantage of being very fast with low overhead. In this way, it can minimize the performance impact TLS will have on the network communications.
But the real challenge of symmetric encryption is how to keep the key private and secure! The client and server must exchange keys without letting an interested eavesdropper see them. This seems like a chicken and egg problem; you can’t establish keys over an insecure channel, and you can’t establish a secure channel without keys. Right?
This key management turns out to be the most difficult part of encryption operations and is where asymmetric or public-key cryptography enters.
Simply speaking, a secure channel is firstly established with asymmetric cryptography and then the symmetric session key is exchanged through this secure channel.
Note: Cryptography is a complex topic, which isn’t in the scope of this series of articles. You can find tons of documents on the internet about it for deeper understanding. You can regard it as a block box and ignore the details. This doesn’t influence your understanding of HTTPS in high level
Why do we need certificates
Now we know public-key cryptography is needed to establish a secure channel. Can we directly transmit the public key from servers to clients? Why do we need a certificate as the carrier to pass the public key? Can we exchange the public key without certificates as follows:
But the ultimate question is how you(as the client) know that the public key can be trusted as authentic? Assume that an attacker can not only view traffic, but also can intercept and modify it. Then the attacker can carry out man-in-the-middle attack as follows:
The attacker can replace the server’s public key with its own and send it to the client. The client doesn’t feel anything wrong and keeps using this public key as normal. The client encrypts the session key with the forged public key(the one from attackers) and sends it out. The attacker decrypts the session key with its private key, re-encrypt the session key with the server’s public key, and sends it to the server. As normal, the server decrypts the session key and agrees on it. But this session key is in the attacker’s hand too. The attacker can decrypt all the subsequent network traffic.
The problem here is that the client blindly trusts that the public key belongs to the server. That’s the reason why we need the certificates to establish trust between clients and servers.
Summary
In this article, we understand the importance of public-key cryptography and certificates. In the next article, we will take a deep look at the certificate.