543755 - Support pref restricting cookies to https-only

Status: NEW

(Core :: Permission Manager, enhancement, P3)

Description

[Anthony Howe]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729)

Consider http://twitter.com and https://twitter.com and the "Remember Me" check box (common for web mail sites too).

I want to be able to block twitter HTTP sent cookies and only allow HTTPS sent cookies for a site. I've notice that if Firefox remembers a session/login cookie sent via HTTPS, it appears to send it back via HTTP equally, since its the web site that specifies the cookie security attribute or not, not the web browser.

If I can block HTTP based cookies and let the HTTPS through, then I can avoid accidentally logging in over an unsecured connection, particularly when Twitter or similar site send you New Follower Email notices with unsecured links to the follower's profile.

Consider following attack:

1. Victim using WiFi in bar/cafe using twitter over HTTPS.
2. Attacker sees screen name over shoulder of victim.
3. Attacker signs into twitter and follows victim.
4. Victim gets New Follower mail and clicks on unsecure HTTP link of new follower.
5. Attacker can now sniff unsecured HTTP traffic on WiFi and obtain twitter login and/or session details.

Simple solution would of course be that twitter and other sites use HTTPS links and specify the cookie secure attribute but they don't. Firefox could help reduce this risk by providing the user a means to restrict cookies based on the connection type at users request.

Reproducible: Always

Comment 1

[Mike Connor [:mconnor]]

The short version is that the permission is domain-based.  It would be technically possible to add an additional bit for cookie permissions, whether that makes sense or not, separate from a forceHTTPS impl, I don't know, but punting over to the right component.

Comment 2

[[e-mail]]

We'd want a permissionmanager bit for this, so you can enter a site into permissionmanager and say 'cookies for this site are https-only'. We can't just flip the 'secure' bit on cookies, sadly, because that's an irreversible action unlike having an entry in a permission list.

Comment 3

[Anthony Howe]

Elaborate please. Why is flipping the cookie secure bit irreversible? Cookies are just text and that can be edited. (Always thought a cookie editor in firefox would be nice.)

Comment 4

[[e-mail]]

I meant thermodynamically irreversible, as in loss of information. One cannot say "make this site's cookie secure", undo that decision, and have the 'secure' bits go back to the way they were. Which would be bad.

Comment 5

[Jesse Ruderman]

I think you want HSTS or the HTTPS Everywhere add-on.  Managing per-site permissions for cookies only does not seem like the best way to protect yourself.

For Twitter in particular, you're already safe because Twitter sends the HSTS header:
"Strict-Transport-Security: max-age=631138519".

Comment 6

[Anthony Howe]

I already use HTTPS Everywhere and it only changes HTTP to HTTPS where possible. It does not affect cookies. 

The issue I have is that if you block HTTP cookies, you also end up blocking cookies for the "Secure" attribute; http://tools.ietf.org/html/rfc6265#section-5.2.5 , http://tools.ietf.org/html/rfc6265#section-4.1 since the blocking currently does not distinguish between plain and secure cookies for HTTP and HTTPS connections.

Off the top of my head, you essentially want some finer granularity of cookie blocking choices, like:

a) block all cookies regardless of HTTP/HTTPS (current model)
b) block all cookies over HTTP, but allow over HTTPS
c) block all cookies over HTTPS, unless "Secure" attribute set.

Comment 7

[Jesse Ruderman]

HSTS affects cookies indirectly, by preventing any connections over HTTP.

Comment 8

[Anthony Howe]

Hmm. I'm not familiar with HSTS, but at the time I submitted this bug, Twitter wdid not appear to use HSTS. Regardless, it the issue appears very applicable with sites that don't support HSTS and those that apply a mix of plain and HSTS for different areas/hosts/sites of a domain.

Comment 9

[Bob Clary [:bc] (inactive)]

Considering the eavesdropping going on, it would be nice to be able to block any non secure cookies. This might also help reduce tracking of people using advertising cookies.

Comment 10

[Ralf Hauser]

Agreed, since many sites to not use HSTS yet and preloading hsts hosts (http://blog.mozilla.org/security/2012/11/01/preloading-hsts/) is not commonly done, this is a very important feature.
http://www.wired.com/opinion/2013/11/this-is-how-the-internet-backbone-has-been-turned-into-a-weapon/ explains nicely, how non-https cookies can be used to identify a firefox user surfing e.g. through TOR ...

Comment 11

[Ralf Hauser]

to protect against "quantum" attacks, this should be combined with better control on HTTP 302 redirects bug 951685

Comment 13

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 14

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 15

[Julian Gaibler]

(In reply to Anthony Howe from comment #6)

I already use HTTPS Everywhere and it only changes HTTP to HTTPS where
possible. It does not affect cookies.

I think HTTPS Everywhere is upgrading all insecure cookies now. Might be a nice alternative to blocking.