Certificates ============ Paper: "SoK: SSL and HTTPs: Revisiting past challenges and evaluating certificate trust model enhancements" by Clark and van Oorschot Today: Certificates Bind PK_S to server's identity (principal name) Crucial part of secure channels Avoid "Man-in-the-middle attack" during handshake Case study: HTTPS HTTP over SSL plus certs, etc. Hard to well in practice Paper documents this well Recall sketch handshake with certificates C --> S: connect C <-- S: PK_S, Sign(SK_CA, {server: PK_S}) C --> S: Encrypt(PK_S, freshKey) C <-> S: Encrypt(freshKey, m...) Certificate authority Trusted principal who mints certificates Maintains table of (principal name, public key) pairs Authority server signs a certificate Sign(SK_CA, {server, PK_server}) Client can verify that it's correctly signed by PK_CA Adversary would not be able to provide such a certificate for adversary's PK_S Certificate can easily be distributed Could query server, but that's bad for availability, performance Instead, a server obtains a certificate and sends it to client Need to know the authority server's public key to bootstrap all this Certificate Principal name is typically the server's DNS name Choice of name must capture the client's intended communication target Crucial that the name is correct! Need to worry about typos, look-alikes Principal name of certificate authority Expiration time ... Example certificate: X.509 structure certificate version serial_number signature_cipher_identifier issuer_signature issuer_name subject_name subject_public_key_cipher_identifier subject_public_key validity_period [Show in browser, symantec.com, MIT, CSAIL] Certificate authorities in Web Symantec, Comodo, GoDaddy, etc. How to find public key? Baked into browser How to get browser securely? Challenge: Bootstrapping CA database Important to have high confidence end-to-end Current CAs have a mix of approaches: Email verification Domain ownership verification Require faxed document on company letterhead ... Design choice is application- and threat-specific Challenge: Validating certificate Browser Human involved Check lock, address bar Users don't check for lock icon Users don't carefully check domain name, don't know what to look for E.g., typo domains (paypa1.com), unicode Domain name doesn't mean anything to user [show https://badssl.com/] EV (Extended Validation) certificates. In addition to URL, embed the company name (e.g., "PayPal, Inc.") Typically shows up as a green box next to the URL bar. Why would this be more secure? When would it actually improve security? What's the risk of a user accepting an invalid certificate? Might be benign (server configuration error) expired cert, server operator forgot to renew or doesn't want to pay browsers allow users to override mismatched certificate historically: 60% of bypass buttons shown by Chrome are clicked through. hard for developers to exactly know what certs will be accepted by browsers Might be a man-in-the-middle attack, connecting to adversary's server. MITM attack Why is this bad? User's browser will send user's cookies to the adversary. User might enter sensitive data into adversary's website. User might assume data on the page is coming from the right site. Today browser's make it more difficult to ignore certification errors Try to take human out of deciding if cert is valid. What happens if adversary tampers with DNS records? Good news: security doesn't depend on DNS. Wrong server will not know correct private key matching certificate. 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. There are 100's of trusted certificate authorities in most browsers. Clients typically accept certificate for any name from any of the CAs Security depends on the policy of least secure certificate authority. Several CA compromises in 2011 (certs for gmail, facebook, ..) [ Ref: http://dankaminsky.com/2011/08/31/notnotar/ ] Paper mentions Syria No solution, but more defense in depth developments Server side Browser side Server-side developments Let's Encrypt CA. Automates issuance of certificates. Reduces barrier for server operators to get proper certificates. Certificate Transparency Public, certified log Google require entry in log for new EV Certs DANE tighter integration between DNS and HTTPS returns X.509 cert, signed with DNSSEC cert lists who can sign domain Browser-side development Key pinning Only accept certificates signed by per-site whitelist of CAs. Remove reliance on least secure CA Currently a hard-coded list of sites in Chrome. Diginotar compromise caught in 2011 because of key pinning. Plans to add mechanism for sites to advertise pins. [ Ref: http://tools.ietf.org/html/draft-ietf-websec-key-pinning-21 ] [ Ref: http://tack.io/ ] Blacklist weak crypto Browsers are rejecting MD5, SHA1 hashes; RSA keys with < 1024 bits. Challenge with certificates: revocation What if the authority server wants to delete an entry from the table? E.g., principal name no longer valid (domain name expired and reused) E.g., adversary broke into server and obtained SK_S Signed messages remain valid Old domain owner can continue to pretend to be the server's principal Adversary can pretend to be the server's principal Checking certificate status with CA on every request is hard to scale. Revocation solutions Certificates have expiration dates. Certificate Revocation List (CRL) published by some CA's, but relatively few certificates in them (spot-checking: most have zero revoked certs). Chrome has CRL 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. Easy to overwhelm CA; so, "try later" message Fail or succeed on "try later" response? One issue: OCSP protocol didn't require signing "try later" messages. [ Ref: http://www.thoughtcrime.org/papers/ocsp-attack.pdf ] OCSP stapling OCSP responses are signed by CA. Server sends OCSP response in handshake instead of querying online Effectively a short-lived certificate. Problems: - Not widely deployed. - Only possible to staple one OCSP response. Community efforts for validating certificates 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. [ Ref: https://www.imperialviolet.org/2011/03/18/revocation.html ] In practice browsers push updates with blacklist after major breaches. [ Ref: https://www.imperialviolet.org/2012/02/05/crlsets.html ] Challenge: users directly entering credentials Phishing attacks Users don't check for lock icon, etc. Web developers put login forms on HTTP pages (target login script is HTTPS). Adversary can modify login form to point to another URL. Login form not protected from tampering, user has no way to tell SSL stripping HTTP Strict-Transport-Security header [ Ref: http://tools.ietf.org/html/rfc6797 ] [ Ref: http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security ] Turns HTTP links into HTTPS links. Prohibits user from overriding SSL/TLS errors (e.g., bad certificate). Cryptographic keys as credentials Strong credential (stronger than passwords, biometrics) Used as computer-to-computer authentication rather than human-to-computer Can allow limiting the scope of human-to-computer authentication A version of this in certificates Server public key authenticates server principal U2F protocol (See lec 3) Summary HTTPS and CAs work reasonably well Attack focus on certs means other security mechanisms are working well Despite challenges, certs raise bar for attackers Many practical challenges Other references: http://www.imperialviolet.org/2012/07/19/hope9talk.html