Replacing SSL/TLS: Its Time for a Protocol Update

Its 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

Handshake using key transport Client 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

Its 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