It’s Time to Replace SSL/TLS
Karen P. Lewison, MD – CEO
kplewison@pomcor.com
Francisco Corella, PhD – CTO
fcorella@pomcor.com
5/29/2014 -- Updated 5/31 to
add link to white paper
1
Outline
• Brief history and usage of SSL, TLS and DTLS
• The core of the protocols
• Shortcomings
– Usability shortcomings:
• Latency and bandwidth consumption of handshake
– Privacy shortcomings:
• Related to client authentication
– Security shortcomings
• Long history of vulnerabilities, some not yet addressed
• It’s time for a replacement
• Ingredients for a replacement
• The formal verification challenge
5/29/2014 -- Updated 5/31 to
add link to white paper
2
Brief history of SSL, TLS and DTLS
• The Web (1990, Tim Berners Lee at CERN)
– Document sharing
– HTTP over TCP, no security
• SSL (Secure Sockets Layer, 1995, Netscape)
– https: HTTP over SSL over TCP
– Encryption of credit card numbers => ecommerce
– Encryption of passwords
• TLS (SSL taken over by IETF, 1999)
– TLS 1.0: January 1999
– TLS 1.1: April 2006
– TLS 1.2: August 2008
• DTLS (for use over UDP, 2006)
5/29/2014 -- Updated 5/31 to
add link to white paper
3
Usage
• TLS is the most widely used network security protocol
• Primary use: web security (https)
• Also used to protect email
– Server-to-client download: POP3, IMAP
– Server-to-server transmission SMTP
– NOT used for end-to-end encryption of email (S/MIME or PGP)
• Used to provide underlying security for many other IETF
protocols: ACAP, COPS, FTP, NET-CONF, NNTP, SDP, SNMP
• Often used instead of IPsec to create VPNs
• DTLS used to protect the Session Initiation Protocol (SIP) for
voice and video calls (VoIP)
5/29/2014 -- Updated 5/31 to
add link to white paper
4
The protocol: two phases
• Handshake:
– Server authentication, optional but almost always used
– Establishment of shared keys for traffic protection
– Optional client authentication, rarely used except for
• Authentication of federal employees with PIV/CAC cards
• Traffic protection:
– Traffic in each direction (client to server, server to client) is
fragmented into records
– Each record is authenticated by a MAC, and encrypted
– 4 symmetric keys: 1 for authentication and 1 for
encryption, in each direction
5/29/2014 -- Updated 5/31 to
add link to white paper
5
Client
Handshake using key transport
Server
Client random
Server random, RSA public key certificate and certificate chain
Generate premaster secret,
derive master secret and
traffic protection keys
Premaster secret encrypted under server RSA public key,
ChangeCipherSpec, client “Finished”
Decrypt premaster secret,
derive master secret and
traffic protection keys
ChangeCipherSpec, server “Finished”
Application data
5/29/2014 -- Updated 5/31 to
add link to white paper
6
Handshake with client authentication
Client
Server
Client random
Server random, RSA public key certificate and chain,
certificate request
Generate pms, ms, keys
Client certificate and chain for digital signature public key,
Premaster secret encrypted under server RSA public key,
Signature on prior handshake messages,
ChangeCipherSpec, client “Finished”
Decrypt pms, derive ms, keys
ChangeCipherSpec, server “Finished”
Application data
5/29/2014 -- Updated 5/31 to
add link to white paper
7
Handshake using ephemeral
Diffie-Hellman (DH) key agreement
• Server certificate contains a public key pertaining to a
digital signature cryptosystem (RSA, DSA or ECDSA)
• Server uses the digital signature private key to sign an
ephemeral DH key pair
– Ephemeral: used for one handshake, then deleted
• DH key agreement produces premaster secret
• Forward secrecy: adversary who captures the digital
signature private key in the future cannot obtain the
premaster secret, nor the master secret, nor the traffic
protection keys because the ephemeral private key is
discarded.
5/29/2014 -- Updated 5/31 to
add link to white paper
8
DH key pair
• DH parameters:
– Prime modulus: p
– Group generator: g
– Private value: y
– Public value: gy
• DH private key: y
• DH public key: (p, g, gy)
5/29/2014 -- Updated 5/31 to
add link to white paper
9
Handshake using ephemeral DH => forward secrecy
Client random
Generate p, g, y, gy,
Sign p, g, gy and randoms
Server random, p, g, gy, signature, server certificate and chain
Generate x, gx
Premaster secret = gxy
Derive ms, keys
gx, ChangeCipherSpec, client “Finished”
Premaster secret = gxy
Derive ms, keys
ChangeCipherSpec, server “Finished”
Application data
5/29/2014 -- Updated 5/31 to
add link to white paper
10
Usability shortcoming:
handshake latency
• Handshake requires up to two roundtrips (in
addition to a TCP roundtrip and at least one data
roundtrip)
– At the speed of light, a signal takes 270ms to reach a
geostationary satellite
– Two round trips take 1080ms
– Downloading a page may require many connections,
hence many handshakes
• Big problem for accessing the web via satellite
from airplanes, ships, rural areas, Antarctica…
5/29/2014 -- Updated 5/31 to
add link to white paper
11
Usability shortcoming:
handshake bandwidth consumption
• The server certificate chain typically comprises
two or three certificates
• Certificate size is typically more than 2KB
• More bandwidth may be spent on certificates
than on content
• Problems:
– Congestion on bandwidth-constrained networks
– Increased data transmission costs and battery
drain for mobile devices
5/29/2014 -- Updated 5/31 to
add link to white paper
12
Deployed mitigation
• Abbreviated handshake for session resumption
(new connection with same master secret)
– One roundtrip only
– No certificate transmission
– Session resumption is widely implemented, but
only about 50% of handshakes are abbreviated, as
estimated by Google
5/29/2014 -- Updated 5/31 to
add link to white paper
13
Non-deployed mitigations
• Fast-track
– Client caches server certificate chain
One roundtrip, no certificate transmission
– Academic implementation, not deployed
• False Start
– Client sends application data before server “Finished” message
One roundtrip
– Deployed by Google in Chrome, then discontinued
•
Snap Start
– Both of the above
Zero roundtrips, no certificate transmission
– Google idea, not implemented
5/29/2014 -- Updated 5/31 to
add link to white paper
14
Privacy shortcomings
related to client authentication
• Client certificate, when used, is sent in the clear
• Limited range of authentication methods
– Supported: Public key certificates, attribute certificates
• Server cannot ask for specific certificates or attributes
– Not supported: Uncertified key pairs, U-Prove tokens, Idemix
anonymous credentials, credentials based on group signatures;
credentials based on identity-based cryptography, etc.
• Client authentication is part of the handshake => very hard
to add new authentication methods
• Without TLS support, privacy enhancing authentication
methods stand no chance of adoption
– U-Prove and Idemix are not supported products
– Attempt at productizing U-Prove failed
5/29/2014 -- Updated 5/31 to
add link to white paper
15
Privacy features we are missing out on
due to lack of support in TLS
• Uncertified key pairs:
– Cryptographic authentication without third-party
involvement for returning user authentication
– Same privacy as passwords, much stronger security
• Idemix:
– Selective disclosure of attributes, issue-show
unlinkability, multishow unlinkability
• U-Prove:
– Selective disclosure, issue-show unlinkability
• Selective disclosure certificates
– Selective disclosure with a mere public key certificate
5/29/2014 -- Updated 5/31 to
add link to white paper
16
Security shortcomings
• Long history of vulnerabilities
• Some have not been addressed yet
• Some have been addressed in TLS 1.1 or 1.2,
but most client and servers do not support
either
• Some are historic but interesting as illustration
of network security concepts
5/29/2014 -- Updated 5/31 to
add link to white paper
17
RSA timing vulnerabilities (historic)
• Paul Kocher 1996 attack
– Attacker asks server to decrypt many premaster secrets, uses a
statistical technique to guess the RSA private key of the server by
timing the decryptions
– Technique not applicable if CRT optimization is used
• Boneh and Brumley 2003 attack
– Different timing attack against CRT optimization
• Both attacks can be prevented by generating random r,
multiplying the encrypted premaster secret xe by the inverse
of re before decrypting, and multiplying the result by r
(r—exe)d = r—edxed = r—1x (mod n)
(r—1x) r = x
(mod n)
• This is the same technique used for RSA signature blinding
5/29/2014 -- Updated 5/31 to
add link to white paper
18
RSA padding vulnerability (historic)
• PKCS #1 version 1.5 specifies how the premaster secret
x is to be padded before being encrypted as
y = xe mod n
• MITM replaces y with yse mod n for many s, producing
the decryption (yse)d mod n = xedsed mod n = xs mod n
• By observing which values of s produce a bad-padding
error message from the server, attacker can compute
the premaster secret x
• Countermeasure: server does not report bad padding,
uses random value as premaster secret instead
5/29/2014 -- Updated 5/31 to
add link to white paper
19
The BEAST attack
• Before TLS 1.1 (April 2006), traffic encryption with a block
cipher (e.g. AES) in CBC mode used chained rather than
random initialization vectors, allowing a block-adaptive
chosen plaintext attack
• Attacker can test guesses of plaintext blocks
• No practical exploits were known until the BEAST attack
(September 2011) recovered authentication cookies
• At that time only 0.25% of servers and few browsers had
upgraded to TLS 1.1 or TLS 1.2
• Today many servers have upgraded, but most still haven’t
• Until recently, using the RC4 stream cipher instead of the
AES block cipher was recommended as a countermeasure
to BEAST; but RC4 vulnerabilities have now been found
5/29/2014 -- Updated 5/31 to
add link to white paper
20
The Lucky Thirteen attack
• Correct order for traffic protection: encrypt then authenticate
• TLS using block cipher in CBC mode:
– Authenticate then pad then encrypt
– Pad is not authenticated
• Chosen ciphertext attack can shift the plaintext so that it is interpreted as
padding by the recipient
• Before TLS 1.1, recipient omitted MAC computation if padding was not
well formed
 Leak of plaintext info => plaintext recovery
