1. Avishai Wool Slides credit: Itamar Gilad
Introduction to Information Security , Spring Lecture 11: SSL & TLS Story of a protocol
Avishai Wool Slides credit: Itamar Gilad

2. Motivations for SSL/TLS
Online banking & online shopping
Secure access to online services (webmail, social networks and many different cloud services)
Medical & “regular” business confidential information
Protecting against phishing attacks, traffic manipulation, cookie stealing and many other forms of attack
Basic privacy – Who did I speak to, when, about what and why?

3. Located on path between browser & server Passive eavesdropper
Adversary
Located on path between browser & server
Passive eavesdropper
Packet sniffer on the network
Active MITM
Same as adversary for IPSec VPN
But client and server never met, no shared administration, no pre-shared keys

4. Definitions & History HTTPS = HTTP Secure (“HTTP over SSL”)
SSL = Secure Socket Layer
1.0 <created by Netscape, never released>
(comprehensive re-design!)
superseded by TLS, but v3 was often enabled and used until 2014 (!)
TLS = Transport Layer Security
v1.0 (1999)
v1.1 (2006)
v1.2 (2008) – current stable version
v1.3 (2015?) – draft status
Leading implementations –
S-Channel (Windows)
OpenSSL, LibreSSL (community fork), BoringSSL (fork by Google)
GnuTLS (Linux and others)
Mozilla NSS (Many), BouncyCastle (Java, C#, etc.), many more…

5. Early SSL History
Leading design criteria: protection against a passive attacker
Simplified session stages –
Alice & Bob exchange session keys using Diffie-Hellman / RSA
They also negotiate a symmetric cipher algorithm they both can use
Alice uses her session key to encrypt connection data, and sends her data to Bob
Bob does the same in the other direction
And they both lived happily ever after…
Or did they?

6. Man In The Middle

7. Solutions to the MITM Issue
Have a pre-shared secret between both parties!
But that’s really hard…
Acceptable in IPSec VPN (few endpoints)
Unacceptable for masses
Solution: Back to Public-Key cryptography

8. Simplified Public-Key (RSA) key exchange
Server has a public-private key pair
Server sends public-key (PK) to client
Client generates random symmetric key (r)
“session key”
Client encrypts M = E(PK, r), sends M to server
Server decrypts M, obtains r
Client and Server both have session key r:
encrypt remaining traffic with symmetric cipher (AES)

9. SSL Handshake Server Client Public key Private key Client request

10. SSL Session Key Server Client Private key Public key Pre-Master

11. Secure Data on Network Server Client Public key Private key
Session key
Data
Session key
Data
Data
Data
Session key
Data

12. Does this defeat MITM? Server Client Public key Private key
Client request
Bad Public key

13. Certificate Authorities
Only works if client trusts server’s public key!
Solution: Authenticate using a common third party both sides can trust
And thus, the CA (Certificate Authority) model was born

14. What is a Certificate Document including: The server’s public key
The server’s name (usually: DNS name)
Expiration date
Digitally signed by CA (using its private key)
Server (Bob) has to convince ($$$$) CA that:
the public-key is really his
he is who he says he is

15. Certificates
Each domain (or HTTP origin) must have a certificate (X.509 ITU-T)
Basic structure:
Version, Serial Number
Algorithm ID
Issuer
Validity - Not Before & Not After dates
Subject (target)
Subject Public Key Info
Public Key Algorithm
Subject Public Key
Certificate Signature Algorithm
Certificate Signature

16. Basic Certificate Authority (CA) Concept
Alice trusts the CA (has the CA’s public key)
Bob has a Certificate (signed by the CA)
Bob presents a certificate to Alice
Alice verifies the certificate (with CA’s public key)
Alice and Bob use information from the certificate to set up an authenticated session

17. Being a CA is hard Problem – Solution –
As a CA, you have to verify each certificate request and stake your reputation on it
Solution –
More CAs were created
New, more thorough validation standards added (EV = Extended Validation)
CAs delegated further. Most OS and browsers will trust root CAs out of the box, and CAs implicitly

18. Issues with the CA model
Each and every CA your system trusts can be evil (or at least – incompetent) and compromise everything
CAs can be fooled into signing bad certificates
Some CAs were compromised (DigiNotar)
Some CAs are “evil”/forced into being evil (TurkSign, CNNIC)
Even worse – even when shown to be bad, some CAs were not removed (Comodo) because they were “too big to fail”.

19. Fixing the CA model Certificate Pinning –
Storing a digest of the certificate inside the browser/application, and validating the trusted certificate yourself
Certificate transparency –
CA publishes a list of all the certificates it has ever signed
Only Certificates on that list are trusted
Anyone can audit the published list

20. Certificate Lifetime
On some occasions, the certificate must be invalidated earlier than expected (e.g.: after a server holding the private key is known to be compromised)
This is done using a protocol known as OCSP (Online Certificate Status Protocol)
When creating a new TLS connection, the client must communicate with a “OCSP Responder” for that CA to verify that the certificate is still valid
The OCSP response is signed by the CA and verified by the client

21. Problems with OCSP
If attacker can already MITM the traffic, they can fail the OCSP checks
usually fail-unsafe
OCSP overload –
OCSP is traffic heavy (an OCSP request should in theory be made before each HTTPS / TLS connection on the Internet...)
As an attacker, DDoSing the OCSP responders is very useful
Solution –
“OCSP Stapling” (TLS Certificate Status Request), which works by including a recently signed OCSP response in the TLS Handshake (sent by the Server);
Cannot be forged by the server, because the OCSP response is signed by the CA, not the certificate holder

22. Finding the Certificate in Chrome

23. Good certificate example
Latest trend: short-validity certificates

24. Bad examples

25. Reflecting trust to users
We want users to know if a site is “safe” or not
There are many things that may cause a certificate to be rejected
Too old / too new (also caused by mis-configured dates on the host)
Misconfigured servers (e.g.: presenting the wrong certificate for a subdomain)
Client & server cannot agree on a cipher
Self-signed or untrusted certificate, but not a malicious attack
Actual attack
In reality, attacks are rare
Result – not all sites use SSL/TLS

26. Other reasons HTTPS not so common
Performance issues –
though negligible for the client, a server has to perform many costly operations to support many clients
Harder to obtain, configure & maintain –
More complex & often costly than plain HTTP
Bad threat model –
“there’s no need for encryption”
Internet caching / filtering –
ISPs cannot cache (or inspect, manipulate or block) traffic that’s encrypted

27. Increasing use of HTTPS
“Let’s Encrypt” –
Free CA for everyone
Instead of background checks and real-world validation – prove validity by proving control over the domain / server content
Theoretically, no reason not to support HTTPS anymore  X

28. Review of TLS session setup

29. What’s required for a secure session?
Ciphers & MACs –
Key exchange (and authentication) method – RSA, DH-RSA, DHE-RSA (PFS), ECDH-RSA, ECDHE-RSA (PFS), DH-DSS, DHE-DSS (PFS), PSK, PSK-RSA, DHE-PSK (PFS), Kerberos, etc.
Symmetric cipher – Null, RC4, DES CBC, IDEA CBC, 3DES CBC, AES CBC, AES CCM, AES GCM, ChaCha20-Poly1305, etc.
Message authentication code – HMAC-MD5, HMAC-SHA1, HMAC-SHA256, HMAC-SHA384, AEAD, GOST, etc.
Key material –
(Authenticated) Public key material
Symmetric session keys
MAC session keys

30. Client Server TLS Handshake Example ClientHello
Highest TLS version supported
Supported cipher suites
Supported compression methods
Client Random
Client
ServerHello
Chosen TLS version
Chosen cipher suites
Chosen compression methods
Server Random
Server

31. Client Server Server Certificate ServerKeyExhange (DHE only)
ServerHelloDone
Server
ServerKeyExchange
ChangeCipherSpec
Finished (first encrypted and MAC’d message)
ClientKeyExchange (PreMasterSecret / public-key / none)
ChangeCipherSpec
Finished (first encrypted and MAC’d message)
Client

32. SSL Record Protocol Operation

33. SSL Record Format

34. Comparison of SSL V2.0 and V3.0
SSL 2.0 is vulnerable to “man-in-the-middle” attack. The ClientHello message can be modified to use 40 bits encryption.
ClientHello not signed / encrypted
Attacker forces use of weak cryptography
SSL 3.0: “Finished” message includes a hash of all the previous handshake message

35. Version Rollback Attacks
Let’s assume TLS 1.0 is secure, but we can attack SSL v3 (not a myth)
If we can find a way to make two TLS-capable hosts use an older version, we can defeat the use of encryption
If two hosts try to use TLS 1.0 and fail to negotiate a connection, they will fall-back to SSLv3

36. A word about FS/PFS PFS = “Perfect” Forward Secrecy
Using a fixed key (e.g.: RSA) to send session keys makes any past session vulnerable to future compromise in an attacker can get the private key
Using Diffie-Hellman key-exchange based modes to agree upon session keys avoids this issue
Result: Hybrid DH + PublicKey modes:
DHE-RSA, DHE-DSS, ECDHE-RSA, ECDHE-ECDSA

37. Compression Based Attacks
Any compression must be done before encryption
Thus, TLS supports compression by default
Goal: the attacker wants to know the value of a user’s cookie (i.e.: “session_id”) for domain example.com
Attacker model:
MITM, can inspect all (encrypted) traffic
Run JavaScript code in the victim browser
JavaScript makes multiple HTTPS requests to victim server
Attacker does NOT get plaintexts

38. Compression Based Attacks
The attacker’s JavaScript makes browser issue: …
The attacker can measure the length of the ciphertext, and know which guesses resulted in the shortest ciphertext
Due to compression, if a sequence is repeated, it will compress better

39. Compression Based Attacks
Once the attacker finds a candidate, they can try guessing the next byte: …
By repeating these steps (and using some methods for recovering from errors) – the attacker can recover the entire cookie in minutes

40. CRIME (2012) & BREACH (2013)
The previous example was called CRIME (Compression Ratio Info-leak Made Easy), and used TLS’s built-in compression in the client-to-server direction
Solution: Disable TLS compression in all implementations
Enter BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) –
BREACH is like CRIME, but uses HTTP’s support for compression in server responses to create a similar info-leak
It requires a server which will reflect back to the user data controlled by the attacker
Luckily, this is indeed possible (e.g.: by using error pages )

