Understanding TLS

## Understanding TLS
					High level introduction to Transport Layer Security 
					
					(and sorta HTTPS)
					---
					## Takeaways
					- What is HTTPS 
					- Mental model of how the various parts of TLS fit together 
						- Easily work on TLS configuration tasks or resolve any cert issues 
					- "If our private CA decides to use a new root cert, what do we need to do?" 
					---
					## Overview
					- Super brief intro to TLS, HTTPS
					- Asymmetric & Symmetric Encryption
					- TLS Connection & Handshake
					- Digital Signatures
					- Certificates
					---
					## TLS, HTTPS 
					- Transport Layer Security (Latest version: 1.3)
					- Provides a way to encrypt your communication 
						- HTTPS = Using TLS to encrypt your HTTP messages
					- What's SSL? 
						- TLS supersedes SSL
						- Terms often used interchangeably
					---
					## Symmetric & Asymmetric Encryption
					---
					### Symmetric Encryption
					- The same key is used to encrypt and decrypt
						- Both parties need to have the same key
					- E.g.
						- AES
						- DES
					---
					### Asymmetric Encryption (Public-key cryptography)
					- A pair of keys (public key, private key)
						- Use public key to encrypt and private key to decrypt
					- Can you do it the other way around? 
						- Yes
							- RSA algorithm (keys can be interchanged, but different security properties)
						- No
							- Most other algorithms (keys are not interchangeable, e.g. Diffie-Hellman)
					---
					## What is a TLS connection?
					- Data transferred is encrypted using a symmetric key
						- For HTTPS, data = HTTP messages
					- Both parties needs to arrive at the same symmetric key, how?	
						- TLS handshake (asymmetric encryption happens here; certs, digital signature, public key, private key) 
					---
					<p class="stretch"><img src="https://hpbn.co/assets/diagrams/b83b75dbbf5b7e4be31c8000f91fc1a8.svg"></p>

---
					## TLS v1.2 Handshake
					- Why 1.2 instead of 1.3? 
						- More intuitive to understand the purpose of the various components from 1.2's handshake
					---
					<style>
					.container {
						display: flex;
					}
					.flex-col{
						flex: 1;
					}
					</style>

