CRYPTOANALYSIS

Lecture 9: TLS Security and Protocol Attacks

PROF. MAHMOUD MOHAMED EL-KHOULY

Outline

INTRODUCTION TO SSL AND TLS

CRIME AND BEAST ATTACK
LUCKY 13 AND RC4
TLS 1.3
 ? WHERE DO WE STAND?
SSL (Secure Sockets Layer)
Developed by Netscape in the mid 1990s
SSLv2 now deprecated (SSLv3 still widely supported)
TLS (Transport Layer Security)
IETF-standardized version of SSL
TLS 1.0 = SSLv3 with minor tweaks, RFC 2246 (1999)
TLS 1.1 = TLS 1.0 + tweaks, RFC 4346 (2006)
TLS 1.2 = TLS 1.1 + more tweaks, RFC 5246 (2008)
TLS 1.3 = TLS 1.2 + major tweaks, RFC 8446 (2018)
 WHY YOU SHOULD CARE
Originally for secure eCommerce, now used much more widely
Retail customer access to online banking facilities
User access (Google, Facebook, ...)
Mobile banking applications
Payment infrastructures

TLS is the de facto secure protocol of choice

Used by hundreds of millions of people and devices every day
Serious attacks could be catastrophic!
 WHY YOU SHOULD CARE CONT.
TLS has been in the news...

BEAST, CRIME, Lucky 13, RC4 attacks

Renegotiation attack (2009), triple Handshake attack (2014)
Poor quality of implementations (e.g., Apple “goto fail”)

Why all these attacks?

Higher profile, so more attention

More attention, so more researcher interest
TLS Protocol Architecture

Change
Handshake Alert HTTP, other
Cipher Spec
Protocol Protocol apps
(TLS <= 1.2)

Record Protocol

TCP
SIMPLIFIED VIEW OF TLS

Used by client and server to

1. Negotiate cipher suite
2. Authenticate
3. Establish keys used in the Record Protocol

Client Server
Handshake Protocol

Record Protocol

Provides confidentiality and authenticity of application

layer data using keys from Handshake Protocol
 ADOPTION OF TLS 1.2
28% of Alexa top 200k servers support TLS 1.1 or higher (2014)

TLS 1.2 support in browsers:

I ) Firefox: since release 28
2) Chrome: since release 30
3) IE: since IE11
4 ) Safari: since iOS 5 and OS X 10.9
Attacks have accelerated adoption of TLS 1.2
Nearly 90% of connections use AE (2017)
TLS – A HISTORY OF ATTACKS
Termination,
POODLE Cookie Cutter Goldberg &
ZombiePOODLE Wagner
GoldenDOODLE Bleichenbacher Debian
Netscape
OpenSSL
Bleichenbacher, PRNG
BEAST entropy bug
attack
SSL 2.0
Cross-protocol downgrade,
DH/ECDH attack FREAK, Logjam Heartbleed
Crypto Ciphersuite Advanced Applications
Libraries
primitives details functionality

• RSA, DSA, • Data structures • Alerts & errors • OpenSSL • Web browsers:

goto fail;
ECDSA • Key derivation • Certification / • LibreSSL, Chrome, Firefox,

BERserk
• Diffie–Hellman, • Encryption revocation BoringSSL IE/Edge, Safari
• Negotiation • NSS • Web servers:
Lucky13

ECDH modes, IVs

• HMAC • Padding • Renegotiation • GnuTLS Apache, IIS,
• MD5, SHA1, • Session • SChannel nginx, node, …

Frankencert
Triple
Triple handshake
handshake • Application

CA breaches
SHA-2 resumption • Java JSSE
attack
• DES, 3DES, • Key reuse • Everest / miTLS SDKs

s
RC4, AES • Compression • s2n • Certificates
• Export grade • State machine • Protocols
• HTTP, IMAP, ..
Sweet32

SMACK SSL stripping

RC4 biases,
rc4nomore, CCS Lucky Virtual host
Bar Mitzvah injection microseconds confusion
(Illustration by Douglas Stebila)
 BEAST ATTACK (BROWSER EXTENSIBLE AUTHENTICATION SECURITY TOKEN ATTACK)

Is a type of security vulnerability where an attacker can intercept and decrypt

sensitive data transmitted between a client and a server.

It typically targets SSL/TLS encrypted data that uses a block cipher mode.

How does a beast attack work?

