TLS Security EPL682 Neophytos Christou What is TLS? - - PowerPoint PPT Presentation

TLS Security EPL682 Neophytos Christou

What is TLS? - Cryptographic protocols that provide secure communication on the internet - Consists of two phases: - TLS Handshake protocol: agree on the cipher suite that will be used to encrypt messages - TLS Record protocol: exchange encrypted messages using the agreed symmetric encryption cipher and session key - Many open source implementations of TLS (OpenSSL, NSS, GnuTLS and many more)

Digital certificates - Used to prove ownership of a public key - Contains information about the key, the owner of the key and many more and is signed by a trusted Certificate Authority - The valid format that a digital certificate can have is defined by the X.509 standard using the syntax defined by the ASN.1 standard - Currently at version 3 of X.509 - Validating a certificate is a complex procedure A TLS certificate illustrated

Chain of trust - Root certificates: Client trusts some certificate authorities (root CAs), whose certificates are stored on the client’s machine - Leaf certificates: the certificate that the server we want to authenticate presents - When presented with a leaf certificate, the client checks the certificate of the CA that signed the certificate - If that CA is not a root CA, this chain continues until the signing CA is a root CA

Certificate constraints - KeyUsage (keyCertSign for intermediate CA, keyEncipherment for leaf certificates with public keys that will be used for session key encryption etc.) - Validity dates - Basic constraints extension: CA bit in root or intermediate CAs, path length: number of intermediate CAs between the leaf and the current certificate - Critical extensions: client must reject the certificate if it doesn’t recognize a critical extension - Name constraints - ExtendedKeyUsage - Hostname verification: check if DNS name of server matches the one on the certificate

Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations Chad Brubaker, Suman Jana, Baishakhi Ray, Sarfraz Khurshid, Vitaly Shmatikov

Problem: testing certificate correctness - Creating correct test inputs to check if the implementations of cryptographic libraries correctly validate certificates - Structure of certificate is very complex - Hard to efficiently auto-generate parsable certificates with random fuzzing - Even if we create correct certificates, how will we test all implementations - Check if the various TLS implementations handle bad certificates correctly - Reject non-valid certificates - Give correct feedback to the user

Solution: Frankencerts - Scanned the internet and collected ~250,000 certificates - Created 8 million frankencerts by taking random parts from the collected certificate and combining them into a new certificate that will be used for testing - The created certificates can be parsed but may not follow constraints defined by X.509 standard - TLS implementations should correctly identify and reject certificates that don’t follow the standard - Use differential testing to test all implementations

- Frankecerts may be invalid because there is no check for X.509 restrictions when creating the certificate, even though they follow the ASN.1 grammar - Frankecerts trigger unusual paths in code that would not be normally triggered by common certificates, because of unusual combinations of certificate fields. - All implementations should handle all certificates the same way - Most TLS implementations only used a small number of pre-generated certificates for testing, which were unlikely to discover any errors in the implementation - Each generated certificate was tested against all TLS implementations - Discovered a total of 208 discrepancies between the tested implementations

Results: constraint checking - Intermediate version 1/2 certificates not rejected: vulnerable to MitM attacks - No check for pathLength constraints: an intermediate CA could issue certificates for other intermediate CAs even though it is not allowed to - Incorrect check for name constraints and time - Incorrect check for key usage: did not reject CA certificates without keyCertSign, server certificates not authorized for use in TLS/server authentication - Incorrect check for critical extensions, wrong extension values, etc

Results: error reporting - Some errors are not as serious as others (e.g. a user could choose to ignore a recently expired certificate error) - Most libraries only reported one error even if there were multiple errors: more serious errors were sometimes hidden by a lower-risk error - Some libraries accepted/did not warn about weak keys (e.g. 512-bit RSA) or weak hash functions (e.g. MD5)

Questions?

TLS Record protocol - Uses symmetric encryption with the key that was agreed during the Handshake phase to encrypt exchanged messages + HMAC for authentication - One of the encryption options is the RC4 stream algorithm - RC4 used to be very widely used in TLS because of its speed - Stream cipher: a keystream is created using the key, message XORed with keystream

The RC4 stream cipher

On the Security of RC4 in TLS Nadhem AlFardan, Daniel J. Bernstein, Kenneth G. Paterson, Bertram Poettering, and Jacob C.N. Schuldt

Single-byte biases in the RC4 keystream - Each byte at each position of the keystream should have a probability of 1/256 to appear, but this is not the case for the first 256 bytes - Some previously discovered biases: - Probability that the second byte of the keystream is 0x00 is 1/128 - All bytes are biased towards 0x00 (around 1/ 2^16) - If the key is L bytes, then the Lth byte is biased towards 256-L - Other discovered biases: - Byte 16 is biased towards 0xF0 and 0x10 - Byte 32 is biased towards 0xE0 and 0x20 - Byte 50 is biased towards 0x32 - Each byte R is biased towards value R

Multi-byte biases in the RC4 keystream - Multi-byte biases appear in regular intervals in the keystream and are depended on counter i used in the RC4 algorithm

Single-byte bias attack Collected statistics from 2 44 keystreams to estimate the biases - on all byte positions. - Generate a large number of ciphertexts over the same plaintext, using a newly generated key each time. - For each distribution of values at each position for the ciphertext, calculate the distribution on the RC4 keystream required to get the observed values. - Select the plaintext byte with the closest match. - Repeat the same process for all 256 first bytes of the plaintext.

Example: decrypt byte at position 16

Double-byte bias attack - Unlike the single-byte bias attack, we don’t need multiple different keystreams. Will work with a single key by encrypting a plaintext repeatedly (concatenated with itself P = P 1 || P 2 || … || P n ). - Starting with a known first byte of plaintext, calculate the most likely byte at the next position based on the multi-byte biases. - Repeat this process for each consecutive byte. - Can recover bytes at any position in the plaintext.

Simulation results summary - Single-byte bias attack: First 46 bytes recovered with 50% success rate with 2 26 - sessions Almost 100% recovery with 2 32 sessions (first 256 bytes) - - Half as much for hex-encoded strings - Double-byte bias attack - attempted to recover 16 bytes at a fixed position (e.g a cookie): 50% success rate on average with 6*20 30 plaintext copies - 99% success with 11*20 30 copies - 100% recovery with 13*20 30 copies - - 98% success with 11*20 30 for base64 encoded strings 98% success with 8*20 30 for hex encoded strings -

Realistic attack - Single-byte bias - Run a client and a server using OpenSSL for TLS - Modified source code to force session resumption after each sent package, thus renewing RC4 key each time - Can generate 2 21 ciphertexts per hour - A real attacker can inject a bad TLS packet or reset the TCP connection to cause this effect - Realistically, it would be extremely slow to generate the required number of ciphertexts

Realistic attack - Double-byte bias - Attacker does not need to force session resumption, since the plaintext is encrypted many times with the same keystream - Set up a legitimate and a malicious server - Client visits both legitimate and malicious site, malicious Javascript directs HTTP requests from the client to the legitimate server over the established TLS connection - Client’s browser attaches its cookie on each request - Can generate 6 million requests per hour Would need around 2000 hours to generate 13*2 30 encryptions - to fully recover the cookie

RC4 is not used anymore in TLS

Thank you!