<div class="container"> 
	
					<div class="flex-col" data-markdown>	
					
					
					![handshake](https://hpbn.co/assets/diagrams/b83b75dbbf5b7e4be31c8000f91fc1a8.svg)
						
					</div>
					<div class="flex-col" data-markdown>

Client sends
					- Client random

</div>
					<div class="fragment fade-in-then-out">
					
					Server sends
					- Server random
					- **Certificate** (this contains the public key of the server)
					- **Digital signature** of this message signed by the server's private key
					
					</div>
					<div class="fragment fade-in-then-out">
					
					Client verifies
					- Certificate against its CA certs store (which contains recognized CA certificates)
					- Digital signature
					</div>
					<div class="fragment fade-in-then-out">
					
					Client uses
					- Public key (in the server certificate) to encrypt a pre-master secret and sends it to the server
					</div>

<div class="fragment fade-in-then-out">
					
					Client uses
					- Pre-master secret
					- Client random
					- Server random

to generate the symmetric key 
					</div>

<div class="fragment fade-in-then-out">
					
					Server uses
					- Pre-master secret
					- Client random
					- Server random
	
					to generate the symmetric key 
					</div>

<div class="fragment fade-in-then-out">
					
					Server & client uses symmetric key to encrypt and decrypt application data

</div>
					
					</div>

</div>
					---
					Based on the handshake, we'll go more in depth on
					1. Digital signature
					1. Certificates

---
					### Digital signature
					"Client verifies the digital signature of the message signed by the server's private key"
					
					---
					## What is a digital signature?
					- fn(sent_message_hash, private_key) such that we can verify it against fn(received_message_hash, public_key)  
					- What does it guarantee? 
						- Origin - Validates that it's signed by the private key, and because nobody else should own the private key
						- Integrity - Validates the message hash, so what's received = what's sent
					---
					<style>
					.container {
						display: flex;
					}
					.flex-col{
						flex: 1;
					}
					</style>
	
					<div class="container"> 
	
					<div class="flex-col" data-markdown>	
					
						
					![handshake](https://hpbn.co/assets/diagrams/b83b75dbbf5b7e4be31c8000f91fc1a8.svg)
					</div>
					<div class="flex-col" data-markdown> 
					
					Server sends
					- Server random
					- **Certificate** (this contains the public key of the server)
					- **Digital signature** of this message signed by the server's private key
					
					</div>
					</div>
					</div>
					---
					## Certificates
					"Client verifies the certificate (given by the server) against its CA certs store (which contains recognized CA certificates)"
					- There are actually 2 types of certs here 
						- Cert given by the server (i.e. the server cert, contains the public key of the server)
						- Certs in the CA certs store (i.e. the root certs store, contains the public keys of the root CAs)
					---
					## Verifying the server certificate
					- The server cert must be issued by a CA whose cert is in the root CA certs store*
					- The principle here is that the CA has done its checks to ensure that the entity owning the server is legitimate before issuing the cert

---
					## How to verify that a cert was issued by the CA?
					- Apply what we learnt about signing!
					- The server cert has a digital signature and was signed by the CA using their private key, and we have the public key of the CA in our CA certs store! 
						- *fn(sent_message_hash, private_key) such that we can verify it against fn(received_message_hash, public_key)*
						- Origin & Integrity
					---
					## Examples
					---
					<img src="minio_console.png"  height="50%" width="50%">

Using your web browser to access MinIO's console page via HTTPS

- MinIO needs to have a server cert
					- Web browser needs to have the cert of the CA that issued MinIO's server cert, in its cert store

---
					Our Java app accessing MinIO's API via HTTPS

- MinIO needs to have a server cert
					- Our Java app needs to have the cert of the CA that issued MinIO's server cert, in its cert store
						- `JAVA_HOME/lib/security/cacerts`

---

```bash
					curl: (60) SSL certificate problem: unable to get local issuer certificate
					More details here: https://curl.haxx.se/docs/sslcerts.html
					```

or similar problems, what is it about?

When we `curl --insecure` or similar things (e.g. `sslVerify=false`), what are we essentially doing?

---
					## Self-signed certs (w/o a CA)
					- Use `openssl` to generate for your servers
					- Won't be recognised by clients unless installed in clients' certs store

---
					## How to be issued a certificate from the CA?
					- Create a cert signing request (CSR), which contains your public key and sends it to a CA

---
					
					## Aren't you simplifying?
					Yes, I am

---
					
					## Intermediate CAs & Certificates
					- *The server cert must be issued by a CA whose cert is in the root CA certs store*
						- Not necessarily

---

## Intermediate CAs & Certificates
					- The root CA whose cert is in the root certs stores can grant someone else, an Intermediate CA the ability to issue certs 
						- (who can then grant someone else)
						- such that the issued cert can verified with the root CA's cert 
						
						- Certificate chain

---

## Certificate chain
					- Root CA -> Server cert
						- Verify server cert against root CA's cert in the root certs store
					- Root CA -> Intermediate CA -> Server cert  
						- Verify server cert against intermediate CA's cert 
						- Verify intermediate CA's cert against root CA's cert in the root certs store  
					- Root CA -> Intermediate CA1 -> Intermediate CA2 -> Server cert? 
					
					---
					## How to verify certificate chain?
					---
					<style>
					.container {
						display: flex;
					}
					.flex-col{
						flex: 1;
					}
					</style>
					
					<div class="container"> 
	
					<div class="flex-col" data-markdown>	
					<img src=https://miro.medium.com/max/256/1*9EbN8Qslk350q3BXzZruXw.png >
					</div>
					<div class="flex-col" data-markdown> 
	
					<div class="r-stack">
					<div class="fragment fade-out">

- The server cert is appended with the intermediate CA certs
					- When the cert is presented to you (client) by the server
						- Verify down the chain

</div>
					<div class="fragment fade-in">
					
					1. Server cert's digital signature against Intermediate CA's public key (inside cert)
					1. Intermediate CA cert's digital signature against root CA's public key (inside root cert store) 
					</div>
					</div>
					</div>
					---

## Summary

- How TLS encrypts HTTP to form HTTPS
						- Symmetric key encryption
						- TLS handshake
					- Digital signatures
						- How it works
					- Certificates
						- Server cert & CA certs
						- Examples & common issues
						- Intermediate CAs & certs

---
					"If our private CA decides to use a new root cert (based on a new key pair), what do we need to do?"

---
					- Have we included the new CA cert in the necessary cert stores?
						- Web browser
						- Java cert store

- Do we need to get new server certs?
						- Is the old CA cert going to expire or revoked from the root certs stores?

---
					## Hope you had some takeaways!

---
					## References

1. [Computerphile's video on TLS handshake](https://www.youtube.com/watch?v=86cQJ0MMses)
					1. [High Performance Browser Networking](https://hpbn.co/transport-layer-security-tls/)
					1. [Intermediate Certificates I](https://www.thesslstore.com/blog/root-certificates-intermediate/)
					1. [Intermediate Certificates II](https://jamielinux.com/docs/openssl-certificate-authority/create-the-intermediate-pair.html)