SSL/TLS is an optional protocol between the application layer (HTTP) and the transport layer (TCP). Its protocol architecture is as shown below:
If HTTP communication does not use SSL/TLS, all information will be transmitted in plaintext, which involves the following risks:
SSL/TLS protocol is designed to address these risks with the following goals:
Currently, all mainstream browsers support SSL/TLS.
SSL/TLS protocol uses public-key encryption. The client requests the public key from the server first, and uses it to encrypt as well as send the information to the server. After receiving the ciphertext, the server decrypts it with its private key.
There are two problems to be solved:
SSL/TLS protocol works as follows:
The first two steps are known as "handshake".
A "handshake" involves four stages of communication where all information is transmitted in plaintext.
The client (usually a browser) first sends a request for encrypted communication to the server, which is generally called a “ClientHello” request.
In this step, the client mainly provides the following information to the server:
The information sent by the client does not contain the domain name of the server. In other words, a server can only host one website in principle. Otherwise, it would be difficult to tell which website’s digital certificate should be provided to the client. This is why each server can only have one digital certificate.
This is inconvenient for users of virtual host. To solve this, Server Name Indication was added in 2006 as an extension to TLS protocol, allowing the client to provide the server with the requested domain name.
After the server receives the client request, it sends a response to the client, which is generally called “ServerHello”. The server's response contains the following information:
If the server needs to confirm the client identity, it will also request a "client certificate". For example, financial institutions usually only allow authenticated customers to connect to their networks. Their customers are provided with USB keys, which contain client certificates.
After receiving the server response, the client will verify the server certificate. If the certificate is not issued by a trustworthy CA, the domain name in the certificate is not the same as the actual domain name, or the certificate has expired, a warning will be shown to the requester, who can choose whether to continue the communication.
If the certificate has no issues, the client will get the server's public key from the certificate and send the following information to the server:
The random number mentioned above is the third random number used during the entire handshake process, which is also known as a "pre-master key". Both the client and server now have three random numbers. They can generate the same "session key" used for this session via the encryption method agreed upon in advance.
For RSA key exchange algorithms, the pre-master key is a random number. When it is coupled with the two random numbers in “hello” messages, a final symmetric key will be generated through key derivation.
The pre-master key exists because SSL protocol does not trust that every host can generate a completely random number. The key generated by the random numbers of the client, the server, and the pre-master key will be difficult to guess. One pseudo-random number may not be completely random, but three together will create a random number.
In addition, if the server requests a client certificate in the previous step, the client will send the certificate and related information in this step.
After receiving the pre-master key (the third random number) from the client, the server calculates and generates the "session key" used for this session. It then sends the following information to the client:
The entire handshake process has now ended. The client and the server begin encrypted communication. HTTP protocol is used, except that the content is encrypted with the "session key".
Below is a simple example to illustrate the process. Assume that SSL client A communicates with SSL server B. The encrypted message is enclosed in square brackets "" to distinguish from plaintext message. The description of actions by both parties is enclosed in parentheses "()".
"I want to talk to you securely. My symmetric encryption algorithms are DES and RC5, my key exchange algorithms are RSA and DH, and my message digest algorithms are MD5 and SHA."
"Let's use the DES-RSA-SHA combination. This is my certificate, which contains my name and public key. Please use it to verify my identity."
Send the certificate to A.
"There is nothing else to say for now."
Check whether the name of B in the certificate is correct, and verify the authenticity of B's certificate with the existing CA certificate. If something is wrong, it will issue a warning and close the connection. This step guarantees that B's public key is authentic.
Generate a secret message, which will be processed and then used as the encryption key to encrypt the initialization vector (IV) and the key for HMAC. This secret message (called
per_master_secret in the protocol) is encrypted with B's public key and encapsulated into a message called
ClientKeyExchange. Using B's public key prevents eavesdropping.
"I generated a secret message and encrypted it with your public key. Here it is." Send `ClientKeyExchange` to B. "Please note that I will send you a message in an encrypted manner!"
Process the secret message to generate the encryption key, and encrypt the IV and the key for HMAC.
Use its own private key to decrypt the secret message in
ClientKeyExchange, process it to generate the encryption key, and encrypt the IV and the key for HMAC. The two parties have now securely agreed on an encryption method.
"Please note that I'm going to send you a message in an encrypted manner!"
[My secret is...]
[No one else can eavesdrop that...]