User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.17) Gecko/20110302 Iceape/2.0.12 Build Identifier: Web sites are gradually learning that HTTPS is necessary for the secure deployment of any account-based service. However, many websites (Twitter is currently a random example) offer HTTPS but do not set the "secure" flag in their authentication cookies. That means that a network attacker (like Firesheep combined with a malicious website, or like Firesheep but with the addition of an easy-to-implement active attack) can steal the user's authentication cookies and hijack their account simply by causing the browser to GET something from the http:// version of the victim domain. The network attacker will get the cookie before the webserver ever has a chance to respond/redirect the user to HTTPS. There are solutions to this, of course: set the secure flag in all authentication cookies, or better, enable HSTS since that also protects against SSL stripping attacks. The web browser needs to indicate to users (and web developers) if these security problems exist in HTTPS websites. Break the lock icon, change the colour of the address bar, cross out the "https", whatever is considered fashionable these days. An HTTPS website with insecure cookies is not really secure. Reproducible: Always

A couple of other vulnerability scenarios I should have mentioned: - Firesheep plus *any* link to http://victim.domain.com that the victim might follow on the public web - Firesheep plus the user naively typing "victim.domain.com" into the addressbar. So to be clear, Firesheep does not need to be modified for it to be considered a ubiquitous exploit against this vulnerability.

One additional vulnerability scenario that is important to point out, as it's incredibly prevalent: A user browses any number of sites which embed content from sites in question which do not mark their cookies as secure: E.g. the Facebook "Like" buttons, Twitter "Tweet" buttons, site badges, etc - any resource retrieved from the same domain over HTTP. These are difficult to avoid without the user being proactive (e.g. HTTPS-Everywhere) and inherently leak your authentication cookies. For example, the Facebook "Like" button is language-dependent and will change based on your account settings. See screenshot in the original Firesheep presentation for an example of these type of resources included in a Techcrunch article: http://codebutler.github.com/firesheep/tc12/#16

Adam Langley asked me the following important question: How is a browser to know which cookies are sensitive? Do you suggest that all cookies on an HTTPS site must be marked 'secure'? Here is a first draft heuristic answer: If the user logs in (username/password submission), and the resulting page load (including redirects) is complete, and the user has cookies from this domain, and none of them are marked secure, trigger the UI change. Under this heuristic, if the web developers have demonstrated that they know about the existence of the secure cookie flag, we will rely on them to mark their authentication cookies with it.

If we use the "mixed content" lock icon, we need a line item in the Page Info window explaining the cookie situation (whether there are secure cookies and whether there are insecure cookies). The heuristic seems about right to avoid triggering false positives, but it's complicated, making me wonder if we should just do the Page Info line item without the lock icon change.

What to show for pages that use both http and https and keep a state/option in non-secure cookies? I think to show broken-security UI is a bit overreaction for this case. Do we have any stats how often there are non-secure cookies used on secured pages that doesn't contain any login/account info? If it is even possible to have such a stat.

(In reply to comment #5) > What to show for pages that use both http and https and keep a state/option in > non-secure cookies? I think to show broken-security UI is a bit overreaction > for this case. I gather you mean pages that are available over *either* http or https, not pages with mixed http/https content ;) > Do we have any stats how often there are non-secure cookies used on secured > pages that doesn't contain any login/account info? If it is even possible to > have such a stat. Why would these pages be affected by the heuristic I proposed in comment 3? If the user hasn't logged in, then the heuristic won't have been triggered.

The "mixed content" lock icon has been removed in Firefox 4. There is no longer any lock icon by default. There is no longer a warning icon that represents the state "mixed content". What happens in Firefox 4 is, you no longer get the SSL indicators (no blue, no green). It is detable whether users notice the missing color and realize something's wrong. Does this bug still make sense with "mixed content indicators" having gone away? Do you propose to add it back? Do you think "missing color" is sufficient?

I think we should make sure "uses cookies without the secure flag" is one of the things that can make sure a site is displayed as "mixed content". Whether it's a cross-out lock or removal of SSL color, the lack of secure flag should trigger it.

I think this is a bit extreme. Lots of sites (twitter, facebook, yahoo, google etc) are going to have non-secure cookies. They serve personalized content on both http and https sites, and hence need to know who are through your non-secure cookies. Unless we see sites shift to full ssl experiences (instead of just protecting their most important pages), most of the once-ssl web will become mixed content. I think it does make sense to expect secure cookies on a domain that has set an STS header for itself and its subdomains. In that case, there is no reason you would be visiting that site on http and hence no reason to have non-secure cookies. But I don't see how this enforcement will really add any security for the user, since their cookies are only sent for that domain which is only accessed via https.

(In reply to Tanvi Vyas from comment #9) > I think this is a bit extreme. Lots of sites (twitter, facebook, yahoo, google etc) are going to have non-secure cookies. Three of those four sites have a mixture of secure and non-secure cookies, and would therefore pass the heuristic I proposed in Comment 3. Last time I checked, Yahoo! had nothing even remotely resembling a secure HTTPS deployment, and users should be warned about that (or at least, never be given the reassuring blue/green glow).

(In reply to Tanvi Vyas from comment #9) > I think it does make sense to expect secure cookies on a domain that has set > an STS header for itself and its subdomains. Also, this is exactly backwards. If the STS header is set, secure cookie flags are no longer necessary.

(In reply to Peter Eckersley from comment #10) > (In reply to Tanvi Vyas from comment #9) > > I think this is a bit extreme. Lots of sites (twitter, facebook, yahoo, google etc) are going to have non-secure cookies. > > Three of those four sites have a mixture of secure and non-secure cookies, > and would therefore pass the heuristic I proposed in Comment 3. Last time I > checked, Yahoo! had nothing even remotely resembling a secure HTTPS > deployment, and users should be warned about that (or at least, never be > given the reassuring blue/green glow). Ah, okay I see. The heuristic in comment 3 says that if at least one of the cookies is marked secure, then the site is okay. Yahoo also has a secure cookie. But just because a site has both secure and non-secure cookies doesn't mean that all the authentication cookies will be marked as secure. I can login to facebook/linkedin/yahoo/twitter, get back a secure cookie, and then get an authenticated user experience on their non-ssl pages. This implies there authentication cookies are not secure.

That's rig > But just because a site has both secure and non-secure cookies doesn't mean > that all the authentication cookies will be marked as secure. I can login > to facebook/linkedin/yahoo/twitter, get back a secure cookie, and then get > an authenticated user experience on their non-ssl pages. This implies there > authentication cookies are not secure. That's right; the heuristic is imperfect. The best test is to delete all of the secure cookies while keeping the non-secure ones, load pages from the website, and check that you are no longer logged in. But because that's not really feasible to do in the browser in real time, the heuristic makes the assumption that if website admins are sufficiently informed to know about the existence of the secure flag, they have a decent chance of using it correctly. This is in contrast to 90%+ of HTTPS sites with logins, which use neither the secure flag nor HSTS, and therefore cannot possibly be offering secure logins.

This is a decision front-end needs to make.