SSL/TLS Theory
Update: 2022
TLS
TLS is a protocol that is used in web environment. The main goal of TLS is to offer a secure communication between a web server and a client by encrypting the traffic. Authentication is also at the core of TLS session. Before the establishment of any TLS session, the web server needs to authenticate to the client to prevent the establishment of a session with a rogue server. A web server, for example a Google server, can prove who he claims to be by presenting to the browser a valid certificate.
All SSL protocols are deprecated
SSL 1.0
SSL 2.0
SSL 3.0
Not recommended to use
TLS 1.1
TLS 1.0
Recommended
TLS 1.2
TLS 1.3
TLS 1.2 Handshake
The image below illustrate the steps of a TLS 1.2 handshake leading to the creation of a TLS session. As we can observe, the process involve many back and forth between the client and the server.
Asymetric vs symetric encryption
Asymmetric encryption
Asymmetric encryption uses a set of two keys, one is Public and the other is Private. While the Private key needs to be stored very securely, the Public key can be shared with anyone else. It is like saying to everyone else how to communicate with me securely.
For example, Bob gave to Alice his Public key saying "Hey, if you want to communicate with me here is the key to do so". Then, the sender of a message (Alice) will encrypt the data with the public key given by Bob, and only the owner (Bob) of the private key will be able to decrypt it.
Downside: A way slower than symmetric encryption.
Symmetric encryption
In symmetric encryption all parties share the same key and this key is used to both decrypt and encrypt data. The issues is that the key needs to be shared between legitimate parties but while the key is being transferred between parties it is exposed to Man In The Middle Attack.
PKI infrastructure
A PKI infrastructure is an infrastructure used to communicate between parties using public key encryption. A PKI includes the Certificate Authority, the Certificate signing request, Intermediate CA, public and private keys generated to encrypt and decrypt data, certificates.
Schema illustrating the TLS handshake with Diffie Hellman Exchange
Chain of trust
The schema below illustrates the mechanism by which a browser can trust a end user certificate when interacting with a web application over HTTPS. The image shows that the end user certificate is signed by an Intermediate Certification Authority (CA) which is in turn trusted by a Root CA. The certificates issued by the Root CA are trusted by default by the operating system. Each level of the hierarchy has a private and a public key. The private key is used to sign the certificate issued by the next authority in the chain. The public key of each instance are used to verify the validity of the lower level certificates in the chain during the validation process.
When a web browser request a web page, the web server sends the entire chain of certificates (end user and Intermediate CA). Root certificate is not send because it is assumed that it is already located on the OS. This chain of certificate will be used by our browser to verify the identify the web server.
Self-sign certificate
We can recognize a self-signed certificate if the Issuer is the same as the Subject.
Root certificates
Root certificates are trusted by default by our browser and can be found in our operating system. The image below shows the list of certificates trusted by the operating system (Windows 10)
Certificate domain scope
Single domain
The certificate might be used only on a single domain
www. instagram.com
www.mywebsite.com
Wildcard
The certificate might be used on a domain and its subdomain.
*.google.com
*.mywebsite.com
Multidomain
The certificate might be used for multiple domains and subdomains.
*.facebook.com
*fb.com
*messenger.com
In self-signed certificates, the issuer and subject are the same.
Certificate validation
Domain validation: By default, the certificate issuer will proceed to a domain validation. To get issued a certificate, the requester will need to prove that he owns the domain.
Extended validation: The requester of the domain needs to prove that he's the owner of the company he request the domain for.
Diffie Hellman Key Exchange
The Diffie Hellman Key allow the generation of a shared symmetric key between two parties over an insecure channel of communication. This key will be used to encrypt and decrypt the data exchanged between the two parties. For more information on DHE see this section.
Last updated
