SSL/TLS: The Ugly Truth
Examining the flaws in SSL/TLS protocols, and the use of
certificate authorities.
Adrian Hayter
CNS Hut 3 Team
[email protected]
Contents
• Introduction to SSL/TLS
• Cryptography Crash Course
• Certificates
• Weaknesses in SSL/TLS
• The Certificate Authority System
• Solutions & Recommendations
• Questions
Adrian Hayter
Page: 2/26
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.
Adrian Hayter
Page: 3/26
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.
Adrian Hayter
Page: 3/26
Cryptography Crash Course
If you already know about cryptography, feel free to ignore the
next few slides!
Adrian Hayter
Page: 4/26
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.
Adrian Hayter
Page: 5/26
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?
Adrian Hayter
Page: 6/26
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?
Adrian Hayter
Page: 6/26
Cryptography Crash Course: Asymmetric Cryptography
Alice
Bob
Alice and Bob generate their own private and public key pairs.
Alice and Bob share their public keys with each other.
Alice encrypts a message with Bob's public key and sends it to Bob. Bob
decrypts the message with his private key.
Bob encrypts a message with Alice's public key and sends it to Alice. Alice
decrypts the message with her private key.
Adrian Hayter
Page: 7/26
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.
Adrian Hayter
Page: 8/26
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.
Adrian Hayter
Page: 8/26
A Solution
We can combine symmetric and asymmetric cryptography.
Adrian Hayter
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.
Page: 9/26
A Solution
We can combine symmetric and asymmetric cryptography.
Adrian Hayter
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.
Page: 9/26
A Solution
We can combine symmetric and asymmetric cryptography.
Adrian Hayter
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.
Page: 9/26
A Solution
We can combine symmetric and asymmetric cryptography.
Adrian Hayter
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.
Page: 9/26
A Solution
We can combine symmetric and asymmetric cryptography.
Adrian Hayter
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.
Page: 9/26
A Solution
We can combine symmetric and asymmetric cryptography.
Adrian Hayter
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.
Page: 9/26
A problem with our solution!
Alice and Bob don’t ever verify that they are actually talking to
each other!
Adrian Hayter
Page: 10/26
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
Mallory
Bob
"Hey Bob, it's Alice. Can I have your
public key?"
"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?
Adrian Hayter
Page: 10/26
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...
Adrian Hayter
Page: 11/26
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
Adrian Hayter
Page: 12/26
(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.
Adrian Hayter
Page: 13/26
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).
Adrian Hayter
Page: 14/26
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.
Adrian Hayter
Page: 15/26
The Certificate Authority System
Web Browsers
Root Certificate
Authorities
Intermediate
Certificate
Authorities
Adrian Hayter
Page: 16/26
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.
Adrian Hayter
Page: 17/26
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!
Adrian Hayter
Page: 18/26
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.
Adrian Hayter
Page: 19/26
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.
Adrian Hayter
Page: 20/26
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?
Adrian Hayter
Page: 21/26
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.
Adrian Hayter
Page: 22/26
Convergence
Server
Cert B
5
5
Cert B
Attacker
4
Notary
Adrian Hayter
Cert A
2
1
Is this cert
valid?
3
Client
4
Is this cert
valid?
3
6
6
No!
No!
Notary
Page: 23/26
Convergence
Advantages
• No single point of failure.
• Servers can self-sign certificates and still be trusted.
• Client has more control over the trust decision.
• Notaries can keep a cache of certificates (eliminating steps 4
and 5).
Disadvantages
• Extra network traffic is required to verify a certificate.
• Still susceptible to some man-in-the-middle attacks.
• (Currently) not implemented well enough for wide adoption.
Adrian Hayter
Page: 24/26
Convergence
Advantages
• No single point of failure.
• Servers can self-sign certificates and still be trusted.
• Client has more control over the trust decision.
• Notaries can keep a cache of certificates (eliminating steps 4
and 5).
Disadvantages
• Extra network traffic is required to verify a certificate.
• Still susceptible to some man-in-the-middle attacks.
• (Currently) not implemented well enough for wide adoption.
Adrian Hayter
Page: 24/26
Recommendations
• Use TLS 1.0 (it’s supported in all major web browsers).
• Use RC4 cipher suites (for now).
• Disable compression.
• Disable renegotiation.
• Play around with Convergence!
Adrian Hayter
Page: 25/26
Recommendations
• Use TLS 1.0 (it’s supported in all major web browsers).
• Use RC4 cipher suites (for now).
• Disable compression.
• Disable renegotiation.
• Play around with Convergence!
Adrian Hayter
Page: 25/26
Questions?
Ask away, or email:
[email protected]
Adrian Hayter
Page: 26/26