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.
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.
Adrian Hayter Page: 9/26 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.
Adrian Hayter Page: 9/26 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.
Adrian Hayter Page: 9/26 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.
Adrian Hayter Page: 9/26 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.
Adrian Hayter Page: 9/26 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.
Adrian Hayter Page: 9/26 “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?
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
5 5 Cert B Cert B
Attacker
Cert A 4 1 2 4
Is this cert Is this cert valid? valid? Notary 3 Client 3 Notary
6 6 No! No!
Adrian Hayter 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:
Adrian Hayter Page: 26/26