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 transmitted information, including potentially personal details. The two systems can be a server and a client (for example, a shopping site and browser) or server to server (for example, an application with personally identifiable information or payroll 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 certificate 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.

HTTPS (Hypertext Transfer Protocol Secure) appears in the URL when the site is protected by an SSL certificate. 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 establishment, followed by a TLS handshake, and then finally a message is sent.

Three handshakes and four waves.

RSA handshake

session key generation

  1. Client generates random number 1 and sends hello packet to Server with the protocol version used, supported cipher suites and random number
  2. Server generates random number 2, and sends the preferred cipher suite, server certificate and random number 2 to Client (plaintext)
    • Here Client will verify the validity of Server certificate by the CA certificate issued by server certificate to ensure that it is really server certificate.
  3. Client generates 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 “quasi master secret” by private key decryption (the only time to use private key)
  5. both Client and Server have client random number, server random number and quasi-master key. Combining these three inputs yields the “session master key (master secret)” and all subsequent communications during the session are encrypted with these new keys.

RSA Certificate Handshake Process

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, and the so-called keyless means that in step 4, the cloud forwards the encrypted “pre-master key” to its own deployed server, and then the server does the Then the server decrypts it and returns it to the cloud, as follows.

Keyless SSL handshake process

From: Cloudflare

A little thought

  • Why do we need to generate 3 random numbers

    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 received the Server certificate, it encrypted a Premaster Secret through the certificate, which is secure, so why should the final session key use 3 Randoms instead of the last encrypted Random?

    Solution: mainly in consideration of replay attack, if only the last quasi-master secret is used, then if an intermediary replayed the request, 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 number, then the replay attack can be defended against because of the presence of the server random number, because the session master key is different for each replay client request (server random is not the same).

ECDHE handshake

  1. Client generates a random number 1, the protocol version used, the list of supported encryption suites and the random number by sending hello packets to Server
  2. Server encrypts Client Random, Server Random, and Server DH parameters using its private key, and the encrypted data is used as the server’s digital signature to determine that the server has a private key that matches the public key in the SSL certificate, which, in addition to this encrypted data, also contains the server’s SSL certificate, the selected cipher suite, and Server Random.(encryption, the only place where the key is used once)
  3. Client uses the public key to decrypt the server’s message and verify the SSL certificate. Then, use the Client DH parameters to reply
  4. Both parties calculate the pre master secret separately from each other using the Client DH parameters and Server DH parameters
  5. They combine this premaster secret with the client random number and the server random number to obtain the session key

ECDHE handshake process

From: Cloudflare

Keyless SSL

ECHDE Keyless Handshake Process

From: Cloudflare

What is forward secrecy?

Forward secrecy ensures that encrypted data remains encrypted even when the private key is made public, which is also called “perfect forward secrecy”. Forward secrecy is possible if each communication session uses a unique session key and 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, but not for encryption otherwise. A short Diffie-Hellman handshake generates the session key separately from the private key, and thus 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 of a past conversation 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 specified session key.

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

Digital certificate

Composition of the 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, and the private key keeps itself hidden, and then uses its own private key to sign its own public key to generate the so-called digital certificate.

The process is about as follows.

  • server generates a file, the content of which is roughly like this (the following contents are in plain text. We call this content P).
    • The domain name of the server
    • Issuer ID: who issued the certificate
    • Subject: that is, to whom this certificate is issued. Here subject and domain should be the same
    • Expiration date (including start date and end date, to the second)
    • Date of issuance
    • Public key content
    • Other information: for example, the country and region of the server provider.
  • Then use hash algorithm to perform hash calculation on content P and get a hash value H
  • Then use the issuer’s private key to encrypt H with RSA and get the signature information S (Digital Signature)
    • This step, called signing, is to encrypt the hash value of a public content with the private key.
  • Then P and S are concatenated into a file, which is called a digital certificate.

Reference