Overview

This is a stock article that has been around for two or three years, but I haven’t released it because there’s nothing special about it. I recently came across this article because I used some HTTPS content when I was doing a requirement, so I simply summarised it and released it. I’ll talk about it.

TLS and SSL

What is SSL

SSL stands for Secure Socket Layer, in short it is the standard technology for keeping internet connections secure, protecting any sensitive data sent between two systems and preventing criminals from reading and modifying any information transmitted, including potentially personal details. The two systems can be a server and a client (for example, a shopping website and browser) or server to server (for example, an application with personally identifiable information or salary information).

It does this by ensuring that any data transferred between the user and the website or between the two systems cannot be read. It uses encryption algorithms to tamper with the data in transit and prevents hackers from reading the data in the connection. This information could be anything sensitive or personal, including credit card numbers and other financial information, names and addresses.

What is TLS

TLS (Transport Layer Security) is simply a newer, more secure version of SSL. We still refer to our security certificates as SSL because it is a more commonly used term, but when you purchase an SSL from DigiCert, you are actually purchasing the latest TLS certificate with the option of ECC, RSA or DSA encryption.

When a website is protected by an SSL certificate, HTTPS (Hypertext Transfer Protocol Secure) appears in the URL. Click on the lock symbol in the browser bar to view the details of the certificate, including the issuing authority and the company name of the website owner.

HTTPS connection establishment process

TCP connection

https requires a TCP connection to be established, followed by a TLS handshake, and finally a message is sent.

Three handshakes and four waves

RSA handshake

Session key generation

  1. The Client generates a random number 1, the protocol version used, the encryption suite supported and the random number, by sending a hello packet to the Server
  2. Server generates random number 2 and responds with the preferred cipher suite, server certificate and random number 2 to the Client (in plaintext)
    • Here Client will check the validity of Server certificate by the CA certificate issued by server certificate to ensure that it is really server certificate
  3. Client generates a random number 3, the so-called “quasi master secret”, and then sends it to the server by encrypting it with the public key in the server certificate
  4. Server obtains the “quasi master secret” by decrypting the private key (the only time the private key is used)
  5. both Client and Server have a client random number, a server random number and a quasi-master key. Combining these three inputs gives the “session master secret” and all subsequent communications during the session are encrypted with these new keys.
Figure 1：RSA Encrypt Handshake
From: Cloudflare

Keyless SSL

If the application is deployed on the cloud, but the private key does not exist on the cloud (locally for security reasons), then the private key needed in step 4 also needs to be placed on the cloud, the so-called keyless means that in step 4, the cloud forwards the encrypted “pre-master key” to its own deployed server, which then decrypts it and returns it to the cloud, the process is.

Figure 2：Keyless SSL Handshake
From: Cloudflare

A bit of food for thought

In the first handshake, a Client Random is sent, and then the Server returns a Server Random, both of which are insecure; after the Client receives the Server certificate, a Premaster Secret is encrypted by the certificate, which is secure, so why should the final After the Client receives the Server certificate, it encrypts a Premaster Secret through the certificate, which is secure, then why should the final session key use 3 Randoms instead of the last encrypted Random directly?

Answer: The main reason for this is the consideration of replay attack, if only the last Premaster secret is used, then if an intermediary replayed the request, then the connection would use the same key ( Since I don’t know much about cryptography, I don’t know how much damage this can do, but from reading some articles this is not a good practice). So, at this point, if there is a server random, then a replay attack can be defended against by the presence of the server random, because the session master key is different for each replay client request (server random is not the same).

ECDHE handshake

  1. the Client generates a random number 1, the protocol version used, the list of supported encryption suites and the random number, by sending a hello packet to the Server
    Server encrypts Client Random, Server Random and the Server DH parameter using its private key. The encrypted data is used as the server’s digital signature, thus establishing that the server has a private key matching the public key in the SSL certificate, which in addition to this encrypted data contains the server’s SSL certificate, the selected cipher suite and Server Random. (encrypted, the only place where the key is used once) 3.
    The Client uses the public key to decrypt the server’s message and verify the SSL certificate. The Client then replies using the Client DH parameters. 4.
  2. Both parties calculate the pre-primary secret separately from each other using the Client DH parameters and Server DH parameters. 5.
    They combine this pre-secret with the client random number and the server random number to obtain the session key
Figure 3：ECDHE Handshake
From: Cloudflare

Keyless SSL

Figure 4：ECHDE Keyless Handshake
From: Cloudflare

What is forward secrecy?

Forward secrecy ensures that encrypted data remains encrypted even when the private key is made public, this is also known as “perfect forward secrecy”. Forward secrecy is possible if each communication session uses a unique session key and if the session key is generated separately from the private key. If a single session key is compromised, an attacker can only decrypt that session; all other sessions will remain encrypted.

In protocols set up for forward secrecy, the private key is used for authentication during the initial handshake, otherwise it is not used for encryption. A short Diffie-Hellman handshake generates the session key separately from the private key, and therefore has forward secrecy.

In contrast, RSA has no forward secrecy; in the case of a compromised private key, an attacker can decrypt the session key for past conversations because they can decrypt the pre-master secret in plaintext form as well as the client random number and the server random number. By combining these three, an attacker can obtain any given session key.

Simple to understand: if the key is lost, will the previous history (including the handshake process being recorded by someone) be cracked. If it can be cracked, then it is not, if not, then it is forward secrecy.

Digital certificates

Components of a certificate

First of all, there is an authoritative certificate issuing authority called CA - there are only a few companies in the world that are more authoritative. This authority, firstly, uses RSA to generate a pair of public and private keys, the private key keeps itself hidden, and then uses its own private key to sign its own public key, generating the so-called digital certificate.

The process is roughly as follows.

Ref