CS 6431 SSL TLS Vitaly Shmatikov What Is

CS 6431 SSL/TLS Vitaly Shmatikov

What Is SSL / TLS? u. Secure Sockets Layer and Transport Layer Security protocols • Same protocol design, different crypto algorithms u. De facto standard for Internet security • “The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications” u. Deployed in every Web browser; also Vo. IP, payment systems, distributed systems, etc. slide 2

SSL / TLS Guarantees u. End-to-end secure communications in the presence of a network attacker • Attacker completely 0 wns the network: controls Wi-Fi, DNS, routers, his own websites, can listen to any packet, modify packets in transit, inject his own packets into the network u. Scenario: you are reading your email from an Internet café connected via a r 00 ted Wi-Fi access point to a dodgy ISP in a hostile authoritarian country slide 3

History of the Protocol u. SSL 1. 0 – internal Netscape design, early 1994? • Lost in the mists of time u. SSL 2. 0 – Netscape, Nov 1994 • Several weaknesses u. SSL 3. 0 – Netscape and Paul Kocher, Nov 1996 u. TLS 1. 0 – Internet standard, Jan 1999 • Based on SSL 3. 0, but not interoperable (uses different cryptographic algorithms) u. TLS 1. 1 – Apr 2006 u. TLS 1. 2 – Aug 2008 slide 4

SSL Basics u. SSL consists of two protocols u. Handshake protocol • Uses public-key cryptography to establish several shared secret keys between the client and the server u. Record protocol • Uses the secret keys established in the handshake protocol to protect confidentiality, integrity, and authenticity of data exchange between the client and the server slide 5

SSL Handshake Protocol u. Runs between a client and a server • For example, client = Web browser, server = website u. Negotiate version of the protocol and the set of cryptographic algorithms to be used • Interoperability between different implementations u. Authenticate server and client (optional) • Use digital certificates to learn each other’s public keys and verify each other’s identity • Often only the server is authenticated u. Use public keys to establish a shared secret slide 6

Handshake Protocol Structure Client. Hello Server. Hello, [Certificate], [Server. Key. Exchange], [Certificate. Request], Server. Hello. Done C [Certificate], Client. Key. Exchange, [Certificate. Verify] S switch to negotiated cipher Finished Record of all sent and received handshake messages switch to negotiated cipher Finished slide 7

Client. Hello C Client announces (in plaintext): • Protocol version he is running • Cryptographic algorithms he supports • Fresh, random number S slide 8

Client. Hello (RFC) struct { Protocol. Version client_version; Session id (if the client wants to Random random; resume an old session) Session. ID session_id; Set of cryptographic algorithms supported by the client (e. g. , Cipher. Suite cipher_suites; RSA or Diffie-Hellman) Compression. Method compression_methods; } Client. Hello Highest version of the protocol supported by the client slide 9

Server. Hello C, versionc, suitesc, Nc Server. Hello C Server responds (in plaintext) with: • Highest protocol version supported by both the client and the server • Strongest cryptographic suite selected from those offered by the client • Fresh, random number S slide 10

Server. Key. Exchange C, versionc, suitesc, Nc versions, suites, Ns, Server. Key. Exchange C Server sends his public-key certificate containing either his RSA, or his Diffie-Hellman public key (depending on chosen crypto suite) S slide 11

Client. Key. Exchange C, versionc, suitesc, Nc versions, suites, Ns, certificate, “Server. Hello. Done” C Client. Key. Exchange S The client generates secret key material and sends it to the server encrypted with the server’s public key (if using RSA) slide 12

Client. Key. Exchange (RFC) struct { select (Key. Exchange. Algorithm) { case rsa: Encrypted. Pre. Master. Secret; case diffie_hellman: Client. Diffie. Hellman. Public; } exchange_keys } Client. Key. Exchange Where do random bits come from? struct { Protocol. Version client_version; Random bits from which opaque random[46]; symmetric keys will be derived (by hashing them with nonces) } Pre. Master. Secret slide 13

