1119555 - Throw away leftover HTTP data for HSTS sites

Status: NEW

(Core :: Security, defect)

Description

[Tanvi Vyas[:tanvi]]

When sites transition to HSTS, the data associated with the sites legacy HTTP entrypoint is no longer needed.  An attacker can use a MITM attack to extract the HTTP data from the browser (ex: passwords, cookies).  To prevent this, the browser should expire and throw away this data.

If a domain is marked HSTS and the browser stores the password for the HTTP entrypoint of that domain, throw away that password.

If a domain is marked HSTS and the browser stores cookies for that domain, mark them secure.

One concern with this proposal is recovery.  If a site switches to HSTS and later switches back, the stored HTTP data for that domain will no longer exist.  Hence, we should only do this for sites that have been HSTS for a certain length of time (perhaps 8 weeks?).  We can use our preload list to help determine this.

Thoughts?

Comment 1

[Jesse Ruderman]

As much data as possible should be migrated from http to https, rather than discarded. We don't want to punish sites for adopting https. This is especially important for saved passwords (see also bug 986609).

I wouldn't worry about "what if the site switches back?". The likelihood of a site adding HSTS and then quickly abandoning HTTPS altogether is low. And the data isn't gone, it's just associated with the wrong origin, similar to the problems when a startup changes its domain name.

Comment 2

[Tanvi Vyas[:tanvi]]

See also https://bugzilla.mozilla.org/show_bug.cgi?id=667233#c20

(In reply to Daniel Veditz [:dveditz] from comment #20)
> If we do use the saved insecure password do we upgrade its origin to https?
> If the site has really switched then having the password still saved for
> http could leave those users vulnerable to an sslstrip-type attack That's
> especially true if we continue to autofill without user action, but even if
> user interaction is required the fact that we remember the password would
> lend believability to the phish. Do we create a new https entry? Do we
> simply leave the data as-is and take the upgrade path forever (and if we do,
> would we handle future password change forms correctly?)