## HTTPS

### Transport Layer Security (TLS)
- Focus: Network attacker
- Problem: HTTP has no security/encryption
- Idea: Encapsulate HTTP in secure channel (i.e., HTTP via SSL/TLS)

#### Basics
- Features:
	- Symmetric end-to-end encryption
	- Server authentication (Server certificates)
	- Client authentication (Client certificates, rarely used, e.g., pybits Redmine)
- 1999: TLS replaces Secure Sockets Layer (SSL)
- Provide security for connection:
	- *Integrity* using HMAC
	- *Confidentiality* using symmetric encryption
	- *Authentication* using public-key cryptography
- Supports *cipher suites*

###### Cipher Suite
- *Cipher suite*:
	- Set of algorithms for security purposes (e.g., key exchange, encryption, integrity checks)
- Components:
	- Protocol: Usually TLS
	- Key exchange algorithm:
		- Authentication and key exchange
		- e.g., RSA with Diffie-Hellman
	- Encryption:
		- e.g., AES with 256-bit CBC
	- Message authentication code:
		- e.g., SHA-256
- Cipher suite is represented by two bytes
- e.g., `TLS_DHE_RSA_WITH_AES_256_CBC_SHA256`

#### Handshake
- Phase 1: Hello
	- Client sends cipher list and a nonce
	- Server selects common suite (e.g., clients priority)
	- Server sends chosen suite, cipher list and a nonce
- Phase 2: Public key of server
	- Server sends RSA certificate + public key
	- Client checks certificate
- Phase 3: MS generation
	- Client sends certificate + public key
	- (*Client sends singed hash over all messages*)
	- Client generates PreMasterSecret (PMS)
	- Client encrypts PMS and sends it to the server
	- Server decrypts PMS
	- Both derive the MasterSecret using a key-derivation function (using PMS, Client Nonce and Server nonce)
- Phase 4: Change to Symmetric Encryption
	- Client changes to symmetric mode
	- Server changes to symmetric mode
	- End the handshake

![](images/10-handshake.svg)

#### Long-Term Connection Privacy
- Decrypt the TLS traffic:
	- Requirement:
		- Computation of MasterSecret (based on Nonces and PMS)
	- Nonces are transmitted in clear text
	- Client-generated PMS is encrypted using public key of server
	- Problem: Compromised private key of server (trivial)
	- Problem: RSA key of server doesn't change (can be compromised, decrypted, leaked, etc.)
	- Solution: Use ephemeral keys for key exchange (achieve forward secrecy)
- (Perfect) Forward Secrecy
	- Inability to decrypt past messages after compromised key
	- *Perfect*: If keys are never used again
	- *Forward secrecy protects past sessions against future compromises of secret keys or passwords* (Wikipedia)
- Diffie-Hellman
	- Goal: Two parties establish shared key
	- Agree common prime `$ p $` and generator `$ g $`
	- Parties generate private keys `$ a $` and `$ b $`
	- Public key `$ K=(g^b mod p)^a mod p $`

![](images/10-dh.png)

### Certificates

#### Server Name Indication (SNI)
- Problem:
	- Server can host several domains
	- TLS connection established using IP
- Past: One certificate per IP containing all domains
- Problem: Horrible to maintain (add domain, revoke, ...)
- Solution: Server Name Indication
	- Client sends desired domain unencrypted to server
	- Server uses correct certificate for that domain

#### Public Key Infrastructure
- Motivation:
	- MitM attack possible using RSA (replace server key)
	- Requires trust in certificate
- Idea: 
	- Chain of trust: Need to trust the certificate authority (root of trust)
- Definition *Certificate*:
	- Signed document binding a subject to some information OR identity to cryptographic key
	- Technically: Combination
		- Server's public key
		- Domain name (identity)
		- Validity timestamps
- Certificate signed with *Certificate Authority*'s  (CA) private key
- Root CAs are stored in browser

