SSL and HTTPS ============= Administrivia Lab 4 is posted. Get started on lab 4 early if you haven't worked with Javascript before. Overall problem: security in the presence of a network adversary. Web browser communicates with web servers via network. Unlike last lecture, consider adversaries that 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. Let c denote the ciphertext, p is plaintext, E is encrypt, D is decrypt Symmetric key cryptography means same key is used to encrypt & decrypt c = E_k(p) p = D_k(c) Asymmetric key (public-key) cryptography: encrypt & decrypt keys differ c = E_PK(p) p = D_SK(c) PK and SK are called public and secret (private) key, respectively Public-key cryptography is orders of magnitude slower than symmetric We will look at the internals of these algorithms in a later lecture. 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 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. If both parties trust certificate authority, can obtain public keys. 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. 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. 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 last lecture's 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). 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? Certificates play a big role in differentiating 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. Often, this fails, for technical & social reasons, leading to phishing. 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. But, cryptography is rarely the weakest part of a system. 2. Authenticating the server. Certificates can be relatively easy to obtain. Many years ago, used to require a faxed request on company letterhead. 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 trusted certificate authorities in most browsers. SSL implementations have bugs in verifying certificate names. 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. 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