A beast attack works by exploiting a vulnerability in the SSL/TLS protocol. The
attacker tries to guess the encrypted message by sending several messages
with known plaintexts and analyzing the corresponding ciphertexts.

Once the attacker can guess the message, they can intercept and decrypt it,
potentially gaining access to sensitive information like passwords or credit
card details.
 BEAST – LESSONS LEARNED

Theoretical vulnerability (1995) became practical attack (2011)

So, attacks really do get better with time!

Sometimes, we should listen to theoreticians

Result: TLS 1.1 and 1.2 use random Ivs (initialization vectors)
 CRIME ATTACK
The CRIME attack is based on a weak spot in a special feature in TLS 1.0. Once
they had the cookie, Rizzo and Duong could return to whatever site the user was
visiting and log in using her credentials. HTTPS should prevent this type of
session hijacking because it encrypts session cookies while in transit or when
stored in the browser. But the new attack, devised by security researchers
Juliano Rizzo and Thai Duong, is able to decrypt them.

The CRIME attack code, known as an agent, needs to be loaded inside the
victim's browser. This can be done either by tricking the victim into visiting a
rogue website or, if the attacker has control over the victim's network, by
injecting the attack code into an existing HTTP connection.
CRIME – LESSONS LEARNED

Theoretical vulnerability (2004) became practical attack (2012)

Tools developed for BEAST were reused for CRIME

... maybe they can be used elsewhere too?
 Lucky 13 Attack
Lucky Thirteen uses a padding technology known as a TLS cryptographic oracle, which
performs cryptography and ensures data integrity. It uses a MEE routine that runs data via a
MAC algorithm and then encodes and codes data in 16-byte chunks. The routine adds data
“padding” to the ciphertext so that the results can be clearly aligned within 8 to 16 bytes. When
TLS decrypts the ciphertext, the padding is later removed.
The attacks begin by capturing the chip text on the Internet. Using a long-discovered weakness
in TLS CBC, or chip block chaining, mode, attackers substitute the last few blocks with the
blocks selected, and observe how long the server needs to respond. It takes less time to
process TLS messages containing the correct padding.
A mechanism in TLS causes the transaction to fail each time a TLS message is received
containing manipulated data, which requires attackers to repeatedly send malformed
messages in a new session after each previous failure. The scientists could finally properly
guess the contents of the ciphertext by sending large numbers of TLS messages and by
statistically sampling server response time for each. It took the scientists as little 2 23 sessions
to extract the entire contents of a TLS-encrypted authentication cookie. They were able to
improve their results when they knew details of a the ciphertext they were trying to decrypt.
Cookies formatted in base 64 encoding, for example, could be extracted in 219 TLS sessions.
The researchers required 213 sessions when a byte of plaintext in one of the last two positions
in a block was already known.
 LUCKY 13 ATTACK
MAC-Encode-Encrypt approach in TLS:
SQN || HDR Payload

MAC

Payload MAC tag Padding

Encrypt

HDR Ciphertext

MAC HMAC-MD5, HMAC-SHA1, HMAC-SHA256

Encrypt CBC-AES128, CBC-AES256, CBC-3DES, RC4-128
Padding “00” or “01 01” or “02 02 02” or … . or “FF FF….FF”
 TLS AND PADDING ORACLES
Specifics of TLS padding format can be exploited to mount a plaintext
recovery attack
No chosen-plaintext requirement!
Attack depends on being able to distinguish good from bad padding

In practice, this is done via a timing side channel

The MAC is only checked if the padding is good
Distinguish cases by producing bad paddings and timing TLS error
messages
TLS AND PADDING ORACLES – PLAINTEXT
RECOVERY Target
XOR 1-byte Δ here ciphertext
and submit for decryption block from
stream

IV R1 R2 Ct-1 Ct

dK dK dK dK

Pt

Produces valid
patterns “00”,
OR bad pad.
 TLS AND PADDING ORACLES
Problem: Each bad trial causes an error and terminates the TLS session

Use multiple TLS sessions

Repeat fixed plaintext in fixed location
Padding oracle attack worked for OpenSSL
Roughly 2 ms difference for long messages
Found TLS-protected Outlook passwords in about 3 hours
 LUCKY 13 – IMPACT
Opera patched (30/01/2013)
OpenSSL patched in versions 1.0.1d, 1.0.0k, and 0.9.8y (05/02/2013)

BounceCastle patched (10/02/2013)

