TLS and DTLS: A Tale of Two Protocols

Kenny Paterson

Information Security Group

Outline

•  TLS and the TLS Record Protocol

•  DTLS versus TLS
•  A selection of old attacks:
•  Predictable IVs and the BEAST
•  Padding Oracle Attacks
•  Breaking DTLS in OpenSSL
•  A new attack on TLS
•  A positive security result for TLS
•  Discussion

2
TLS Overview
•  SSL = Secure Sockets Layer.
–  Developed by Netscape
–  SSLv3 still widely supported
•  TLS = Transport Layer Security.
–  IETF-standardised 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).
•  SSL/TLS provides security ‘at TCP layer’.
–  Runs over TCP, using TCP to provide reliable, end-to-end
transport.
–  Widely deployed in Web browsers and servers to support
‘secure e-commerce’ over HTTP.

3
TLS Protocol Architecture

Change
Handshake Alert HTTP,
Cipher
Protocol Protocol other apps
Spec
Protocol

Record Protocol

TCP

4
TLS Record Protocol
•  TLS Record Protocol provides:
–  Data origin authentication and integrity using a MAC.
–  Confidentiality using a symmetric encryption
algorithm.
–  Anti-replay using sequence numbers protected by
the MAC.
•  Keys for the algorithms are supplied by the TLS
Handshake Protocol.
–  A complex protocol which we will henceforth ignore.

5
TLS Record Protocol: MAC-Encode-Encrypt

SQN + Payload
other data

MAC

Payload MAC tag Padding

Encrypt

Header Ciphertext

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

Encrypt CBC-AES128, CBC-AES256, CBC-3DES, RC4-128

6
TLS Record Processing
1.  Decrypt;
2.  Remove padding;
3.  Check MAC on header data, sequence number and
plaintext.

•  Each of these steps can fail.

•  Additional sanity checking may be needed.
•  Any failure results in an error message being sent and
immediate termination of the TLS connection.
•  Great care is needed in implementations to avoid attacks
based on analyzing error conditions.

7
Outline

•  TLS and the TLS Record Protocol

•  DTLS versus TLS
•  A selection of old attacks:
•  Predictable IVs and the BEAST
•  Padding Oracle Attacks
•  Breaking DTLS in OpenSSL
•  A new attack on TLS
•  A positive security result for TLS
•  Discussion

8
DTLS Overview
•  DTLS = Datagram Transport Layer Security.
–  A tweak to TLS.
–  Runs over UDP, using UDP to provide end-to-end transport.
–  Becoming more widely used, e.g. Cisco VPN products.
•  Some modifications to TLS are needed to handle unreliable
nature of UDP.
–  Allow for retransmission of handshake messages.
–  Allow out-of-order arrival of messages.
•  Use explicit sequence numbers rather than implicit sequence numbers and keep
a sliding window of received messages.
–  Tolerance of errors during decryption, but no error messages and
no session termination.
•  Versions:
–  DTLS 1.0, based on TLS 1.1, RFC 4347 (2006).
–  DTLS 1.2, based on TLS 1.2, RFC 6347 (2012).
9
DTLS Protocol Architecture

Change
Handshake Alert HTTP,
Cipher
Protocol Protocol other apps
Spec
Protocol

DTLS Record Protocol

UDP

10
CBC Mode in TLS and DTLS

Pi-1 Pi •  SSLv3 and TLS 1.0

use a chained IV in
CBC mode.
eK eK
–  IV for current message
is the last ciphertext
Ci-1 Ci block from the previous
message.

Ci-1 Ci •  Modified in TLS 1.1,

1.2 and DTLS.
dK dK –  TLS 1.2 now has explicit
IV and recommends IV
SHOULD be chosen at
Pi-1 Pi random for each
message.
11
Outline

•  TLS and the TLS Record Protocol

•  DTLS versus TLS
•  A selection of old attacks:
•  Predictable IVs and the BEAST
•  Padding Oracle Attacks
•  Breaking DTLS in OpenSSL
•  A new attack on TLS
•  A positive security result for TLS
•  Discussion