Debian Linux (2006 -08) u. A line of code commented out from md_rand • MD_Update(&m, buf, j); /* purify complains */ u. Without this line, the seed for the pseudo-random generator is derived only from process ID • Default maximum on Linux = 32768 u. Result: all keys generated using Debian-based Open. SSL package in 2006 -08 are predictable • “Affected keys include SSH keys, Open. VPN keys, DNSSEC keys, and key material for use in X. 509 certificates and session keys used in SSL/TLS connections” slide 14

RSA Cryptosystem u. Key generation: • Generate large (say, 512 -bit) primes p, q • Compute n=pq and (n)=(p-1)(q-1) • Choose small e, relatively prime to (n) – Typically, e=3 (may be vulnerable) or e=216+1=65537 (why? ) • Compute unique d such that ed = 1 mod (n) • Public key = (e, n); private key = d – Security relies on the assumption that it is difficult to compute roots modulo n without knowing p and q u. Encryption of m (simplified!): c = me mod n u. Decryption of c: cd mod n = (me)d mod n = m slide 15

How RSA Encryption Works u. RSA encryption: compute yx mod n • This is a modular exponentiation operation u. Naïve algorithm: square and multiply Modern implementations more complex: - Chinese Remainder Theorem - Sliding windows - Different multiplication algorithms depending on the size of the operands slide 16

RSA Keys in the Wild [Lenstra et al. “Ron was wrong, Whit is right” CRYPTO 2012] u. Corpus of over 6 million RSA public key • Sources: X. 509 certificates from EFF SSL observatory, PGP keyservers u. RSA public key is (e, n) • Some problems with e • Many problems with n slide 17

Bad “e” in the Wild [Lenstra et al. “Ron was wrong, Whit is right” CRYPTO 2012] Includes: • 8 occurrences of e=1 • 2 occurrences of even e • 2 occurrences of suspiciously large/random e slide 18

How Did This Happen? [Lenstra et al. “Ron was wrong, Whit is right” CRYPTO 2012] u. Small “e” are safe if message is properly padded u. Special small “e” = fast encryption and signature verification u“e” and “d” are interchangeable in key generation u. Let’s pick a special “d” to make decryption/signing fast! slide 19

Bad “n” in the Wild [Lenstra et al. “Ron was wrong, Whit is right” CRYPTO 2012] u. Identical RSA moduli in different certificates • 4. 3% of X. 509 certs have non-unique moduli • Legitimate reason: same owner, different expiration dates… but sometimes no obvious relation u. Broken RSA moduli • Prime “n” (2 occurrences) • “n” with small factors (171 occurrences) – Of these, 68 occurrences of even “n” • “n” with common factors (20, 000+ occurrences) – Why is this bad? slide 20

Factoring “n” with Common Factors [Lenstra et al. “Ron was wrong, Whit is right” CRYPTO 2012] u. Private key of user A has n = p q u. Private key of user B has n’ = p’ q’ u. What if p = p’ u. Anyone can compute GCD(n, n’) and recover p, q, q’, thus both keys are completely broken slide 21

How? Maybe Like This… [Lenstra et al. “Ron was wrong, Whit is right” CRYPTO 2012] seed_my_rng() PRIME p = random_prime() // just to be safe seed_my_rng_again() PRIME q = random_prime() void seed_my_rng() { state = 4 // chosen by fair dice roll } slide 22