41. Logo credit: http://heartbleed.com/
HeartBleed (2014)
In SSL/TLS, a “Heart-beat” packet can be used to keep the connection alive / know when the connection has dropped
The peer will echo sent data (using length field)
OpenSSL (~66% of HTTPS servers) allowed a peer to send a heart-beat packet with fake length field
Attacker can send a small packet with a large length value  Attacker gets back a bigger answer, consisting of unknown server memory
Logo credit:

42. Logo credit: http://heartbleed.com/
Implications
Reading (dynamic) server memory
Which may contain sensitive information
And key material!
If exploited, all your security are belong to us! (can decrypt / MITM that site’s traffic)
Logo credit:

43. Logo credit: http://heartbleed.com/
Mitigation
Proper Solution –
Update to a fixed version of OpenSSL
Generate new certificates
Ask all users to change all passwords, audit anything that happened in the mean time
Never sleep well again
Reality –
Most of the Internet has been patched very quickly (<24hours)
Not all certificates have been / will be replaced
Most sites have not urged users to change passwords
Most users won’t do it anyway…
Logo credit:

44. FREAK (2015) & Logjam (2015) FREAK = Factoring RSA Export Keys
In the past, strong encryption couldn’t legally be exported from USA
SSL/TLS’s solution? – export-grade-compatibility mode, which limits RSA keys to 512 bits (which today are easy to factor)
On many common implementations, a MITM-capable attacker can force the client & server to use the export-grade keys instead of the secure copy
“Logjam” = extremely similar attack for Diffie-Hellman based key exchanges
Both attacks use weaknesses in the state-machine based implementations of SSL/TLS

45. RSA Key Generation Vulnerabilities
p, q are large random primes
n = p*q is part of the public key, included in the certificate
What if two hosts chose a common factor?
Using GCD it’s possible to crack those keys
Research: Out of 11.4 Million keys, had common factors
Reason: poor random generation!
Most collisions in embedded devices, where true random data is more scarce

46. State of the Web (06/2017) More issues have been identified
Quirky bug names
Ongoing arms race…
Report by SSL Pulse

47. TOR
TOR = The Onion Router
A distributed, community supported network for anonymity – protecting the identities of clients (and servers)
Anonymity is created by using a random path through 3 or more TOR routers
The link to each node is encrypted using another key (‘layered’ encryption  onion routing)

48. TOR session setup

49. TOR session setup

50. TOR session setup

51. TOR issues Exit nodes can be evil (snoop or attack users)
Side channels (DNS, etc.) may leak sensitive data
Endpoint security still an issue (attacks against Tor Browser, etc.)
Traffic correlation attacks demonstrated