##### Validation
- Goal: Prove ownership of domain
- *Domain validation*
	- Owner should host certain file under certain path (e.g., Let's Encrypt)
- *Extended Validation* (EV)
	- Proof legal identity + physical location
	- *Green lock icon*

##### Revocation
- Important if ownership changes
- Certificate Revocation Lists (CRLs)
	- Updated by CA
	- List of revoked certificates
	- Downloaded regularly by browsers
	- Issues:
		- Interval of update by CA
		- Interval of update by browsers
		- Blacklist may miss revoked certificates/does not ensure validity
- Online Certificate Status Protocol (OCSP)
	- Client checks validity on request
	- Problem: High load on OCSP servers
	- Problem: Privacy (OCSP knows the contacted HTTPS servers)
	- Problem: Not enabled by default
	- OCSP Stapling:
		- Website issues *ticket* with limited validity from OCSP server
		- Website sends ticket to client in handshake
		- Advantages:
			- Less load on OCSP servers
			- No privacy issues
		- Disadvantage: Delay in revoked certificates

![](images/stapling.png)
### Attacks on TLS
- Problem of MitM: Hard to prevent
- Attacks:
	- SSL Stripping
	- HSTS Tracking
	- PKI Compromise
	- HTTP Public Key Pinning

#### SSL Stripping
- Special case of MitM
- Goal: Ensure that traffic from victim is plaintext
- Attacker uses HTTPS connection to server
- Rewrite response for the client:
	- Links/redirects are changed to HTTP
	- Link targets are HTTPS

![](images/10-ssl.png)
#### HTTP Strict Transport Security (HSTS)
- Server forces client to connect using HTTPS
	- HTTP header `Strict-Transport-Security`
	- Must be sent via HTTPS
- `Strict-Transport-Security: max-age=<expiry in seconds>`
	- Option `includeSubDomains`
	- Option `preload` (allow for preload list)
- Page can't be loaded via HTTP until expiry
- Problem: Page needs to be visited once
- Solution: HSTS preload list
- HSTS Tracking:
	- see *‌6 Assorted Client-Side Security - Fingerprinting Users*

#### PKI Compromise
- Attack: Compromise the root CA
- Abusing CAs: Certificates for wildcard domains
- Common mistakes:
	- Improper checks before issuing an EV certificate
	- Unauthorized employees had access to CA keys
- Real-world abuses:
	- DigiNotar (2011): Wildcard certificate for Google
	- TürkTrust (2012): Wildcard certificate for Google
	- Symantec: Google does not accept Symantec certificates

#### HTTP Public Key Pinning (HPKP)
- Defense against malicious CAs
- Problem: Domain owner can't control which CA issues a valid certificate
- Idea: Server tells browsers which CAs are trustworthy
- HTTP Header `Public-Key-Pins`
	- Provide (least) two hashes of valid certificates
		- *Main*: Certificate in the chain
		- *Backup*: Certificate not in the chain
	- Requires a second key pair
	- `pin-sha256='XXX'`
	- Only valid for a certain time
	- HPKP is deprecated
- Problem: Trust On First Use (TOFU)
	- Site must be visited once
	- No trust before the first use (already compromised server does not work...)
- **Certificate Transparency**
	- Problem: Malicious certificate are hard to detect
	- Solution:
		- Use append-only log containing *Signed Certificate Timestamp* (SCT)
		- Use log to detect mis-issue certificates


### Attacks on Certificates
- OpenSSL bug detected in 2006
	- Allowed decryption of every TLS connection
	- Problem: PRNG seeded with PID (32k possible values)
	- Attacker can pre-compute values
- SHA-1 collisions
	- SHA-1 was used in certificates


### Attacking Crypto
- RSA *export* in USA was restricted to 512 bits
- FREAK (2015)
	- Attack Diffie-Hellmann
- DROWN (2016)
- BEAST (2011)
- RC4 weakness (2015)
- POODLE
- CRIME