1. 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

2. 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

3. 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

4. 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

5. 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

6. Handshake using key transport 5/29/2014 -- Updated 5/31 to add link to white paper 6 ClientServer Client random Server random, RSA public key certificate and certificate chain Premaster secret encrypted under server RSA public key, ChangeCipherSpec, client “Finished” Generate premaster secret, derive master secret and traffic protection keys Decrypt premaster secret, derive master secret and traffic protection keys ChangeCipherSpec, server “Finished” Application data

7. Handshake with client authentication 5/29/2014 -- Updated 5/31 to add link to white paper 7 ClientServer Client random Server random, RSA public key certificate and chain, certificate request 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” Generate pms, ms, keys Decrypt pms, derive ms, keys ChangeCipherSpec, server “Finished” Application data

8. 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

9. DH key pair DH parameters: – Prime modulus: p – Group generator: g – Private value: y – Public value: g y DH private key: y DH public key: (p, g, g y ) 5/29/2014 -- Updated 5/31 to add link to white paper 9

10. Handshake using ephemeral DH => forward secrecy 5/29/2014 -- Updated 5/31 to add link to white paper 10 Client random Server random, p, g, g y, signature, server certificate and chain g x, ChangeCipherSpec, client “Finished” Generate x, g x Premaster secret = g xy Derive ms, keys Premaster secret = g xy Derive ms, keys ChangeCipherSpec, server “Finished” Application data Generate p, g, y, g y, Sign p, g, g y and randoms

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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 x e by the inverse of r e before decrypting, and multiplying the result by r (r —e x e ) d = r —ed x ed = r —1 x(mod n) (r —1 x) 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

19. RSA padding vulnerability (historic) PKCS #1 version 1.5 specifies how the premaster secret x is to be padded before being encrypted as y = x e mod n MITM replaces y with ys e mod n for many s, producing the decryption (ys e ) d mod n = x ed s ed 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

20. 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

21. 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

22. 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

23. 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

24. “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

25. 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

26. 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

27. 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

28. 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

29. 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

30. 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

31. 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

32. 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

33. Traditional hierarchical identity-based encryption, with single root Chain of PKGs – Private key issuance: PKG 0  PKG 1  …  PKG n  server Identity chain of server: (Name, ID n, …, ID 1 ) 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

34. Proposed hierarchical identity-based encryption, with multiple roots Chain of PKGs PKG 0  PKG1  …  PKGn  server Identity chain of server: (Name, ID n, …, ID 1, ID 0 ) Each root has its own domain parameters Domain parameters of trusted root PKGs are stored by client Tail of server identity chain (ID n, …, ID 1, ID 0 ) replaces certificate chain, but is much shorter 5/29/2014 -- Updated 5/31 to add link to white paper 34

35. 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

36. 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

37. 5/29/2014 -- Updated 5/31 to add link to white paper 37 change (to keys2), data3 Implicit change (to keys1), sr, g y, change (to keys2), data2 Generate client random (cr) Generate pms1 Derive ms1 and keys1 from pms1 and cr (no antireplay) Generate p, g, x, g x Decrypt pms1 Derive ms1 and keys1 from cr and pms1 Decrypt (p, g, g x ) and data1 Generate y, g y pms2 = g xy Generate server random (sr) Derive ms2 and keys2 from pms2, cr and sr pms2 = g xy, Derive ms2 and keys2 from pms2, cr and sr Decrypt data2 cr, pms1 under server pub key, change (to keys1), (p, g, g x ), data1

38. 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

39. 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

40. 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

41. 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

42. 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

43. 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

44. 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

45. 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

46. 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

47. 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

48. 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