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
• ne 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 244 keystreams to estimate the biases
• n 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 = P1 || P2 || … || Pn ).

• 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 226

sessions

• Almost 100% recovery with 232 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*2030 plaintext copies
• 99% success with 11*2030 copies
• 100% recovery with 13*2030 copies
• 98% success with 11*2030 for base64 encoded strings
• 98% success with 8*2030 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 221 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*230 encryptions

to fully recover the cookie

RC4 is not used anymore in TLS

Thank you!