SSL and HTTPS ============= Overall problem: security in the presence of a network adversary. Web browser communicates with web servers via network. Unlike previous lectures, adversary assumed to intercept, modify packets. Turns out this is a good model for many situations: Nearby adversaries can intercept packets on wired, wireless networks. Adversaries can often spoof packets from arbitrary sources. How to build secure systems in the presence of such adversaries? Recall: two kinds of encryption schemes. E is encrypt, D is decrypt Symmetric key cryptography means same key is used to encrypt & decrypt ciphertext = E_k(plaintext) plaintext = D_k(ciphertext) Asymmetric key (public-key) cryptography: encrypt & decrypt keys differ ciphertext = E_PK(plaintext) plaintext = D_SK(ciphertext) PK and SK are called public and secret (private) key, respectively Public-key cryptography is orders of magnitude slower than symmetric Encryption provides data secrecy, often also want integrity. Message authentication code (MAC) with symmetric keys can provide integrity. Look up HMAC if you're interested in more details. Can use public-key crypto to sign and verify, almost the opposite: Use secret key to generate signature (compute D_SK) Use public key to check signature (compute E_PK) How to secure network communication with cryptography? (Simple sketch.) Suppose two computers already have a shared secret key. Use symmetric encryption and MAC to encrypt, authenticate messages. Adversary cannot decrypt or tamper with messages. What can we do if two computers don't have a shared secret? One possibility: two computers know each other's public keys. Use public-key encryption (expensive) to exchange symmetric keys. Strawman: A picks symmetric key, encrypts with PK_B, sends to B. Now fall back to symmetric encryption/MAC case. What can go wrong with strawman? Adversary can replay all of A's traffic and B would not notice. Solution: have the server send a nonce (random value). Incorporate the nonce into the final master secret: K_master = f(K_pre-master, nonce) Adversary can impersonate A, by sending another symmetric key to B. Possible solution (one of many; if B cares who A is): B also chooses and send a symmetric key to A, encrypted with PK_A. Then both A and B use a hash of the two keys combined. Adversary can later obtain SK_B, decrypt symmetric key and all messages. Solution: use a key exchange protocol like Diffie-Hellman, which provides forward secrecy. What if neither computer knows each other's public key? Common approach: use a trusted third party to generate certificates. Certificate is tuple (name, pubkey), signed by certificate authority. Meaning: certificate authority claims that name's public key is pubkey. B sends A a pubkey along with a certificate. If A trusts certificate authority, continue as above. The process to establish K_master is called the "handshake" Plan for securing web browsers: HTTPS New protocol: https instead of http (e.g., https://www.paypal.com/). 1. How to ensure data is not sniffed or tampered with on the network? Use SSL (a cryptographic protocol that uses certificates). SSL encrypts and authenticates network traffic. Negotiate ciphers (and other features: compression, extensions). Negotiation is done in clear. Include a MAC of all handshake messages to authenticate. 2. How to ensure that we are talking with the right server? SSL certificate name must match hostname in the URL In our example, certificate name must be www.paypal.com. One level of wildcard is also allowed (*.paypal.com) Browsers trust a number of certificate authorities. What happens if adversary tampers with DNS records? Good news: security doesn't depend on DNS. We already assumed adversary can tamper with network packets. Wrong server will not know correct private key matching certificate. 3. How to ensure client-side Javascript cannot be used to subvert security? Origin (from the same-origin policy) includes the protocol. http://www.paypal.com/ is different from https://www.paypal.com/ Here, we care about integrity of data (e.g., Javascript code). Result: non-HTTPS pages cannot tamper with HTTPS pages. Rationale: non-HTTPS pages could have been modified by adversary. 4. How to ensure user credentials are not sent to wrong server? Server certificates help clients differentiate between servers. Cookies (common form of user credentials) have a "Secure" flag. Secure cookies can only be sent with HTTPS requests. Non-Secure cookies can be sent with HTTP and HTTPS requests. 5. Finally, users can enter credentials directly. How to secure that? Lock icon in the browser tells user they're interacting with HTTPS site. Browser should indicate to the user the name in the site's certificate. User should verify site name they intend to give credentials to. How can this plan go wrong? As you might expect, every step above can go wrong. Not an exhaustive list, but gets at problems that ForceHTTPS wants to solve. 1. Cryptography. There have been some attacks on the cryptographic parts of SSL. Attack by Rizzo and Duong can allow adversary to learn some plaintext by issuing many carefully-chosen requests over a single SSL connection. (BEAST) More recent attack by same people using compression, mentioned in iSEC lecture. (CRIME) Some servers/CAs use weak crypto, e.g. certificates using MD5. Some clients choose weak crypto (e.g., SSL on Android). But, cryptography is rarely the weakest part of a system. 2. Authenticating the server. Adversary may be able to obtain a certificate for someone else's name. Used to require a faxed request on company letterhead (but how to check?) Now often requires receiving secret token at root@domain.com or similar. Security depends on the policy of least secure certificate authority. There are 100's of trusted certificate authorities in most browsers. Several CA compromises in 2011 (certs for gmail, etc obtained) Servers may be compromised and the corresponding private key stolen. How to deal with compromised certificate (e.g., invalid cert or stolen key)? Certificates have expiration dates. Checking certificate status with CA on every request is hard to scale. Certificate Revocation List (CRL) published by some CA's, but relatively few certificates in them (spot-checking: most have zero revoked certs). CRL must be periodically downloaded by client. Could be slow, if many certs are revoked. Not a problem if few or zero certs are revoked, but not too useful. OCSP: online certificate status protocol. Query whether a certificate is valid or not. Various heuristics for guessing whether certificate is OK or not. CertPatrol, EFF's SSL Observatory, .. Not as easy as "did the cert change?". Websites sometimes test new CAs. Problem: online revocation checks are soft-fail. An active network attacker can just make the checks unavailable. Browsers don't like blocking on a side channel. (Performance, single point of failure, captive portals, etc.) In practice browsers push updates with blacklist after major breaches. SSL implementations have bugs in verifying certificate names. Remember important principle from 6.033: "be explicit". Certificate contains length (in bytes) followed by that many name bytes. Many C implementations store names as standard C strings. Some CAs would provide certificates for www.paypal.com\0.attacker.com. To non-C code (e.g., Java), looks like a valid attacker.com subdomain. Users ignore certificate mismatch errors. Despite certificates being easy to obtain, many sites misconfigure them. Some don't want to deal with (non-zero) cost of getting certificates. Others forget to renew them (certificates have expiration dates). End result: browsers allow users to override mismatched certificates. About 60% of bypass buttons shown by Chrome are clicked through. 3. Mixing HTTP and HTTPS content. Web page origin is determined by the URL of the page itself. Page can have many embedded elements: Javascript via