• After TLS 1.1 recipient should compute dummy MAC instead, but timing of
MAC computation still leaks plaintext info
 Lucky Thirteen attack
• Proposed mitigation
– Add steps to MAC computation to hide timing differences
– But proponents doubt that it will be effective
5/29/2014 -- Updated 5/31 to
add link to white paper
21
Compression-related attacks
(CRIME, TIME)
• TLS has an optional traffic compression stage
before traffic protection
• Amount of plaintext compression depends on
amount of redundancy in plaintext
– And plaintext length cannot be effectively hidden by
padding
• Chosen plaintext attack: attacker injects string,
compressed plaintext is shorter if injected string
can be found elsewhere in plaintext
Can test for the presence of strings in plaintext
5/29/2014 -- Updated 5/31 to
add link to white paper
22
Renegotiation vulnerability
• A TLS handshake can be performed over an existing
connection to change the connection parameters
– This is usually done to add client authentication
• MITM of handshake can cause the server to believe that
the handshake is a renegotiation of a prior TLS connection
from the attacker and that the client data after the
handshake is continuation of MITM data before handshake
• The attacker can send an HTTP GET request to the server,
and have it authenticated by the client
• Countermeasure: secure renegotiation extension
– Renegotiating client has to send the data in the “Finished”
message of the previous handshake
5/29/2014 -- Updated 5/31 to
add link to white paper
23
“Unknown key share (UKS)”
vulnerability
• Since the master secret is derived from
random quantities generated by client and
server during the handshake, it is commonly
assumed that it is unique to a connection
• But MITM can establish separate connections
with client and server that have the same
master secret
5/29/2014 -- Updated 5/31 to
add link to white paper
24
Triple handshake attack
1. MITM creates sessions with client and server
having same master secret
– “Finished” data are different because server certs are
different
2. MITM resumes both sessions
– “Finished” data are now the same because no server
certs are sent
3. MITM renegotiates both sessions
– Renegotiation extension countermeasure is defeated
because prior “Finished” data are the same
5/29/2014 -- Updated 5/31 to
add link to white paper
25
CA compromise vulnerability
• From time to time a CA is compromised (Comodo
3/2011, DigiNotar 9/2011)
• A compromised CA can issue a certificate to any
server
• A server with a certificate from an expensive very
secure CA can be impersonated as a result of a
compromise of an unrelated cheap and less
secure CA
• This is because the TLS client gets the server
certificate from the server itself
5/29/2014 -- Updated 5/31 to
add link to white paper
26
Recap: current security posture
• BEAST
– Solved in TLS 1.1, but most servers still vulnerable
• Lucky Thirteen
– Not clear if implementations attempt or achieve mitigation
• Compression-related attacks
– Compression still in TLS, applications vulnerable if they use it
• UKS
– Not addressed
• Triple handshake
– Not addressed
• CA compromise
– Not solved
5/29/2014 -- Updated 5/31 to
add link to white paper
27
It’s time to replace TLS
• Why replace rather than fix?
– TLS has too many shortcomings
– It is already too complex, due to prior fixes
• 5 versions in current use
• 23 extensions
• 28 RFCs
– There is upgrade fatigue
• Most servers have not yet upgraded to TLS 1.1 (April 2006)
• Now is the time
– Awareness of security and privacy breakdown on the Internet
• Trying to replace TLS is not hopeless
– New URL scheme can by used to indicate HTTP over new security protocol
– Mobile apps can use any protocol they want to interact to their back-ends
– Not the only replacement proposal (QUIC)
5/29/2014 -- Updated 5/31 to
add link to white paper
28
Possible ingredients for a replacement
•
•
•
•
•
•
•
•
•
Identity-based cryptography
DNS support
Forward secrecy from second flow
Optional: pre-shared key for server authentication in
the enterprise
Combination with TCP Fast Open
Client authentication independent of handshake
No compression
No padding
Encryption before authentication and/or authenticated
encryption
5/29/2014 -- Updated 5/31 to
add link to white paper
29
Identity-based cryptography
• Trusted party called “private key generator
(PKG)” analogous to certificate authority (CA)
• Public key of entity is computed from ID of
entity and public key of PKG
• Private key of entity is computed from ID of
entity and private key of PKG
– Can only be computed by PKG
– PKG gives it to entity
5/29/2014 -- Updated 5/31 to
add link to white paper
30
Expiration and revocation
• Key pair can be made to expire by adding an
expiration date or time to the identity, e.g.
– Server ID: “pomcor.com”
– ID with expiration date: “pomcor.com-20140529”
• Key pair can be revoked by adding a revocation
counter
– ID with revocation counter: “pomcor.com-4”
– Latest ID must be retrieved from trusted repository
• Short term expiration + emergency revocation
counter
– Pomcor.com-20140529-4
5/29/2014 -- Updated 5/31 to
add link to white paper
31
Using ID-based cryptography for the
new protocol
• There are ID-based cryptosystems for
encryption, digital signature and key
agreement
• ID-based encryption can be used for key
transport instead of RSA encryption
• There must be a hierarchy of PKGs just as
there is a hierarchy of CAs
• The PKG hierarchy must have multiple roots
just as the CA hierarchy has multiple roots
5/29/2014 -- Updated 5/31 to
add link to white paper
32
Traditional hierarchical identity-based
encryption, with single root
• Chain of PKGs
– Private key issuance:
PKG0  PKG1  …  PKGn  server
• Identity chain of server:
(Name, IDn, … , ID1)
• One set of cryptographic domain parameters
• Public key of server = identity chain + domain
parameters
5/29/2014 -- Updated 5/31 to
add link to white paper
33
Proposed hierarchical identity-based
encryption, with multiple roots
• Chain of PKGs
PKG0  PKG1  …  PKGn  server
• Identity chain of server:
(Name, IDn, … , ID1, ID0)
• Each root has its own domain parameters
• Domain parameters of trusted root PKGs are
stored by client
• Tail of server identity chain (IDn, … , ID1, ID0)
replaces certificate chain, but is much shorter
5/29/2014 -- Updated 5/31 to
add link to white paper
34
DNS support
• Tail of server identity chain retrieved from DNS
rather than server
– By contrast, certificate chain would be too large to be
reliably retrieved from the DNS
Zero roundtrips if replay of first data is not a
problem
DNSSEC solves the “CA compromise
shortcoming”
– DNS without DNSSEC mitigates it
• Compare to DANE
5/29/2014 -- Updated 5/31 to
add link to white paper
35
Forward secrecy from second flow
• ID-based key transport => initial traffic protection
keys
• Ephemeral DH => subsequent traffic protection
keys
• Client sends its EDH public key protected by initial
keys in first flow
• Server sends its EDH public key protected by
initial keys followed by data protected by
subsequent keys in second flow
• QUIC independently came up with similar trick
5/29/2014 -- Updated 5/31 to
add link to white paper
36
Generate client random (cr)
Generate pms1
Derive ms1 and keys1 from pms1 and cr (no antireplay)
Generate p, g, x, gx
cr, pms1 under server pub key, change (to keys1), (p, g, gx), data1
Decrypt pms1
Derive ms1 and keys1 from cr and pms1
Decrypt (p, g, gx) and data1
Generate y, gy
pms2 = gxy
Generate server random (sr)
Derive ms2 and keys2 from pms2, cr and sr
Implicit change (to keys1), sr, gy, change (to keys2), data2
pms2 = gxy,
Derive ms2 and keys2 from pms2, cr and sr
Decrypt data2
change (to keys2), data3
5/29/2014 -- Updated 5/31 to
add link to white paper
37
Pre-shared key for server
authentication
• Alternative way of avoiding certificate chains
• Well suited for corporate intranet
• Available in TLS
5/29/2014 -- Updated 5/31 to
add link to white paper
38
Combination with TCP Fast Open
• TCP Fast Open eliminates the TCP roundtrip in
some cases
– Implemented in kernel
– Available in Linux, Chrome OS and Android
– Support by Chrome browser but disabled by
default
– Relies on client caching a “TCP cookie”
5/29/2014 -- Updated 5/31 to
add link to white paper
39
Client authentication
independent of handshake
• Server asks for one or more identifiers or
attributes at any time after the secure connection
has been established
• Server tells client what kind of credentials it
supports
• Clients presents credentials of types acceptable
to server, with identifiers or attributes requested
by server
• Credential presentation protocols are specified
independently from the handshake
5/29/2014 -- Updated 5/31 to
add link to white paper
40
No compression
• Compression before encryption may leak
information, compression after encryption does
not work => TLS should not include compression
• Application layer compression (e.g. HTTP
compression) can also leak information: BREACH
attack
• But application layer could address the problem
(e.g. by using multiple compression contexts)
where as TLS cannot
5/29/2014 -- Updated 5/31 to
add link to white paper
41
No padding
• Use CFB, OFB or authenticated encryption
modes that require no padding instead of CBC
mode
5/29/2014 -- Updated 5/31 to
add link to white paper
42
Authentication after encryption
• Authentication after encryption has been proven
secure
– MAC on ciphertext provides effective defense against
chosen ciphertext attacks
• An alternative is authenticated encryption modes
of operation, which simultaneously encrypt and
authenticate
– A.k.a. authenticated encryption with added data
(AEAD)
– GCM, CCM, etc.
5/29/2014 -- Updated 5/31 to
add link to white paper
43
The formal verification challenge
• Avoiding a string of vulnerabilities will require
formal verification
• But formal verification will be very
challenging, for three reasons…
5/29/2014 -- Updated 5/31 to
add link to white paper
44
1. The problem is intrinsically difficult
• Stating the security goal is difficult
– Security is not absolute: goal is to prove that the
adversary is unlikely to win, in some sense
• Modeling a network security protocol is difficult
– It’s easy to miss key details
– Example: the use of CBC mode in TLS was proved
correct, overlooking the IV chaining mistake
• Modeling the adversary may be even more
difficult
5/29/2014 -- Updated 5/31 to
add link to white paper
45
2. The state of the art needs
improvement
• Verification consists of proofs on paper, which
are extremely complex and not always
rigorous
• Bellare and Rogaway: “In our opinion, many
proofs in cryptography have become
essentially unverifiable. Our field may be
approaching a crisis of rigor.”
5/29/2014 -- Updated 5/31 to
add link to white paper
46
3. Some of the proposed ingredients
may require new verification
techniques
• Explicit reliance on the DNS for security
• Combination of two different key
establishment techniques in the same
protocol
5/29/2014 -- Updated 5/31 to
add link to white paper
47
Thank you for your attention!
Any questions?
Whitepaper at
http://pomcor.com/whitepapers/TimeToRedesignTLS.pdf
Karen P. Lewison
kplewison@pomcor.com
Francisco Corella
fcorella@pomcor.com
5/29/2014 -- Updated 5/31 to
add link to white paper
48