12
Attacking Predictable IVs

•  IV chaining in SSLv3 and TLS 1.0 leads to a

chosen-plaintext distinguishing attack against
TLS.
–  First observed by Rogaway as early as 1995.
–  Then applied to TLS by Dai and Moeller.
–  The adversary tries to learn which one of two possible
messages was encrypted.

•  For simplicity, we ignore MACs, padding and

sequence numbers and work with single block
messages.
13
Attacking Predictable IVs

•  Suppose attacker wishes to distinguish encryptions of

single blocks P0, P1.
•  Attacker asks for encryption of message P0 or P1.
•  Attacker receives ciphertext C = C1 for message Pb
where some known, previous block C0 was used as the
IV.

Pb

eK

C0 C1

14
Attacking Predictable IVs

•  C1 will be used as the IV for the next encrpytion.

•  Attacker now asks for the encryption of the single block
P0 ⊕ C0 ⊕ C1.
•  Attacker receives single block ciphertext C2.

Pb P0⊕C0⊕C1

eK eK

C0 C1 C2

15
Attacking Predictable IVs

Pb P0⊕C0⊕C1

eK eK

C0 C1 C2

•  If Pb = P0, then inputs to block cipher are the same in

both encryptions.
•  Hence, if Pb = P0, then C1 = C2.
•  Otherwise, if Pb = P1, then C1 is not equal to C2.
•  So looking at C1 and C2 gives us a test to distinguish
encryptions of P0 and P1.
16
Preventing Predictable IVs

•  To avoid this attack, TLS 1.1 and TLS 1.2 use

random IVs for each message.
•  One alternative is to always encrypt an empty
message before each real message, then send
both together.
•  Attacker cannot see IV before choosing his
plaintext.
•  So countermeasures are known and have been
standardised since 2006.
•  How widely are they implemented?

17
Preventing Predictable IVs

Safari TLS 1.0

Firefox TLS 1.0
Chrome TLS 1.1
Opera TLS 1.2
Microsoft IE8 TLS 1.2

(source: Wikipedia)

•  Support for TLS 1.1 and higher is patchy at best.

•  But the attack is only theoretical, right?
•  Attacker needs chosen plaintext capability and
is only able to distinguish encryptions.
18
Enter the BEAST

•  Sept. 2011: Duong and Rizzo demonstrated the

BEAST attack tool.
•  Builds on predictable IV attack to achieve
plaintext recovery against TLS 1.0.
•  Builds on low-entropy ideas of Bard.
•  Main new trick is “movable boundaries”.
•  Achieves chosen plaintext capability via a
Javascript download to client and an exploit to
bypass browser s same origin policy.
•  Demonstrated decryption of paypal session
cookies.
19
Reaction to the BEAST

•  Lots of press coverage and behind-the-scenes

work to put countermeasures in place.
•  OpenSSL apparently had empty the message
countermeasure in place since 2002.
•  But disabled because Microsoft could not
handle zero-length records!

•  Attacks tend to improve with age if left

unaddressed.
•  So when does an attack become severe enough
that the TLS community will take it seriously?
20
Outline

•  TLS and the TLS Record Protocol

•  DTLS versus TLS
•  A selection of old attacks:
•  Predictable IVs and the BEAST
•  Padding Oracle Attacks
•  Breaking DTLS in OpenSSL
•  A new attack on TLS
•  A positive security result for TLS
•  Discussion

21
TLS Record Protocol: Padding

SQN + Payload
other data

MAC

Payload MAC tag Padding

Encrypt

Header Ciphertext

22
TLS Record Protocol Padding

•  Padding in TLS 1.0 and up has a particular

format:
–  Always add at least 1 byte of padding.
–  If t bytes are needed, then add t copies of the byte
representation of t-1.
–  So possible padding patterns in TLS are:
00;
01 01;
02 02 02;
…

23
SSL/TLS Record Protocol Padding

