HTTPS¶

Transport Layer Security (TLS)¶

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:
- 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

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

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

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

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

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

../_images/stapling.png

Problem of MitM: Hard to prevent
Attacks:
- SSL Stripping
- HSTS Tracking
- PKI Compromise
- HTTP Public Key Pinning

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

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

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

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

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