534065 - Use Strict-Transport-Security headers to force HTTPS access

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: Code Quality, enhancement, P5)

Description

[James Socol [:jsocol, :james]]

As AMO content is served over HTTPS, AMO should send a Strict-Transport-Security[1] header on HTTPS responses. This tells complying UAs (Firefox with the ForceTLS[2] or NoScript add-ons, potentially Firefox natively and other UAs soon) to always make requests over HTTPS, and avoid the HTTP->HTTPS redirect that is potentially subject to MITM attacks.

The header should look something like:
Strict-Transport-Security: max-age=###
where ### is a delta-seconds, high enough that most people will visit AMO before the expiry date.

Marking this security for now, please feel free to clear that if it's inappropriate.

1. http://lists.w3.org/Archives/Public/www-archive/2009Sep/att-0051/draft-hodges-strict-transport-sec-05.plain.html
2. https://addons.mozilla.org/en-US/firefox/addon/12714

Comment 1

[Reed Loden [:reed]]

I don't consider this an active security issue that could be exploited, so I think clearing the security flag on this would be appropriate.

Comment 2

[Wil Clouser [:clouserw]]

Can do this w/ zamboni.  Are there recommended values of max-age?  Maybe 30 days?  I don't think we should use the subdomain flag, instead opting in for each subdomain if that's what we want.  There may be a case where we want plain text, e.g. static.amo.

Comment 3

[James Socol [:jsocol, :james]]

The suggestion I got was double the approximate maximum time between visits. I doubt that data is available, so maybe 30 or 60 days. max-age is probably a 32-bit unsigned integer (waiting on spec clarification) for what that's worth.

Comment 4

[Daniel Veditz [:dveditz]]

There's no harm in having an over-long max-age unless you seriously consider making the site. The original proposal didn't even have an expire time, it was left up to the user agent to provide some way for users to manually clear the setting should a site make such a change and otherwise it was permanent. Note that the server can reduce the expiry time--possibly to 0--at any future visit (in the current spec; this was a debated point). Go ahead and make it a couple of years, and if at any point we start talking about introducing non-SSL portions of the site we can switch to a shorter time frame while we plan and then eventually drop it altogether.

You won't get a definition of a type for max-age since it's defined in terms of previous specs which also don't say. It'll be implementation independent but a signed 32-bit int is a safe minimum bet, but hopefully most implementations will use at least unsigned if not eventually 64-bit.

I wouldn't use the subordinate domain flag. PayPal wanted that, but even if that directive didn't exist it could be forced by having parent domain pages include resources from the subdomain, allowing it to set its own state.

Comment 5

[Wil Clouser [:clouserw]]

James:  This is a good candidate for commonware, similar to x-frame-options.  If you make a patch, I'll turn it on. :)

Comment 6

[Michael Coates [:mcoates] (acct no longer active)]

I'd like to bring this bug back to life.  With STS support in FF4.0 we should get this into AMO.

ETA?

Comment 7

[Michael Coates [:mcoates] (acct no longer active)]

Wil, James: Ping?

Is more work needed for this to happen or do we just need to schedule a push?

Comment 8

[James Socol [:jsocol, :james]]

I'll patch commonware this afternoon and add support.

Comment 9

[James Socol [:jsocol, :james]]

https://github.com/jsocol/commonware/compare/d77e5188%5E%5E...58948b4%5E

Support in commonware.

Comment 10

[Michael Coates [:mcoates] (acct no longer active)]

Clouser,

Can we pull this into AMO and enable?  There are no repercussion for older browsers that don't support STS. It is an added layer of security for those that do.

Comment 11

[Wil Clouser [:clouserw]]

Yeah, I put it on trunk yesterday.  I didn't realize this bug was AMO specific.  -> fixed

Comment 12

[Wil Clouser [:clouserw]]

Also, for the record, I'm curious what the behavior is if/when a site switches to non ssl (I'm thinking of dev sites).

This feature isn't activated until the first time the request goes over SSL so our dev sites aren't affected right now, but do you know if there is a way to reset this in the browser?

Comment 13

[Michael Coates [:mcoates] (acct no longer active)]

(In reply to comment #12)
> Also, for the record, I'm curious what the behavior is if/when a site
> switches to non ssl (I'm thinking of dev sites).
> 
> This feature isn't activated until the first time the request goes over SSL
> so our dev sites aren't affected right now, but do you know if there is a
> way to reset this in the browser?

The browser will not send a HTTP request until the STS_MAX_AGE has expired. So if a site switches to just HTTP and has already set the STS header with all users, the site will be unavailable to these users until STS_MAX_AGE expires.

But, that is an odd scenario.  The header is set to the domain, so we can easily set it for specific prod or dev sites as needed.

I do not know of any easy way to reset the STS flag within the browser.  One possible way is to use a proxy (with a cert that has been added to the browser's root store), intercept a response to the browser and manually change the STS_MAX_AGE to 1 (so it immediately expires).

Comment 14

[Wil Clouser [:clouserw]]

Ugh, probably easier to write an add-on at that point :-P