Last modified: 2014-11-21 00:43:24 UTC
[[HTTP Strict Transport Security]] tells a user's browser to load all resources for a website over HTTPS, even if the resources are referenced with an "http://" URI. More information at http://www.imperialviolet.org/2012/07/19/hope9talk.html
I think you'd do this at the Squid level. The Squid configuration is in Wikimedia's git repo somewhere...
CC-ing Ryan Lane. Note that until the SSL cluster is expanded and more stable, this must *not* happen at the Squid level, or any other level for that matter. Right now the plan (afaik) is: * Keep testing and allow natural usage increase by word of mouth * Increase SSL cluster * Enable for logged-in users by default * .... * ... * Enable for everybody by default (?) * ... (?) * Increase SSL cluster ++ ++ ++ * Send HSTS and thus force all modern browsers to use HTTPS unconditionally. This would probably require most servers to have SSL on them internally, instead of the current situation in which we have a couple of SSL proxies that fetch from the protocol-relative (HTTP) squids.
We can turn it on by default for logged-in users right now. We can easily handle that load. To enable it for all users we'd need to expand the cluster so that every squid/varnish node is also an HTTPS node. That would be a requirement for HSTS. Indeed HSTS is the last in the chain for this. Also, it isn't necessary for squid/varnish to send these headers. It would actually be nice if MediaWiki handled this, since then anyone could enable it.
(In reply to comment #3) > We can turn it on by default for logged-in users right now. We can easily > handle that load. > You should realize that that means that once a browser is used by a logged-in user *once*, it will use HTTPS for *everyone* *forever* (really until the STS header expires, usually that's a year), even if they're not logged in. So in practice that means that every shared computer (libraries, internet cafes) in the world is gonna be hitting us exclusively via HTTPS within a few days of deploying this change. This is not necessarily a huge problem, but I just wanted to point this out. Also, STS forbids accepting invalid certs, and we're currently serving wrong certs for domains like wikipedia.com and wikidata.org; essentially all the misc domains we have are sent to wikimedia-lb, which means they get the star-wikimedia cert, which is bad. Serving STS fro those domains would be deadly. > To enable it for all users we'd need to expand the cluster so that every > squid/varnish node is also an HTTPS node. That would be a requirement for HSTS. > Indeed HSTS is the last in the chain for this. > Why is Squid/Varnish-side SSL termination required for STS? Why can't we just scale up our current nginx cluster? > Also, it isn't necessary for squid/varnish to send these headers. It would > actually be nice if MediaWiki handled this, since then anyone could enable it. Yes, MW should send these headers.
(In reply to comment #4) > (In reply to comment #3) > > We can turn it on by default for logged-in users right now. We can easily > > handle that load. > > > You should realize that that means that once a browser is used by a logged-in > user *once*, it will use HTTPS for *everyone* *forever* (really until the STS > header expires, usually that's a year), even if they're not logged in. So in > practice that means that every shared computer (libraries, internet cafes) in > the world is gonna be hitting us exclusively via HTTPS within a few days of > deploying this change. > > This is not necessarily a huge problem, but I just wanted to point this out. > Sorry, sorry. I meant send all logged-in traffic to https, not use HSTS. > Also, STS forbids accepting invalid certs, and we're currently serving wrong > certs for domains like wikipedia.com and wikidata.org; essentially all the misc > domains we have are sent to wikimedia-lb, which means they get the > star-wikimedia cert, which is bad. Serving STS fro those domains would be > deadly. > Eh? Since when are we serving incorrect certificates? Do you mean for mobile? > > To enable it for all users we'd need to expand the cluster so that every > > squid/varnish node is also an HTTPS node. That would be a requirement for HSTS. > > Indeed HSTS is the last in the chain for this. > > > Why is Squid/Varnish-side SSL termination required for STS? Why can't we just > scale up our current nginx cluster? > It makes more sense to just stick HTTPS on every box, than to have a separate cluster, if we're going to do HTTPS by default.
(In reply to comment #5) > Eh? Since when are we serving incorrect certificates? Do you mean for mobile? > https://wikipedia.com https://wikipedia.net https://wikidata.org > It makes more sense to just stick HTTPS on every box, than to have a separate > cluster, if we're going to do HTTPS by default. Right, OK.
(In reply to comment #6) > (In reply to comment #5) > > Eh? Since when are we serving incorrect certificates? Do you mean for mobile? > > > https://wikipedia.com > https://wikipedia.net > https://wikidata.org > Ah. Those, yes. We only send redirects from there, so, MediaWiki wouldn't send headers from that.
Hi folks, Just wanted to say 1) this would be awesome and 2) it would be even more awesome if you could configure these sites to be on the HSTS preload lists currently in Firefox and Chrome. To do so, you simply need to have max-age be 10886400 or larger and contact Adam Langley as per http://dev.chromium.org/sts There's a bit more of an explanation here: https://blog.mozilla.org/security/2012/11/01/preloading-hsts/ Thanks!
Note that you can disable HSTS at any point by sending the header with an expiry that already expired (similar to how it's done with cookies). This is what Extension:SecureSessions does to implement HSTS in MediaWiki, and as long as Squid/Varnish allows MediaWiki to override the HSTS header it sends somehow, it should still be possible even with an HTML cache.
(In reply to comment #9) > Note that you can disable HSTS at any point by sending the header with an > expiry that already expired (similar to how it's done with cookies). This is > what Extension:SecureSessions does to implement HSTS in MediaWiki, and as > long > as Squid/Varnish allows MediaWiki to override the HSTS header it sends > somehow, > it should still be possible even with an HTML cache. Let's assume we need to turn off HSTS for a really great reason, like a country being blocked on HTTPS. How would those users get the expired header if they can't reach the site?
Adding bug 35313 and bug 36126 as blockers per comment 4 (how is there no tracking bug for invalid SSL certs?). I may be misunderstanding Roan's comment, though, so if invalid certs wouldn't actually be blockers for enabling HSTS, adjust as needed. =)
(In reply to comment #11) > Adding bug 35313 and bug 36126 as blockers per comment 4 (how is there no > tracking bug for invalid SSL certs?). I may be misunderstanding Roan's > comment, > though, so if invalid certs wouldn't actually be blockers for enabling HSTS, > adjust as needed. =) We're no longer serving invalid certs.
(In reply to comment #12) > We're no longer serving invalid certs. Okay, guess I should've actually read them. Sorry about that. =X
(In reply to comment #12) > We're no longer serving invalid certs. That may be the case for wikis, but it's still an issue for redirects like https://wikipedia.com and https://bugzilla.wikipedia.org/ .
(In reply to comment #10) > (In reply to comment #9) > > Note that you can disable HSTS at any point by sending the header with an > > expiry that already expired (similar to how it's done with cookies). This is > > what Extension:SecureSessions does to implement HSTS in MediaWiki, and as > > long > > as Squid/Varnish allows MediaWiki to override the HSTS header it sends > > somehow, > > it should still be possible even with an HTML cache. > > Let's assume we need to turn off HSTS for a really great reason, like a > country > being blocked on HTTPS. How would those users get the expired header if they > can't reach the site? I meant in reference to comment 4, which mentioned that if somebody uses it on a shared computer then it will use TLS for practically ever. We could make it so logging out causes HSTS to be disabled, although honestly it'd be better if we didn't now that I think about it...
(In reply to comment #10) > Let's assume we need to turn off HSTS for a really great reason, like a > country > being blocked on HTTPS. How would those users get the expired header if they > can't reach the site? They wouldn't be able to. They would have to manually clear the cached HSTS information (in Firefox, users can do this by using "Clear Recent History -> Site Preferences"). (In reply to comment #15) > I meant in reference to comment 4, which mentioned that if somebody uses it > on > a shared computer then it will use TLS for practically ever. We could make it > so logging out causes HSTS to be disabled, although honestly it'd be better > if > we didn't now that I think about it... The weak point of HSTS is the first connection. By doing this, there would be many more first connections for things to go wrong.
(In reply to comment #16) > (In reply to comment #10) > > Let's assume we need to turn off HSTS for a really great reason, like a > > country > > being blocked on HTTPS. How would those users get the expired header if they > > can't reach the site? > > They wouldn't be able to. They would have to manually clear the cached HSTS > information (in Firefox, users can do this by using "Clear Recent History -> > Site Preferences"). > https://bugzilla.mozilla.org/show_bug.cgi?id=572803
(In reply to comment #16) > The weak point of HSTS is the first connection. By doing this, there would be > many more first connections for things to go wrong. Yeah, this would be the main reason of why we would not want to do what I mentioned earlier. :/
Change 132393 had a related patch set uploaded by MZMcBride: Improve nginx TLS/SSL settings. https://gerrit.wikimedia.org/r/132393
I also wish Wikimedia to enable HSTS. How about we add it to Beta features [1], so that users can optionally enable HSTS? The feature description on that page can tell users how to remove HSTS record by deleting browsers' cache. I don't think it's necessary to disable HSTS when users log off, because shared computers are usually configured to clear all caches when browsers are closed. [1] https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-betafeatures
*** Bug 67303 has been marked as a duplicate of this bug. ***
bugzilla.wikimedia.org, wikitech.wikimedia.org and lists.wikimedia.org require HTTPS connections. Could we enable HSTS on these domains first?
Yes, enabling those first is fine. The patch for bugzilla is at https://gerrit.wikimedia.org/r/#/c/127256/ .
(In reply to fn84b from comment #22) > bugzilla.wikimedia.org, wikitech.wikimedia.org and lists.wikimedia.org > require HTTPS connections. Could we enable HSTS on these domains first? I made a table, which summarizes which domains require HTTPS: https://wikitech.wikimedia.org/wiki/User:Chmarkine/HTTPS There are many other domains besides these three.
fyi. this is enabled on Bugzilla since Jul 8 6:17 PM we set it to max-age 7 days only for now (see csteipp's comment on https://gerrit.wikimedia.org/r/#/c/127256/) we want to wait for one full cycle, then raise that value,and then the Qualis SSL labs test will not say it's "TOOSHORT" anymore
Wikitech: https://gerrit.wikimedia.org/r/#/c/145491/2 OTRS: https://gerrit.wikimedia.org/r/#/c/145495/
Change 145500 had a related patch set uploaded by Dzahn: StrictTransportSecurity for lists.wm.org https://gerrit.wikimedia.org/r/145500
Change 145495 had a related patch set uploaded by Krinkle: StrictTransportSecurity for OTRS https://gerrit.wikimedia.org/r/145495
Change 145491 had a related patch set uploaded by Krinkle: Enable StrictTransportSecurity for wikitech https://gerrit.wikimedia.org/r/145491
Change 145491 merged by Andrew Bogott: Enable StrictTransportSecurity for wikitech https://gerrit.wikimedia.org/r/145491
Change 145495 merged by Dzahn: StrictTransportSecurity for OTRS https://gerrit.wikimedia.org/r/145495
Just enabled it on OTRS a minute ago. 11:21 < mutante> !log OTRS - enabled STS, updated SSL cipher list, restarted Apache on iodine
Could we now raise the max-age to 1 year or longer?
Yes, I think after no known issues with HSTS being enabled with 7day max-age for 7 days, it makes sense to extend it. I don't know of any reason not to use 1 year. So lets go with that. Out of curiosity: Any special reason for 1 year? The longest suggestions I have seen is 186 days from http://www.chromium.org/sts .
Bugzilla: https://gerrit.wikimedia.org/r/#/c/148285/ OTRS: https://gerrit.wikimedia.org/r/#/c/148289/ Wikitech: https://gerrit.wikimedia.org/r/#/c/148290/
Change 148285 had a related patch set uploaded by JanZerebecki: bugzilla - raise max-age for STS to 1 year https://gerrit.wikimedia.org/r/148285
Change 148289 had a related patch set uploaded by JanZerebecki: OTRS - raise max-age for STS to 1 year https://gerrit.wikimedia.org/r/148289
Change 148290 had a related patch set uploaded by JanZerebecki: wikitech - raise max-age for STS to 1 year https://gerrit.wikimedia.org/r/148290
Change 148290 merged by Andrew Bogott: wikitech - raise max-age for STS to 1 year https://gerrit.wikimedia.org/r/148290
Change 148285 merged by Dzahn: bugzilla - raise max-age for STS to 1 year https://gerrit.wikimedia.org/r/148285
Change 148289 merged by Dzahn: OTRS - raise max-age for STS to 1 year https://gerrit.wikimedia.org/r/148289
OTRS (ticket.wikimedia.org) - now "This server supports HTTP Strict Transport Security with long duration." (1 year)
Change 157789 had a related patch set uploaded by Chmarkine: gerrit: Enable StrictTransportSecurity max-age=7days https://gerrit.wikimedia.org/r/157789
Change 157789 merged by Dzahn: gerrit: Enable StrictTransportSecurity max-age=7days https://gerrit.wikimedia.org/r/157789
Change 145500 merged by Dzahn: StrictTransportSecurity for lists.wm.org https://gerrit.wikimedia.org/r/145500
Change 159729 had a related patch set uploaded by Chmarkine: gerrit - raise HSTS max-age to 1 year https://gerrit.wikimedia.org/r/159729
Change 161177 had a related patch set uploaded by Chmarkine: lists.wm.org - raise HSTS max-age to 1 year https://gerrit.wikimedia.org/r/161177
sounds good, please let ops@ know this is going on so people are aware (that is, hsts on non-mediawiki sites being turned on)
Change 162805 had a related patch set uploaded by Chmarkine: phabricator - enable HSTS with max-age 7 days https://gerrit.wikimedia.org/r/162805
Change 162805 merged by Rush: phabricator - enable HSTS with max-age 7 days https://gerrit.wikimedia.org/r/162805
Change 159729 merged by Dzahn: gerrit - raise HSTS max-age to 1 year https://gerrit.wikimedia.org/r/159729
Change 164897 had a related patch set uploaded by Chmarkine: phabricator - raise HSTS max-age to 1 year https://gerrit.wikimedia.org/r/164897
Change 164897 merged by Rush: phabricator - raise HSTS max-age to 1 year https://gerrit.wikimedia.org/r/164897
Change 161177 merged by Filippo Giunchedi: lists.wm.org - raise HSTS max-age to 1 year https://gerrit.wikimedia.org/r/161177
How about installing Extension:HSTS on Wikipedia and other projects? It seems to be very useful. [1] https://www.mediawiki.org/wiki/Extension:HSTS
(In reply to chmarkine from comment #55) > How about installing Extension:HSTS on Wikipedia and other projects? It > seems to be very useful. > > [1] https://www.mediawiki.org/wiki/Extension:HSTS * Note that if you intend to activate HSTS on the whole website, it will be * more efficient and robust to add it directly in the server configuration.
(In reply to Sam Reed (reedy) from comment #56) > (In reply to chmarkine from comment #55) > > How about installing Extension:HSTS on Wikipedia and other projects? It > > seems to be very useful. > > > > [1] https://www.mediawiki.org/wiki/Extension:HSTS > > * Note that if you intend to activate HSTS on the whole website, it will be > * more efficient and robust to add it directly in the server configuration. Yeah, I agree. But what the extension does is to allow registered users to optionally enable HSTS, rather than enforcing everyone to use it.
(In reply to chmarkine from comment #57) > (In reply to Sam Reed (reedy) from comment #56) > > (In reply to chmarkine from comment #55) > > > How about installing Extension:HSTS on Wikipedia and other projects? It > > > seems to be very useful. > > > > > > [1] https://www.mediawiki.org/wiki/Extension:HSTS > > > > * Note that if you intend to activate HSTS on the whole website, it will be > > * more efficient and robust to add it directly in the server configuration. > > Yeah, I agree. But what the extension does is to allow registered users to > optionally enable HSTS, rather than enforcing everyone to use it. This extension aims at smoothly deploy HSTS on MediaWiki wikis, and I added some months ago the possibility to enable it as a BetaFeature. This would gradually increase the load on the servers and the users could say if they have problems before a wider deployment.
And payments.wikimedia.org should use HSTS as well. https://www.ssllabs.com/ssltest/analyze.html?d=payments.wikimedia.org