How? Maybe Like This… [Lenstra et al. “Ron was wrong, Whit is right” CRYPTO 2012] PRIME random_prime() { PRIME p; do { p = random_number(); } while (!prime(p)); // I Feel Lucky ! return p; } slide 23

Culprits [Lenstra et al. “Ron was wrong, Whit is right” CRYPTO 2012] u. Network device manufacturer • X. 509 self-signed certificates • A single p in common for several thousand certs • Duplicate keys on seemingly unrelated devices, moduli are correlated with cert generation times u. Embedded management device • Fully connected set of 9 distinct primes • Each modulus occurs in many keys with unrelated owners slide 24

“Core” SSL Handshake C, versionc=3. 0, suitesc, Nc versions=3. 0, suites, Ns, certificate for PKs, “Server. Hello. Done” C {Secretc}PKs if using RSA C and S share secret key material (secretc) at this point switch to keys derived from secretc , Ns Finished S switch to keys derived from secretc , Ns Finished slide 25

SSL 2. 0 Weaknesses (Fixed in 3. 0) u. Cipher suite preferences are not authenticated • “Cipher suite rollback” attack is possible u. Weak MAC construction, MAC hash uses only 40 bits in export mode u. SSL 2. 0 uses padding when computing MAC in block cipher modes, but padding length field is not authenticated • Attacker can delete bytes from the end of messages u. No support for certificate chains or non-RSA algorithms slide 26

Version Rollback Attack C, versionc=2. 0, suitesc, Nc Server is fooled into thinking he is communicating with a client who supports only SSL 2. 0 C versions=2. 0, suites, Ns, certificate for PKs, “Server. Hello. Done” {Secretc}PKs S C and S end up communicating using SSL 2. 0 (weaker earlier version of the protocol that does not include “Finished” messages) slide 27

Version Check in SSL 3. 0 C, versionc=3. 0, suitesc, Nc C versions=3. 0, suites, Ns, certificate for PKs, “Server. Hello. Done” “Embed” version number into secret {versionc, secretc}PKs Check that received version is equal to the version in Client. Hello S C and S share secret key material secretc at this point switch to key derived from secretc, Nc, Ns slide 28

TLS Version Rollback C, versionc=3. 0, suitesc, Nc Server is fooled into thinking he is communicating with a client who supports only SSL 3. 0 C POODLE attack (October 2014) versions=3. 0, suites, Ns, certificate for PKs, “Server. Hello. Done” C and S end up communicating using SSL 3. 0 (deprecated but supported by everyone for backward compatibility) S Attack exploits “padding oracle” in CBC encryption mode as used by SSL 3. 0 to infer the value of encrypted cookies Many “padding oracle” attacks over the years: BEAST, CRIME, … slide 29

“Chosen-Protocol” Attacks u. Why do people release new versions of security protocols? Because the old version got broken! u. New version must be backward-compatible • Not everybody upgrades right away u. Attacker can fool someone into using the old, broken version and exploit known vulnerabilities • Similar: fool victim into using weak crypto algorithms u. Defense is hard: must authenticate version early u. Many protocols had “version rollback” attacks • SSL, SSH, GSM (cell phones) slide 30

Diffie-Hellman Key Establishment u. Alice and Bob never met and share no secrets u. Public information: p and g, where p is a large prime number, g is a generator of Z*p • Z*p={1, 2 … p-1}; a Z*p i such that a=gi mod p Pick secret, random X gx mod p Pick secret, random Y gy mod p Alice Compute k=(gy)x=gxy mod p Bob Compute k=(gx)y=gxy mod p slide 31

Why Is Diffie-Hellman Secure? u. Discrete Logarithm (DL) problem: given gx mod p, it’s hard to extract x • There is no known efficient algorithm for doing this • This is not enough for Diffie-Hellman to be secure! u. Computational Diffie-Hellman (CDH) problem: given gx and gy, it’s hard to compute gxy mod p • … unless you know x or y, in which case it’s easy u. Decisional Diffie-Hellman (DDH) problem: given gx and gy, it’s hard to tell the difference between gxy mod p and gr mod p where r is random slide 32

Security of Diffie-Hellman Protocol u. Assuming the DDH problem is hard, Diffie-Hellman protocol is a secure key establishment protocol against passive attackers • Eavesdropper can’t tell the difference between the established key and a random value • Can use the established key for symmetric cryptography – Approx. 1000 times faster than modular exponentiation u. Basic Diffie-Hellman protocol is not secure against an active, man-in-the-middle attacker • Need signatures or another authentication mechanism slide 33

TLS/SSL with Diffie-Hellman crypto suites (incl. DHE), Nc Ciphersuite not signed DHE, Ns, certificate for RSA public key, p, g, ga, sign. RSAkey(ga) C gb S C and S share secret gab at this point switch to derived keys Finished slide 34

DH Downgrade by MITM LOGJAM attack “Export-grade” DHE, Nc DHE, Ns, certificate for RSA public key, p, g, ga, sign. RSAkey(ga) C gb C and S share secret gab at this point S “Export-grade” Diffie-Hellman: • 97% of hosts use one of three 512 -bit primes • With 1 week of precomputation, takes 70 seconds of real time to compute discrete log slide 35

Isn’t the Dialog Verified? crypto suites (incl. DHE), Nc DHE, Ns, certificate for RSA public key, p, g, ga, sign. RSAkey(ga) C gb Do these authentication messages help? C and S share secret gab at this point switch to derived keys Finished S switch to derived keys Finished slide 36

More Fun With Diffie-Hellman crypto suites (incl. DHE), Nc DHE, Ns, certificate for RSA public key, p, g, ga, sign. RSAkey(ga) C gb C and S share secret gab at this point switch to derived keys Validate the certificate S switch to derived keys Finished … then verify the signature on the DH value Finished using the public key from the certificate slide 37

MITM Presenting Valid Certificate Hello I am Pay. Pal. com (or whoever you want me to be) Here is Pay. Pal’s certificate for its RSA signing key And here is my signed Diffie-Hellman value Validate the certificate … then verify the signature on the DH value using the public key from the certificate slide 38

Goto Fail Here is Pay. Pal’s certificate And here is my signed Diffie-Hellman value … verify the signature on the DH value using the public key from the certificate if ((err = SSLHash. SHA 1. update(&hash. Ctx, &client. Random)) != 0) goto fail; if ((err = SSLHash. SHA 1. update(&hash. Ctx, &server. Random)) != 0) goto fail; if ((err = SSLHash. SHA 1. update(&hash. Ctx, &signed. Params)) != 0) goto fail; ? ? ? if ((err = SSLHash. SHA 1. final(&hash. Ctx, &hash. Out)) != 0) goto fail; … Signature is verified here err = ssl. Raw. Verify(. . . ); … fail: … return err … slide 39

Complete Fail Against MITM u. Discovered in February 2014 u. All OS X and i. OS software vulnerable to man-in-the-middle attacks • Broken TLS implementation provides no protection against the very attack it was supposed to prevent u. What does this tell you about quality control for security-critical software? slide 40

Motivation https: // Whose public key is used to establish the secure session? slide 41

Distribution of Public Keys u. Public announcement or public directory • Risks: forgery and tampering u. Public-key certificate • Signed statement specifying the key and identity – sig. Alice(“Bob”, PKB) u. Common approach: certificate authority (CA) • An agency responsible for certifying public keys • Browsers are pre-configured with 100+ of trusted CAs • A public key for any website in the world will be accepted by the browser if certified by one of these CAs slide 42

Trusted Certificate Authorities slide 43

CA Hierarchy u. Browsers, operating systems, etc. have trusted root certificate authorities • Firefox 3 includes certificates of 135 trusted root CAs u. A Root CA signs certificates for intermediate CAs, they sign certificates for lower-level CAs, etc. • Certificate “chain of trust” – sig. Verisign(“UT Austin”, PKUT), sig. UT(“Vitaly S. ”, PKVitaly) u. CA is responsible for verifying the identities of certificate requestors, domain ownership slide 44

Certificate Hierarchy What power do they have? Who trusts their certificates? slide 45

Example of a Certificate Important fields slide 46

X. 509 Authentication Service u. Internet standard (1988 -2000) u. Specifies certificate format • X. 509 certificates are used in IPsec and SSL/TLS u. Specifies certificate directory service • For retrieving other users’ CA-certified public keys u. Specifies a set of authentication protocols • For proving identity using public-key signatures u. Can use with any digital signature scheme and hash function, but must hash before signing slide 47

X. 509 Certificate Added in X. 509 versions 2 and 3 to address usability and security problems hash slide 48

Back in 2008 [Sotirov et al. “MD 5 Considered Harmful Today: Creating a Rogue CA Certificate”] u. Many CAs still used MD 5 • Rapid. SSL, Free. SSL, Trust. Center, RSA Data Security, Thawte, verisign. co. jp u. Sotirov et al. collected 30, 000 website certificates u 9, 000 of them were signed using MD 5 hash u 97% of those were issued by Rapid. SSL slide 49

Colliding Certificates [Sotirov et al. ] set by the CA serial number validity period chosen prefix (difference) real cert domain name real cert RSA key Hash to the same MD 5 value! Valid for both certificates! X. 509 extensions signature validity period rogue cert domain name ? ? ? collision bits (computed) identical bytes (copied from real cert) X. 509 extensions signature slide 50

Generating Collisions [Sotirov et al. ] 1 -2 days on a cluster of 200 Play. Station 3’s Equivalent to 8000 desktop CPU cores or $20, 000 on Amazon EC 2 slide 51

Generating Colliding Certificates [Sotirov et al. ] u. Rapid. SSL uses a fully automated system • $69 for a certificate, issued in 6 seconds • Sequential serial numbers u. Technique for generating colliding certificates • • Get a certificate with serial number S Predict time T when Rapid. SSL’s counter goes to S+1000 Generate the collision part of the certificate Shortly before time T buy enough (non-colliding) certificates to increment the counter to S+999 • Send colliding request at time T and get serial number S+1000 slide 52

Creating a Fake Intermediate CA [Sotirov et al. ] serial number rogue CA cert validity period real cert domain name real cert RSA key X. 509 extensions signature chosen prefix (difference) collision bits (computed) identical bytes (copied from real cert) rogue CA RSA key rogue CA X. 509 CA bit! extensions We are now an intermediate CA. Netscape Comment W 00 T! Extension (contents ignored by browsers) signature slide 53

Result: Perfect Man-in-the-Middle u. This is a “skeleton key” certificate: it can issue fully trusted certificates for any site (why? ) u. To take advantage, need a network attack • Insecure wireless, DNS poisoning, proxy autodiscovery, hacked routers, etc. slide 54

A Rogue Certificate slide 55

Flame u. Cyber-espionage virus (2010 -2012) u. Signed with a fake intermediate CA certificate that appears to be issued by Microsoft and thus accepted by any Windows Update service • Fake intermediate CA certificate was created using an MD 5 chosen-prefix collision against an obscure Microsoft Terminal Server Licensing Service certificate that was enabled for code signing and still used MD 5 u. MD 5 collision technique possibly pre-dates Sotirov et al. ’s work • Evidence of state-level cryptanalysis? slide 56

Comodo u. Comodo is one of the trusted root CAs • Its certificates for any website in the world are accepted by every browser u. Comodo accepts certificate orders submitted through resellers • Reseller uses a program to authenticate to Comodo and submit an order with a domain name and public key, Comodo automatically issues a certificate for this site slide 57

Comodo Break-In u. An Iranian hacker broke into instant. SSL. it and global. Trust. it resellers, decompiled their certificate issuance program, learned the credentials of their reseller account and how to use Comodo API • username: gtadmin, password: globaltrust u. Wrote his own program for submitting orders and obtaining Comodo certificates u. On March 15, 2011, got Comodo to issue 9 rogue certificates for popular sites • mail. google. com, login. live. com, login. yahoo. com, login. skype. com, addons. mozilla. org, “global trustee" slide 58

Consequences u. Attacker needs to first divert users to an attackercontrolled site instead of Google, Yahoo, Skype, but then… • For example, use DNS to poison the mapping of mail. yahoo. com to an IP address u… “authenticate” as the real site u… decrypt all data sent by users • Email, phone conversations, Web browsing Q: Does HTTPS help? How about EV certificates? slide 59

Message from the Attacker http: //pastebin. com/74 KXCa. EZ I'm single hacker with experience of 1000 hacker, I'm single programmer with experience of 1000 programmer, I'm single planner/project manager with experience of 1000 project managers … When USA and Isarel could read my emails in Yahoo, Hotmail, Skype, Gmail, etc. without any simple little problem, when they can spy using Echelon, I can do anything I can. It's a simple rule. You do, I do, that's all. You stop, I stop. It's rule #1 … Rule#2: So why all the world got worried, internet shocked and all writers write about it, but nobody writes about Stuxnet anymore? . . . So nobody should write about SSL certificates. Rule#3: I won't let anyone inside Iran, harm people of Iran, harm my country's Nuclear Scientists, harm my Leader (which nobody can), harm my President, as I live, you won't be able to do so. as I live, you don't have privacy in internet, you don't have security in digital world, just wait and see. . . slide 60

Digi. Notar Break-In u. In June 2011, the same “Comodo. Hacker” broke into a Dutch certificate authority, Digi. Notar • Message found in scripts used to generate fake certificates: “THERE IS NO ANY HARDWARE OR SOFTWARE IN THIS WORLD EXISTS WHICH COULD STOP MY HEAVY ATTACKS MY BRAIN OR MY SKILLS OR MY WILL OR MY EXPERTISE" u. Security of Digi. Notar servers • All core certificate servers in a single Windows domain, controlled by a single admin password (Pr 0 d@dm 1 n) • Software on public-facing servers out of date, unpatched • Tools used in the attack would have been easily detected by an antivirus… if it had been present slide 61

Consequences of Digi. Notar Hack u. Break-in not detected for a month u. Rogue certificates issued for *. google. com, Skype, Facebook, www. cia. gov, and 527 other domains u 99% of revocation lookups for these certificates originated from Iran • Evidence that rogue certificates were being used, most likely by Iranian government or Iranian ISPs to intercept encrypted communications – Textbook man-in-the-middle attack • 300, 000 users were served rogue certificates slide 62

Another Message from the Attacker http: //pastebin. com/u/Comodo. Hacker Most sophisticated hack of all time … I’m really sharp, powerful, dangerous and smart! My country should have control over Google, Skype, Yahoo, etc. […] I’m breaking all encryption algorithms and giving power to my country to control all of them. You only heards Comodo (successfully issued 9 certs for me -thanks by the way-), Digi. Notar (successfully generated 500+ code signing and SSL certs for me -thanks again-), Start. COM (got connection to HSM, was generating for twitter, google, etc. CEO was lucky enough, but I have ALL emails, database backups, customer data which I'll publish all via cryptome in near future), Global. Sign (I have access to their entire server, got DB backups, their linux / tar gzipped and downloaded, I even have private key of their OWN globalsign. com domain, hahahaa). . BUT YOU HAVE TO HEAR SO MUCH MORE! At least 3 more, AT LEAST! slide 63

Trust. Wave u. In Feb 2012, admitted issuing an intermediate CA certificate to a corporate customer • Purpose: “re-sign” certificates for “data loss prevention” • Translation: forge certificates of third-party sites in order to spy on employees’ encrypted communications with the outside world u. Customer can now forge certificates for any site in world… and they will be accepted by any browser! • What if a “re-signed” certificate leaks out? u. Do other CAs do this? slide 64

Turk. Trust u. In Jan 2013, a rogue *. google. com certificate was issued by an intermediate CA that gained its authority from the Turkish root CA Turk. Trust • Turk. Trust accidentally issued intermediate CA certs to customers who requested regular certificates • Ankara transit authority used its certificate to issue a fake *. google. com certificate in order to filter SSL traffic from its network u. This rogue *. google. com certificate was trusted by every browser in the world slide 65