NSS (Firefox, Chrome) patched (15/02/2013)
Oracle patched JavaSE (19/02/2013)
Microsoft:
“The issue has been adequately addressed in previous modifications to our
TLS and DTLS implementations.”
LUCKY 13 – OTHER COUNTERMEASURES?
Introduce random delays during decryption (surprisingly ineffective)
Redesign TLS

Pad-MAC-Encrypt or Pad-Encrypt-MAC?
Switch to TLS 1.2+
Support for AES-GCM and AES-CCM
Was not widely supported by browsers or servers at that time
Switch to RC4
Recommended by many people (again)
Is it a good idea?
Attacks on RC4
TLS RECORD PROTOCOL: RC4-128 (STREAM CIPHER)

SQN || HDR Payload

MAC

Payload MAC tag

Encrypt

HDR Ciphertext

MAC HMAC-MD5, HMAC-SHA1, HMAC-SHA256

Encrypt CBC-AES128, CBC-AES256, CBC-3DES, RC4-128
USE OF RC4 IN TLS

• BEAST and Lucky 13 attacks on CBC-based cipher suites in TLS

• Just switch to RC4

• Fast on software (when no AES-NI available)

• Use of RC4 in the wild: ≈ 50% of TLS connections protected by RC4 (2013) Problem:
RC4 is known to have statistical weaknesses
 WAIT,WHAT’S GOING ON HERE?

Why were people still using RC4 in half of all TLS connections when we already
knew it was a weak stream cipher?

“The biases are only in the first bytes and they don’t encrypt anything interesting in TLS.”

“The biases are not exploitable in any meaningful scenario.”

“RC4 is fast.”

“I’m worried about BEAST on CBC mode. Experts say ’use RC4’.”

“Google uses it, so it must be fine for my site.”

 SUMMARY OF RC4 IN TLS
Plaintext recovery attacks against RC4 in TLS are feasible although not truly
practical
228 - 232 sessions for reliable recovery of initial bytes
233 - 234 encryptions for reliable recovery of 16 bytes anywhere in the
plaintext
Attacks illustrate that RC4 in TLS provides a security level far below the
strength suggested by the 128-bit key
And last but not least: Attacks become better with time
RC4 removed in TLS 1.3
Current and Future Developments in TLS
 CURRENT STATUS
CBC mode cipher suites can be patched against BEAST and Lucky 13
However, reputation damaged by long series of attacks
Performance also an issue (AES-CBC + HMAC quite slow)
RC4 pretty much dead
Switch to AE in TLS 1.3
 CURRENT STATUS CONT.
AES-based cipher suites are generally slow without AES-NI

AES-GCM is tricky to implement securely

... but it is relatively fast

Especially with AES-NI and PCLMULQDQ

Only ≈ 1 - 2 cycles per byte, depending on processor
Roughly twice as fast as AES-CBC + HMAC-SHA

The new 2010 Intel® Core processor family (code name Westmere) includes a set of new instructions, Intel® Advanced
Encryption Standard (AES) New Instructions (AES-NI). The instructions were designed to implement some of the complex and
performance intensive steps of the AES algorithm using hardware and thus accelerating the execution of the AES algorithms.
AES-NI can be used to accelerate the performance of an implementation of AES by 3 to 10x over a completely software
implementation.
 CURRENT STATUS CONT.
New AE algorithms
Important for environments where AES is not available in hardware

Salsa20 and ChaCha stream ciphers added to TLS 1.3

Poly1305 MAC added to TLS 1.3

www.cryptopp.com/wiki/Salsa20
www.poly1305.com
 CURRENT DEVELOPMENTS
TLS 1.3 was released in August 2018

Simplified key exchange and authentication methods in handshake

protocol
Server name/identity hiding for improved privacy
Reduced latency
Reform of symmetric algorithms

Widely supported now

 TLS 1.3 – CHANGES
Removed features

SHA-1, MD5
DES, 3DES, RC4, AES-CBC
Compression (CRIME)

Handshake improvements

All messages after ServerHello encrypted

1-RTT handshake, 0-RTT for pre-shared keys
Simplified state machine
SUMMARY
A lot of attacks on TLS 1.2
Both theoretical and practical
Problems due to CBC mode (padding oracle)
RC4 also vulnerable
TLS 1.3 to remove many of the weak components of TLS 1.2
Different approach for TLS 1.3

Huge interest by scientific community

Security analysis during design phase
Feedback by researchers integrated in final TLS 1.3 specification