SSL === TA office hours for lab 3 today and friday quiz will be graded by next lecture couple of students haven't taken it due to absence.. SSL background want to use crypto to prevent network attacks public-key crypto: pair of keys (public, private) and encrypt/decrypt funcs server has a priv key, client will encrypt message for the server's pub key how does the client know the server's public key? certificates signed by someone you trust often a certificate authority like Verisign includes server's name and server's public key client certs: signed message from someone trusted, this time by server how to prove client is the party described in the client cert? client cert says what the client's public key is when you generate an MIT client cert, your browser picks priv key sends the corresponding pub key to MIT's CA, which signs the cert so noone but you (really your browser) ever sees the private key challenge-response scheme to verify client has the private key most protocols (incl. SSL) derive a symmetric key, use it for session data how does the browser integrate with SSL? lock icon indicates you are viewing a page encrypted with SSL (https://...) rules for when the lock icon appears: - certificate is valid - certificate issued by a trusted CA - certificate name matches domain in URL - (most of) page components loaded via HTTPS how secure are server certificates? in practice hard to verify if you're talking to owner of some web server used to be, you had to fax a request on company letterhead now largely requires the ability to receive mail for domain's admin contact a while back, attackers convinced a CA to issue cert for microsoft EV certs try to tie certs to names users know (PayPal Inc; Microsoft Corp; ...) perhaps avoids confusing names (paypa1.com) unclear if it's worth the effort (will user know if EV cert is missing?) certificate null encoding bug certificate encodes the name of the web server as an ASN-1 string encoding format: length, followed by that many bytes how does a CA work? allow a domain owner to get certs for *.domain.com attacker asks the CA to issue a cert for www.paypal.com\0foo.domain.com some SSL libraries simply decode string into a memory array C implementation treats resulting string as equivalent to www.paypal.com CA might not have noticed because they were running Java certificate revocation CRL include known-compromised certs in a "bulletin" of some kind idea is that users would download it periodically to protect themselves in practice, noone bothered, infrequently-used mechanism OCSP try to check certificate freshness online don't need to do this on every HTTP request can cache results for certs we've seen recently client sends a list of certs that it wants to verify server responds with server status, set of certIDs + certStatus'es, plus signature over the certID/certStatus sequence protocol didn't sign the server status! what's the paper's goal? suppose SSL really works the way it was intended i.e., provides a guarantee you have a confidential channel to named server assume a network attacker (e.g. you connect to an open wireless network) how hard is it to build secure web sites on top of this abstraction? problem: attacker gets to control all of your non-SSL connections non-SSL sites have some influence over supposedly-SSL sites what are possible attack vectors? HTTPS-protected page using content from non-HTTPS origins e.g. using SCRIPT SRC= to load some popular javascript library or use CSS style sheets from a non-HTTPS URL browsers often ask "Page contains secure & non-secure items" users almost always allow the non-HTTPS items to be loaded trick the user into accepting an invalid server certificate exploit poor cookie management schemes HTTP cookies many sites use HTTPS to protect the user's password e.g. when you log into your google/gmail acct: site checks for cookie, doesn't find it redirects user to https://www.google.com/accounts/login/ that site gets user's username/password, checks it if OK, issues a cookie for .google.com with username in it simple cookie attack: sniff cookies for non-SSL connections attacker reuses the cookie to make other requests to, e.g., gmail what if the user is careful to always visit https://mail.google.com? site might use same cookie to identify the user to any google.com server if user visits any non-SSL google.com URL, cookie sent in the clear what if user always uses HTTPS google.com URLs? still vulnerable if user visits any other non-HTTPS site attacker can intercept connection, redirect to http://mail.google.com what if user never visits any other sites? gmail uses XMLHttpRequest to perform operations initially tried to use HTTPS, but fell back to HTTP if HTTPS fails! network attacker can easily cause the HTTPS request to fail protection mechanism: "Secure" cookies cookie can be marked as "Secure" by server; only sent via HTTPS connections what if user modifies the browser to mark gmail cookies as "Secure"? slight complication with the way google manages its cookies there's actually a few different cookies in question google has separate cookies for different services (e.g. gmail) can view some gmail information with a non-gmail google cookie login service has its own cookie remembering your info will issue new cookies on request might ask for password again, e.g. for search history problem is, google's login service will issue fresh cookies on request login service keeps its own cookie to remember logged-in user attacker can ask login service to issue a fresh cookie for non-SSL gmail works by redirecting to http://mail.google.com/?..new-cookie-data.. even if you mark your gmail cookie as secure, this login service will issue new ones, perhaps over HTTP! for more details, see: http://blog.icir.org/2008/02/sidejacking-forced-sidejacking-and.html how to defend? user can try to only visit HTTPS pages, but can't prevent shared cookies or sites that can be tricked into revealing cookies over HTTP site can mark cookie as Secure, but cannot prevent user accepting bad certs how did forcehttps work? - make SSL misconfiguration warnings into an error don't ask the user, assume the worst, because site says it should work - disallow non-HTTPS content to protect against http javascript or css - mark cookies as "Secure" server-based forcehttps site issues a cookie called "ForceHTTPS" which enables forcehttps for site interesting problems with cookie-based impl: space exhaustion browsers don't guarantee how long a cookie stays around for if attacker sets many cookies, browser can evict some existing cookies no guarantee that all cookies for a site are evicted at once so browser might evict the forcehttps cookie before the real cookies then attacker tries to mount one of the above attacks! denial of service on other sites attacker can break web sites by setting the forcehttps cookie on them have a special policy for when to accept a forcehttps cookie forcehttps cookies specific to a particular server, not an entire domain user-based forcehttps specify which cookies should be forced to be "Secure" specify URL rewriting rules (both convenience and prevent sites like google's login service from sending sensitive arguments to non-HTTPS URLs in the query string) using forcehttps on gmail was a bit annoying your authentication cookie was only sent via SSL (good) means that you can only access google sites that require auth via SSL but some sites don't accept SSL (google maps, or search, for later history) since this paper, google fixed gmail "only use SSL" checkbox to prevents google from issuing non-SSL gmail cookie what doesn't forcehttps protect from? XSS, CSRF HTTP response-splitting attacks sort-of like cross-site scripting, but on HTTP headers attackers inject CR LF into something (e.g. cookie sent back by server) can specify new headers, e.g. arbitrary other cookies can specify the complete response body (after CR LF CR LF) can specify the entire response to next request (with HTTP pipelining) very bad on a proxy/cache server: next req may be for another server! another possible fix to the same problem: use client certs when you log into a web site like gmail, you get a client cert back expiration times would be short like cookies web browser would automatically present client cert when making a connection certs avoid MITM or credential-stealing attacks like with cookies why not? browser cert mechanism not well-specified, so each browser is different not designed for short-term or programmatically-issued/requested certs requires a lot of user intervention for each certificate operation