SSL/TLS overview

Secure web traffic with an encryption layer

view on github

SSL/TLS

✔️ HTTP over SSL/TLS, creates a secure channel over an insecure network authentication is provided by means of a signed certificate which contains a public key plus informations about the owner of the matching private key.

✔️ SSL/TLS uses PKI

Server authentication:

✔️ The most common situation (simple mode) has the client trust a server if :

  1. Certificate authorities (CA) are installed on the client
  2. The server provides a x509 certificate (CRT) signed by a CA
  3. The CRT correctly identifies the server's domain name

As a result, the certificate's owner is identified as the operator of the server

Client authentication

✔️ Another use (mutual mode) is to limit access to a server to trusted clients :

  1. Server admin creates a certificate for each client (how ? how is it signed ?)
  2. Client loads said certificates into their browsers
  3. Server verifies certificates at each client's connection

TLS v1.2

✔️ Cipher suites :

Cipher suites are agreed upon by server and client during the TLS handshake and are composed of :

  • protocol
  • key exchange algorithm
  • handshake authentication
  • session key cipher type
  • session key cipher length in bits
  • block cipher mode of operation (GCM, CBC, etc...)
  • message digest hash function
  • message digest length in bits

✔️ Initialization of a TLS session :

  1. (a) Asymmetric encryption using RSA key exchange
operation step
client requests HTTPS connection, and presents server with supported cipher suites
server picks the cipher suite and sends it to client along with its CRT
client validates server's CRT and extracts server's public key from it DIGITAL SIGNATURE CHECK
client generates PMS (PreMasterSecret) and encrypts it using server's public key KEY EXCHANGE
client sends encrypted PMS to server KEY EXCHANGE
server decrypts PMS using its private key AUTHENTICATION
PMS is simultaneously used client-side and server-side to generate the session key KEY AGREEMENT

The downside here is that there is no forward secrecy : if the encrypted traffic is recorded and server's private key is compromised, then the PMS can be extracted by the attacker, the session key can be recreated and recorded traffic can then be decrypted

  1. (b) Asymmetric encryption using DH key exchange
operation step
client requests HTTPS connection and presents server with supported cipher suites
server produces a digital signature using its private key
server picks the cipher suite and sends it to client along with its CRT and digital signature
client validates server's CRT and extracts server's public key from it DIGITAL SIGNATURE CHECK
client uses server's public key to verify server's digital signature AUTHENTICATION
server sends its DH public value to client KEY EXCHANGE
client sends its DH public value to server KEY EXCHANGE
server and client simultaneously generate session key using : KEY AGREEMENT
a. their own DH private value KEY AGREEMENT
b. the other party's DH public value KEY AGREEMENT
  1. Symmetric encryption

From now on, all client/server traffic will be encrypted/decrypted with the session key

TLS v1.3

✔️ Cipher suites :

Cipher suites are agreed upon by server and client during the TLS handshake and are composed of :

  • protocol
  • (ECDHE key exchange is mandatory in TLS v1.3)
  • handshake authentication
  • session key cipher type
  • session key cipher length in bits
  • block cipher mode of operation (GCM, CBC, etc...)
  • message digest hash function
  • message digest length in bits

Work in progress ...