•  Variable length padding is permitted in all

versions of TLS.
•  Up to 256 bytes of padding in total.
•  From TLS 1.0:
Lengths longer than necessary might be
desirable to frustrate attacks on a protocol based
on analysis of the lengths of exchanged
messages.

•  Security?
24
Handling Padding During Decryption

•  TLS 1.0 error alert:

decryption_failed: A TLSCiphertext decrypted in

an invalid way: either it wasn`t an even multiple
of the block length or its padding values, when
checked, weren t correct. This message is
always fatal.

•  Suggests padding format should be checked,

but without specifying exactly what checks
should be done.
25
Preventing Weak Padding Checks

•  Failure to check padding format leads to a simple

attack recovering the last byte of a block.
•  Hence, in TLS 1.1:

Each uint8 in the padding data vector MUST be

filled with the padding length value. The receiver
MUST check this padding….

26
Attack Based on Distinguishable Errors

•  Suppose now we have a full padding check, but that we

can distinguish a failure of the padding check from a
MAC failure.
•  So decryption checks that bytes at the end of the
plaintext have one of the following formats:
00;
01, 01;
02, 02, 02;
….
FF, FF,………..FF
and outputs an error if none of these formats is found.

27
Attack Based on Distinguishable Errors

•  Vaudenay [V02] proposed the concept of a padding

oracle.
Padding
Oracle
C
P=DecK(C)

Check
Valid/Invalid
padding of P

•  Vaudenay [V02] showed that, for CBC mode and for

certain padding schemes, a padding oracle can be used
to build a decryption oracle!
28
Padding Oracle Attack
•  Place target block Ct as last block of ciphertext.
•  Flipping bits in last-but-one ciphertext block may lead to
correct padding in last plaintext block.
•  Padding oracle will tell attacker when this occurs.
Flipping bits here

Ct-1 Ct

dK dK

Pt-1 Pt

May lead to valid padding format here 29

Padding Oracle Attack for TLS

•  For TLS padding, most likely “correct” output

arises from valid padding pattern of length 1,
namely “00”.
•  So:
–  Select a random block R.
–  Repeatedly modify last byte of R and submit
ciphertext ending with blocks R,Ct to padding
oracle….

30
Padding Oracle Attack for TLS

Modify here and submit to oracle

C
Rt-1 Ct
Revealing value of
dK(Ct) in last byte
here (R ⊕ 00 )
dK dK
Recovering true
plaintext byte here
Ct-1 ⊕ R ⊕ 00
Pt-1 Pt

Eventually produces
valid pad 00 here

31
Padding Oracle Attack for TLS

Modify here and submit to oracle

R Ct Revealing value of
dK(Ct) in second last
byte here (R ⊕ 01 )
dK dK

This byte now set to

Pt-1 Pt “01” by modifying R

Eventually produces
valid pattern 01 01 here

32
Padding Oracle Attack for TLS

•  An average of 128 trials are needed to extract

the last byte of each plaintext block.
•  Can extend to the entire block.
•  Can extend to entire ciphertext.
–  Can place any target block as last block of
ciphertext.

33
TLS Padding Oracles In Practice?

•  In TLS, an error message during decryption

can arise from either a failure of the padding
check or a MAC failure.
•  Vaudenay s padding oracle attack will produce
an error of one type or the other.
–  Padding failure indicates incorrect padding.
–  MAC failure indicates correct padding.
•  If these errors are distinguishable, then a
padding oracle attack should be possible.

34
TLS Padding Oracles In Practice?
Good news (for the attacker):
•  The error messages arising in TLS 1.0 are
different:
–  bad_record_mac
–  decryption_failed
Bad news:
•  But they are encrypted, so cannot be seen by
the attacker.
•  And an error of either type is fatal, leading to
the TLS session being terminated.

35
TLS Padding Oracles In Practice?
Canvel et al. [CHVV03] :
•  But a MAC failure error message is likely to
appear on the network later than a padding
failure error message.
–  Because MAC only checked if padding fails.
•  So timing the appearance of error messages
can give us the required padding oracle.
•  Because the errors are fatal, the attacker can
only learn one byte of plaintext, and then with
probability 1/256.

36
OpenSSL and Padding Oracles

Canvel et al. [CHVV03] also showed:

•  The attacker can still decrypt if a fixed plaintext
is repeated in a fixed location in many TLS
sessions.
•  The timing difference was detectable for the
then-current OpenSSL implementation of TLS.
–  Roughly 2ms difference.
•  The attack was applied to recover Outlook login
passwords in 3 hours.

37
Preventing Padding Oracle Attacks

•  OpenSSL was then patched to ensure uniform

reporting and timing of error messages, thus
preventing the padding oracle attack.
•  Advice to implementers in TLS1.1 (2006):
In order to defend against this attack, implementations
MUST ensure that record processing time is essentially
the same whether or not the padding is correct. In
general, the best way to do this is to compute the MAC
even if the padding is incorrect, and only then reject the
packet.

38
Outline

•  TLS and the TLS Record Protocol

•  DTLS versus TLS
•  A selection of old attacks:
•  Predictable IVs and the BEAST
•  Padding Oracle Attacks
•  Breaking DTLS in OpenSSL
•  A new attack on TLS
•  A positive security result for TLS
•  Discussion

39
Breaking DTLS in OpenSSL

•  [AP12]: Can we apply these ideas to DTLS?

•  Bad news: no error messages to time.

•  Good news: errors in DTLS are not fatal, so a
single-session attack might be possible.

•  But surely DTLS implementations would have

learned lessons from old TLS attacks?
–  DTLS 1.0 is based on the TLS 1.1 specification.
–  So we should not expect a timing-based side channel
to exist…
40
Breaking DTLS in OpenSSL

•  OpenSSL implementations of DTLS prior to

versions 0.9.8s/1.0.0f do not check the MAC if
the pad check fails.
•  Hence the timing difference observed in
[CHVV03] should still be present!

41
Breaking DTLS in OpenSSL

•  Bad news: no error messages to time.

–  Not a major hurdle:

Attack Heartbeat
packet packet

Heartbeat
response

–  Attack packet takes longer to process if padding is

good.
–  So measure timing difference between sending attack
packet and receiving heartbeat response.
–  This serves as a proxy for timing error messages
42
Breaking DTLS in OpenSSL

Good news: errors in DTLS are not fatal.

–  Actually very good news: allows amplification of timing
difference using packet trains.

Attack Attack Attack Heartbeat

packet packet packet packet

Heartbeat
response

–  With care, the timing difference arising from the attack

packets can be made cumulative!
–  Repeat over many trains and use statistical techniques
to detect timing difference.
43
Experimental Results
•  HMAC-SHA1 + CBC-AES, 10 packets per train, 1456
bytes per packet:

44
Experimental Results

•  Example for HMAC-SHA1 + CBC-AES

–  192 byte packets
–  2 packets per train
–  10 trains per byte value
•  Statistical processing:
–  Get timings for each set of 10 trains; remove outliers
–  Keep minimum time for each byte value tried.
–  Select as correct byte the one that maximizes the
resulting time.
•  Success probabilities:
–  Per byte: 0.996
–  Per block: 0.94 45
Observation

•  DTLS turns out to be substantially easier to

attack than TLS.
–  Because of ability to amplify timing differences using
packet trains.
–  This is a consequence of the choice of transport
protocol: UDP instead of TCP.
•  This distinction does not arise in current formal
security models for encryption.
–  But can easily be modelled.

46
Impact – OpenSSL
OpenSSL Security Advisory [04 Jan 2012]
======================================
DTLS Plaintext Recovery Attack (CVE-2011-4108)
==============================================
Nadhem Alfardan and Kenny Paterson have discovered an extension of the
Vaudenay padding oracle attack on CBC mode encryption which enables an
efficient plaintext recovery attack against the OpenSSL implementation of DTLS.
Their attack exploits timing differences arising during decryption processing. A
research paper describing this attack can be found at http://www.isg.rhul.ac.uk/
~kp/dtls.pdf

Thanks go to Nadhem Alfardan and Kenny Paterson of the Information Security

Group at Royal Holloway, University of London (www.isg.rhul.ac.uk) for
discovering this flaw and to Robin Seggelmann <[email protected]>
and Michael Tuexen <[email protected]> for preparing the fix.

Affected users should upgrade to OpenSSL 1.0.0f or 0.9.8s.

47
Impact – GnuTLS

GNUTLS-SA-2012-1 (CVE-2012-0390)

Timing attack (DTLS)

This vulnerability allows an attacker to perform partial

plaintext recovery using a timing attack in CBC-mode
encryption. The attack is applicable to Datagram TLS (DTLS).

Recommendation: Upgrade to GnuTLS 3.0.11.

48
Impact!

49
Outline

•  TLS and the TLS Record Protocol

•  DTLS versus TLS
•  A selection of old attacks:
•  Predictable IVs and the BEAST
•  Padding Oracle Attacks
•  Breaking DTLS in OpenSSL
•  A new attack on TLS
•  A positive security result for TLS
•  Discussion

50
Back to TLS

By now, a standards-compliant implementation of TLS

should have:

1)  Explicit, random IVs

– to prevent Dai-Rogaway-Moeller/BEAST attacks.
2) Uniform behaviour under padding and MAC failures
– to prevent padding oracle attacks.
3) Careful checking and removal of padding
– to prevent padding oracle attacks.
4) Variable length padding
– to disguise true plaintext lengths.

Is this enough to prevent all possible attacks?

51
Prior Security Analyses of MEE in TLS
Encode   In(security)   Restric2ons  
IND-­‐CPA  +    
[BN00]   Concatena2on   -­‐-­‐-­‐  
INT-­‐PTXT  
Tag  must  fill  exactly  
[K00]   Concatena2on   Secure  channel     one  block;  random  
IVs  
Tag  must  fill  exactly  
IND-­‐CPA  +    
Easy  extension  to  [K00]   Concatena2on   one  block;  random  
INT-­‐CTXT  
IVs  
[Rogaway/Dai/Moeller   Dis2nguishing  aUack/
Chained  IVs;  chosen  
1995-­‐2002];   Any   plaintext  recovery  
plaintexts  
[Duong-­‐Rizzo  2011]   aUack  
Dis2nct  error  
Plaintext  recovery  
[V02]/[CHVV03]   TLS  padding   messages/2ming  
aUack  
side  channel  
Minimal-­‐length  
Secure  channel  
padding  only;  
[MT10]   Any  func%on   (construc2ve  crypto  
uniform  errors;  
framework  )    
random  IVs   52
A New Attack on TLS

[PRS11]: Distinguishing attack for short messages,

truncated tags, variable length padding.

Practical
attacks
exist!!! eK eK

C0 C1 C2

53
A Positive Security Result for TLS

[PRS11]: Elsewhere, a security analysis proving

length-hiding authenticated-encryption (LHAE)
security

Secure in
the LHAE
model eK eK eK

C0 C1 C2 C3

54
A New Attack [PRS11]

K  
C C K  

C = Encrypt(K, X) X is either Yes or No

•  Adversary intercepts C, flips a few bits, and forwards it
on to recipient.
•  How recipient responds will indicate whether X = Yes
or No .
•  Ciphertext-only distinguishing attack.
•  The attack works when MAC size < block size.
55
MAC length t = 80, block length n = 128

Byte 13 is hex
No 134 1316
for ‘19’

eK eK

C0 C1 C2

Byte 12 is hex
C0 = C0 ⊕ 0012104 Yes 123 1216
for ‘18’

C = C0 C1 eK eK

C0 C1 C2
56
MAC length t = 80, block length n = 128

No 034 1316

eK eK Decrypts
fine to No
C0 C1 C2

C0 = C0 ⊕ 0012104 Yes 123 1216

C = C0 C1 eK eK

C0 C1 C2
57
MAC length t = 80, block length n = 128

No 034 1316

eK eK Decrypts
fine to No
C0 C1 C2

C0 = C0 ⊕ 0012104 Yes ?? 023 1216

MAC will
C = C0 C1 eK eK not verify,
decryption
C0 C1 C2 fails
58
Where Does the Attack apply?

For TLS 1.2:

Block length MAC length
n = 64 for 3DES t = 128 for HMAC-MD5
n = 128 for AES t = 160 for HMAC-SHA1
t = 256 for HMAC-SHA256

eK eK

C0 C1 C2

59
Where Does the Attack apply?

For TLS 1.2 with truncated MAC extension (RFC 6066):

Block length MAC length
n = 64 for 3DES t = 80 for Truncated HMAC-MD5
n = 128 for AES t = 80 for Truncated HMAC-SHA1
t = 80 for Truncated HMAC-SHA256

Attack applies!

eK eK

C0 C1 C2

60
Characteristics of the Attack

•  The attack requires messages of different lengths.

•  Hence NOT an attack in the classic IND-CCA/AE
sense.
•  But defeats the security design objective of TLS to
hide message lengths by variable length padding.
•  One message must be short:
|M| + t ≤ n - 8.
•  A variant attack using a single message breaks
INT-CTXT of MEE in TLS.
•  Hence MEE in TLS cannot be proven to provide
Authenticated Encryption, without some restrictions.

61
Consequences of the Attack

•  This does not yield a real attack against TLS.

–  But only because no short MAC algorithms are
currently supported in implementations.
•  The attack is only a distinguishing attack.
–  Does not seem to extend to plaintext recovery.
–  But ciphertext-only rather than chosen-plaintext.
•  c.f. requirements for BEAST attack.

62
Outline

•  TLS and the TLS Record Protocol

•  DTLS versus TLS
•  A selection of old attacks:
•  Predictable IVs and the BEAST
•  Padding Oracle Attacks
•  Breaking DTLS in OpenSSL
•  A new attack on TLS
•  A positive security result for TLS
•  Discussion

63
Authenticated Encryption (AE)
Security
C <- E( K, M1 ) M <- Dec( C ) C <- E( K, M0 )
Ret C Ret M Ret C
Ret !

M0  ,  M1   C   M0  ,  M1   C  

|M0|  =  |M1|   |M0|  =  |M1|  

b   b  

Authenticated-Encryption security does not protect against

adversary who can select messages of different lengths.

64
Length-hiding Authenticated
Encryption (LHAE) Security
C1 <- E( K, L, M1 ) M <- Dec( C ) C1 <- E( K, L, M1 )
C0 <- E( K, L, M0 ) Ret M C0 <- E( K, L, M0 ) Ret !
If C0 = !or C1 = ! If C0 = !or C1 = !
Ret ! Ret !
Ret C1 Ret C0

C   C  
L,  M0,  M1   L,  M0,  M1  

|M0|  =  |M1|   |M0|  =  |M1|  

b   b  

LHAE security protects against learning partial information

about messages of (some) different lengths and forging
ciphertexts.
LHAE     LH-­‐IND-­‐CPA  +  INT-­‐CTXT   AE    
65
Towards Showing LHAE Security

eK eK eK

C0 C1 C2 C3

LHAE LH-IND-CPA + INT-CTXT

Showing LH-IND-CPA is easy using IND-CPA of CBC.

INT-PTXT is straightforward from results of [BN00].

But we need INT-CTXT, and INT-PTXT does not imply it.
66
Collision-Resistant Decryption Security
This is exactly the gap between INT-PTXT and INT-CTXT
INT-CTXT INT-PTXT + CRD

Recall in our attack, adversary creates a new ciphertext that

decrypts to a previously encrypted message.

No 134 1316

eK eK

C0 C1 C2

67
Collision-Resistant Decryption Security
This is exactly the gap between INT-PTXT and INT-CTXT
INT-CTXT INT-PTXT + CRD

Recall in our attack, adversary creates a new ciphertext that

decrypts to a previously encrypted message.

No 034 1316

eK eK

C0 C1 C2

Achieving CRD security shows that no such attacks exist.

68
Showing CRD Security
Theorem ([PRS11], informal)
Suppose E is a block cipher with block size n that is sprp-secure.
Suppose MAC has tag size t and is prf-secure.
Suppose that for all messages M queried by the adversary:
|M| + t ≥ n.

Then MEE with CBC mode encryption, random IVs,

TLS padding, and uniform errors is CRD-secure, and hence LHAE secure.

eK eK eK

C0 C1 C2 C3 69
Updated Security Analyses of MEE in TLS
Encode   In(security)   Restric2ons  
Tag  must  fill  exactly  
IND-­‐CPA  +    
Easy  extension  to  [K00]   Concatena2on   one  block;  random  
INT-­‐CTXT  
IVs  
[Rogaway/Dai/Moeller   Dis2nguishing  aUack/
Chained  IVs;  chosen  
2002];   Any   plaintext  recovery  
plaintexts  
[Duong-­‐Rizzo  2011]   aUack  
Dis2nct  error  
Plaintext  recovery  
[V02]/[CHVV03]   TLS  padding   messages/2ming  
aUack  
side  channel  
Minimal-­‐length  
Secure  channel  
padding  only;  
[MT10]   Any  func%on   (construc2ve  crypto  
uniform  errors;  
framework  )    
random  IVs  

[PRS11]   TLS  padding   Dis2nguishing  aUack   |M|  +  t    ≤    n  –  8  

Length-­‐hiding   |M|  +  t    ≥    n;  

[PRS11]   TLS  padding   authen2cated   uniform  errors;  
encryp2on   random  IVs   70
Tag size matters!

Practical
attacks
exist eK eK

C0 C1 C2

Secure in
our LHAE
model eK eK eK

C0 C1 C2 C3
71
Outline

•  TLS and the TLS Record Protocol

•  DTLS versus TLS
•  A selection of old attacks:
•  Predictable IVs and the BEAST
•  Padding Oracle Attacks
•  Breaking DTLS in OpenSSL
•  A new attack on TLS
•  A positive security result for TLS
•  Discussion

72
TLS and Complexity
•  TLS is now part of the “critical infrastructure” of
the Internet, but we still don’t fully understand its
security.
•  TLS continues to evolve and get more complex.
–  DTLS.
–  TLS extensions.
–  New ciphersuites; PSK, GCM, ECC,…
–  TLS Handshake Protocol options.
–  Renegotiation/resumption.
–  Ad hoc design proposals are rife on TLS mailing list.
•  But complexity is the enemy of security.
73
Lessons Learned
•  MAC-Encode-Encrypt is hard to implement securely and
hard to analyse.
–  Maybe there are still some surprises in store!?
•  Ignore theoretical attacks at your peril!
–  Rogaway’s 1995 observation was largely ignored until a “real”
attack was presented in 2011.
–  Attacks tend to improve with age.
•  Desire to support legacy and backwards compatibility
hampers the adoption of better cryptographic
alternatives.
•  TLS is late 20th century technology.
–  Tried and trusted?
–  Or obsolete, and a moving target as a consequence?
74
Literature

•  [AP12]: AlFardan, Paterson, NDSS 2012.

•  [BN00]: Bellare, Namprempre, Asiacrypt 2000.
•  [CHVV03]: Canvel, Hiltgen, Vaudenay,
Vuagnoux, Crypto 2003.
•  [K01]: Krawczyk, Crypto 2001.
•  [MT10]: Maurer, Tackmann, ACM-CCS 2010.
•  [PRS11]: Paterson, Ristenpart, Shrimpton,
Asiacrypt 2011.
•  [V02]: Vaudenay, Eurocrypt 2002.

75