660904 - Send HSTS header to logged-in users

Status: RESOLVED FIXED

(support.mozilla.org :: General, defect)

Description

[Jesse Ruderman]

I keep ending up at http pages such as http://support.mozilla.com/en-US/kb/High%20memory%20usage and being unable to edit them as a result.  This is extremely confusing.

(I guess this means the fix for bug 483026 isn't working for me...)

SUMO should send HSTS headers to logged-in users to ensure they don't accidentally connect over http.

Comment 1

[Erik Rose [:erik][:erikrose]]

Also, we shouldn't link folks to http:// from the https:// side. Are we doing that anywhere?

Comment 2

[James Socol [:jsocol, :james]]

HSTS is not appropriate for this situation: just because a user logged in once should not keep them on HTTPS forever on SUMO. We've implemented bug 620910 but it only shipped yesterday afternoon.

Comment 3

[Sid Stamm [:geekboy or :sstamm]]

(In reply to comment #2)
> HSTS is not appropriate for this situation

I don't understand why it's inappropriate.  HSTS ensures users don't get login credentials stolen, and the users who have logged in once are precisely the ones who are likely to do it again.  Server-side redirects (bug 620910) are helpful, but only if the network is trustworthy (which is precisely the opposite of what HSTS defends against: the case when attackers use firesheep or other credential-stealing MITM attacks).

Comment 4

[Jesse Ruderman]

Server-side redirects are also slower.

Comment 5

[James Socol [:jsocol, :james]]

As Erik said, we shouldn't be sending people to HTTP from HTTPS. This is just to catch weird cases like opening a link from someone else. There's no reason why someone who has logged in once should always come back to HTTPS, so at most we'd want to set HSTS on login and for a very short window, maybe a day.

Comment 6

[Jesse Ruderman]

I found myself at http URLs after doing Google searches and navigating using the awesomebar. I don't think those are "weird cases".

Comment 7

[James Socol [:jsocol, :james]]

And you were currently logged in if you switched it to HTTPS?

Comment 8

[Jesse Ruderman]

I don't understand your question.

Things seem better now that bug 620910 is fixed. The brokenness is gone, leaving only the minor speed and security problems.

Comment 9

[James Socol [:jsocol, :james]]

Given that we're now not expiring sessions at browser close, this makes more sense. It depends on commonware issue #5: https://github.com/jsocol/commonware/issues/5.

Comment 10

[Ricky Rosario [:rrosario, :r1cky]]

Cleaning up 2011Q4

Comment 11

[Frederik Braun [:freddy]]

Marking this as a blocker for the next-SuMO (kitsune) security review. Why send HSTS to only logged-in users?

Comment 12

[James Socol [:jsocol, :james]]

(In reply to Frederik Braun [:freddyb] from comment #11)
> Marking this as a blocker for the next-SuMO (kitsune) security review. Why
> send HSTS to only logged-in users?

Because almost all of our unauthenticated traffic is HTTP, and that is tightly coupled to our performance/caching strategy.

For practical purposes, logged-in (or logging in) <=> on HTTPS.

Comment 13

[Ricky Rosario [:rrosario, :r1cky]]

I did this as part of Bug 840966