SSL/TLS: The Ugly Truth
Examining the flaws in SSL/TLS protocols, and the use of certificate authorities.
Adrian Hayter
CNS Hut 3 Team
adrian.hayter@cnsuk.co.uk
Contents
• Introduction to SSL/TLS
• Cryptography Crash Course
• Certificates
• Weaknesses in SSL/TLS
• The Certificate Authority System
• Solutions & Recommendations
• Questions
What is SSL/TLS?
Secure Sockets Layer (versions 2.0, 3.0)
Transport Layer Security (versions 1.0, 1.1, 1.2)
Cryptographic protocols that allow secure communication over a network.
Uses:
• Authentication of participants.
• Key exchange.
• Encryption of data.
• Data integrity.
What is SSL/TLS?
Secure Sockets Layer (versions 2.0, 3.0)
Transport Layer Security (versions 1.0, 1.1, 1.2)
Cryptographic protocols that allow secure communication over a network.
Uses:
• Authentication of participants.
• Key exchange.
• Encryption of data.
• Data integrity.
Cryptography Crash Course
If you already know about cryptography, feel free to ignore the
next few slides!
Cryptography Crash Course: Symmetric Cryptography
Alice Bob
Alice and Bob both have a copy of a secret key.
Alice encrypts a message using the secret key and sends it to Bob. Bob decrypts the message using the secret key.
Bob encrypts a message using the secret key and sends it to Alice. Alice
decrypts the message using the secret key.
Cryptography Crash Course: Symmetric Cryptography
• Encryption / Decryption is simple and easy for a computer to do. Secret keys are also easy to generate.
• Requires participants to have set up the shared secret key beforehand.
Problems:
How do participants set up a shared secret key?
What if the participants don’t know each other?
Cryptography Crash Course: Symmetric Cryptography
• Encryption / Decryption is simple and easy for a computer to do. Secret keys are also easy to generate.
• Requires participants to have set up the shared secret key beforehand.
Problems:
How do participants set up a shared secret key?
What if the participants don’t know each other?
Cryptography Crash Course: Asymmetric Cryptography
Alice Bob
Alice and Bob generate their own private and public key pairs.
Alice encrypts a message with Bob's public key and sends it to Bob. Bob decrypts the message with his private key.
Alice and Bob share their public keys with each other.
Bob encrypts a message with Alice's public key and sends it to Alice. Alice
decrypts the message with her private key.
Cryptography Crash Course: Asymmetric Cryptography
• Asymmetric Cryptography is also known as Public-key Cryptography.
• Public / Private keys are mathematically linked. Knowledge of one of the keys does not compromise the other.
• Does not require the participants to have set up any shared secrets beforehand, or even know each other.
Problem:
Both the key pair generation and the encryption / decryption
processes are complex and take much longer for computers to do
than with symmetric cryptography.
Cryptography Crash Course: Asymmetric Cryptography
• Asymmetric Cryptography is also known as Public-key Cryptography.
• Public / Private keys are mathematically linked. Knowledge of one of the keys does not compromise the other.
• Does not require the participants to have set up any shared secrets beforehand, or even know each other.
Problem:
Both the key pair generation and the encryption / decryption
processes are complex and take much longer for computers to do
than with symmetric cryptography.
A Solution
We can combine symmetric and asymmetric cryptography.
..
1
Alice & Bob generate public/private keys beforehand.
..
2
When Alice wants to send a message to Bob, she asks Bob to send her his public key.
..
3
Bob sends Alice his public key.
..
4
Alice creates a symmetric key, encrypts it using Bob’s public key, and sends the encrypted key to Bob.
..
5
Bob decrypts the symmetric key using his private key and stores it.
..
6
Alice and Bob can now encrypt/decrypt messages using the
shared symmetric key.
A Solution
We can combine symmetric and asymmetric cryptography.
..
1
Alice & Bob generate public/private keys beforehand.
..
2
When Alice wants to send a message to Bob, she asks Bob to send her his public key.
..
3
Bob sends Alice his public key.
..
4
Alice creates a symmetric key, encrypts it using Bob’s public key, and sends the encrypted key to Bob.
..
5
Bob decrypts the symmetric key using his private key and stores it.
..
6
Alice and Bob can now encrypt/decrypt messages using the
shared symmetric key.
A Solution
We can combine symmetric and asymmetric cryptography.
..
1
Alice & Bob generate public/private keys beforehand.
..
2
When Alice wants to send a message to Bob, she asks Bob to send her his public key.
..
3
Bob sends Alice his public key.
..
4
Alice creates a symmetric key, encrypts it using Bob’s public key, and sends the encrypted key to Bob.
..
5
Bob decrypts the symmetric key using his private key and stores it.
..
6
Alice and Bob can now encrypt/decrypt messages using the
shared symmetric key.
A Solution
We can combine symmetric and asymmetric cryptography.
..
1
Alice & Bob generate public/private keys beforehand.
..
2
When Alice wants to send a message to Bob, she asks Bob to send her his public key.
..
3
Bob sends Alice his public key.
..
4
Alice creates a symmetric key, encrypts it using Bob’s public key, and sends the encrypted key to Bob.
..
5
Bob decrypts the symmetric key using his private key and stores it.
..
6
Alice and Bob can now encrypt/decrypt messages using the
shared symmetric key.
A Solution
We can combine symmetric and asymmetric cryptography.
..
1
Alice & Bob generate public/private keys beforehand.
..
2
When Alice wants to send a message to Bob, she asks Bob to send her his public key.
..
3
Bob sends Alice his public key.
..
4
Alice creates a symmetric key, encrypts it using Bob’s public key, and sends the encrypted key to Bob.
..
5
Bob decrypts the symmetric key using his private key and stores it.
..
6
Alice and Bob can now encrypt/decrypt messages using the
shared symmetric key.
A Solution
We can combine symmetric and asymmetric cryptography.
..
1
Alice & Bob generate public/private keys beforehand.
..
2
When Alice wants to send a message to Bob, she asks Bob to send her his public key.
..
3
Bob sends Alice his public key.
..
4
Alice creates a symmetric key, encrypts it using Bob’s public key, and sends the encrypted key to Bob.
..
5
Bob decrypts the symmetric key using his private key and stores it.
..
6
Alice and Bob can now encrypt/decrypt messages using the
shared symmetric key.
A problem with our solution!
Alice and Bob don’t ever verify that they are actually talking to each other!
“Man in the Middle Attack”
Alice Bob
"Hey Bob, it's Alice. Can I have your public key?"
Mallory
"Hey Bob, it's Alice. Can I have your public key?"
Bob sends his public key. Mallory sends his public key.
How do we solve this problem?
A problem with our solution!
Alice and Bob don’t ever verify that they are actually talking to each other!
“Man in the Middle Attack”
Alice Bob
"Hey Bob, it's Alice. Can I have your public key?"
Mallory
"Hey Bob, it's Alice. Can I have your public key?"
Bob sends his public key.
Mallory sends his public key.
How do we solve this problem?
Certificates
A digital certificate binds a public key to an identity using a digital signature.
The digital signature almost always comes from a trusted third party.
If the signature is trusted, the certificate is valid, and the public key is verified to belong to the specified identity.
In the SSL/TLS system, X.509 certificates are signed by
Certificate Authorities (e.g. VeriSign, Comodo, Entrust,
PositiveSSL). More on these later...
Certificate Fields
Subject: The identity the public key belongs to (e.g. Bob, www.example.com).
Issuer: The identity that signed and issued the certificate (e.g.
VeriSign).
Signature: The signature of the issuer.
Not Before / Not After: Dates when the certificate is valid.
Public Key: The subject’s public key.
Version, Serial Number, Signature Algorithm, Public Key Algorithm
(Highly) Simplified SSL/TLS Handshake
Client Server
Client requests SSL/TLS connection. Sends some random bytes to the server.
Server sends certificate. Sends some random bytes to the client.
Client verifies certificate, generates pre-master secret, encrypts the secret with the server's public key, and sends it to the server.
The server decrypts the pre-master secret and uses it to generate a shared master secret, which is then used to generate session keys. The client generates
the same master secret and session keys.
The client and server encrypt and exchange data using the session keys.
SSL/TLS: Common Security Weaknesses
• Use of outdated protocols: SSLv2.
• Use of weak ciphers: symmetric encryption (<128 bits), asymmetric encryption (<2048 bits).
• Expired / invalid certificates.
• Self-signed certificates.
• Renegotiation.
Web based:
• Login over HTTPS, everything else over HTTP (sslstrip
exploits this).
Attacks against SSL/TLS
BEAST (Browser Exploit Against SSL/TLS) – Developed in 2011.
Affects all versions of SSL/TLS except TLS 1.1 and 1.2. Allows an attacker to perform a man-in-the-middle attack.
CRIME (Compression Ratio Info-leak Made Easy) – Developed in 2012. Affects all version of SSL and TLS. Allows an attacker to decrypt web cookies.
Lucky Thirteen Attack – Developed in 2013. Affects all versions of
TLS. Allows an attacker to decrypt an intercepted message.
The Certificate Authority System
Web Browsers
Intermediate Certificate Authorities Root Certificate
Authorities
The Certificate Authority System
A certificate from an intermediate CA is trusted if there is a valid chain of trust all the way back to a root CA.
Any certificate authority can issue and sign a certificate for any identity / public key.
The system is only as secure as the weakest certificate
authority.
Attack Scenario
..
1
An attacker compromises the private (signing) key of a certificate authority.
..
2
The attacker can now sign a certificate for the attacker’s public key, with the identity “google.com”.
..
3
A man-in-the-middle attack is now possible, as long as the compromised CA is continued to be trusted all the way back to a root CA.
Note: This attack works even if a root CA (or any other CA) has
signed a certificate for google.com’s real public key!
Case Study: DigiNotar
DigiNotar was a Dutch root certificate authority, trusted by all major web browsers.
On July 10th, 2011 a hacker gained access to DigiNotar’s private signing key, and created a wildcard certificate for Google
(*.google.com) using the hacker’s public key.
The certificate was used to perform man-in-the-middle attacks on
web users in Iran before it was detected and revoked at the end of
August.
Case Study: DigiNotar (The Fallout)
At least 531 other fraudulent certificates were found to have been issued by hackers using DigiNotar’s compromised key.
DigiNotar was removed as a root CA from all major web browsers.
DigiNotar’s intermediate CAs and all certificates they had signed were considered invalid due to the broken chain of trust.
The company were declared bankrupt in September 2011.
The Ugly Truth
The ugly truth about SSL/TLS is that even with lots of clever cryptography being used, the current system we have for validating trust is based on often unknown third parties, with a single point of failure.
How can we make certificate verification more secure?
Convergence
Convergence (unfortunately, no relation to CNS) was designed by security researcher Moxie Marlinspike.
“An agile, distributed, and secure strategy for replacing Certificate Authorities”
Relies on a number of “network notaries” to verify certificates, rather than a single CA.
Resistant to most man-in-the-middle attacks.
Convergence
Cert A Server
Attacker
Client
Notary Notary
Cert B Cert B
Is this cert valid?
Is this cert valid?
No! No!
1 2
3 3
4 4
5 5
6 6