[Bug 38516] New: Enable HSTS on Wikimedia wikis

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

Web browser: ---
Bug #: 38516
Summary: Enable HSTS on Wikimedia wikis
Product: Wikimedia
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: SSL related
AssignedTo: wikibugs-***@lists.wikimedia.org
ReportedBy: ***@gmail.com
Classification: Unclassified
Mobile Platform: ---


[[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

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #1 from MZMcBride <***@mzmcbride.com> 2012-07-20 06:42:07 UTC ---
I think you'd do this at the Squid level. The Squid configuration is in
Wikimedia's git repo somewhere...

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

Krinkle <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com,
| |***@gmail.com

--- Comment #2 from Krinkle <***@gmail.com> 2012-07-20 06:52:39 UTC ---
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.

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

Sam Reed (reedy) <***@reedyboy.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #3 from Ryan Lane <***@gmail.com> 2012-07-20 21:58:15 UTC ---
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.

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

Roan Kattouw <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #4 from Roan Kattouw <***@gmail.com> 2012-07-20 22:05:46 UTC ---
(In reply to comment #3)

Post by b***@wikimedia.org
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.

Post by b***@wikimedia.org
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?

Post by b***@wikimedia.org
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.

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #5 from Ryan Lane <***@gmail.com> 2012-07-20 22:28:24 UTC ---
(In reply to comment #4)

Post by b***@wikimedia.org
(In reply to comment #3)

Post by b***@wikimedia.org
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.

Post by b***@wikimedia.org
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?

Post by b***@wikimedia.org

Post by b***@wikimedia.org
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.

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #6 from Roan Kattouw <***@gmail.com> 2012-07-20 22:30:18 UTC ---
(In reply to comment #5)

Post by b***@wikimedia.org
Eh? Since when are we serving incorrect certificates? Do you mean for mobile?

https://wikipedia.com
https://wikipedia.net
https://wikidata.org

Post by b***@wikimedia.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.

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #7 from Ryan Lane <***@gmail.com> 2012-07-20 22:34:50 UTC ---
(In reply to comment #6)

Post by b***@wikimedia.org
(In reply to comment #5)

Post by b***@wikimedia.org
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.

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

Andre Klapper <***@wikimedia.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Priority|Unprioritized |Low

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

***@mozilla.com changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@mozilla.com

--- Comment #8 from ***@mozilla.com ---
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!

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

Andre Klapper <***@wikimedia.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Blocks| |35079

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

Tyler Romeo <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #9 from Tyler Romeo <***@gmail.com> ---
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.

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #10 from Ryan Lane <***@gmail.com> ---
(In reply to comment #9)

Post by b***@wikimedia.org
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?

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

Phillip Patriakeas <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.c
| |om
Depends on| |35313, 36126

--- Comment #11 from Phillip Patriakeas <***@gmail.com> ---
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. =)

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #12 from Ryan Lane <***@gmail.com> ---
(In reply to comment #11)

Post by b***@wikimedia.org
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.

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #13 from Phillip Patriakeas <***@gmail.com> ---
(In reply to comment #12)

Post by b***@wikimedia.org
We're no longer serving invalid certs.

Okay, guess I should've actually read them. Sorry about that. =X

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #14 from Matthew Flaschen <***@wikimedia.org> ---
(In reply to comment #12)

Post by b***@wikimedia.org
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/ .

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #15 from Tyler Romeo <***@gmail.com> ---
(In reply to comment #10)

Post by b***@wikimedia.org
(In reply to comment #9)

Post by b***@wikimedia.org
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...

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #16 from ***@mozilla.com ---
(In reply to comment #10)

Post by b***@wikimedia.org
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)

Post by b***@wikimedia.org
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.

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #17 from Ryan Lane <***@gmail.com> ---
(In reply to comment #16)

Post by b***@wikimedia.org
(In reply to comment #10)

Post by b***@wikimedia.org
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

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #18 from Tyler Romeo <***@gmail.com> ---
(In reply to comment #16)

Post by b***@wikimedia.org
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. :/

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

Bug 38516 depends on bug 36126, which changed state.

Bug 36126 Summary: *.mobile.wikipedia.org domains are using invalid SSL certificate
https://bugzilla.wikimedia.org/show_bug.cgi?id=36126

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |WONTFIX

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

Bug 38516 depends on bug 36126, which changed state.

Bug 36126 Summary: *.mobile.wikipedia.org domains are using invalid SSL certificate
https://bugzilla.wikimedia.org/show_bug.cgi?id=36126

What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|WONTFIX |---

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

Nemo <***@tiscali.it> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@tiscali.it
Depends on| |34670

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

Bug 38516 depends on bug 35313, which changed state.

Bug 35313 Summary: SSL cert invalid for bugzilla.wikipedia.org redirect
https://bugzilla.wikimedia.org/show_bug.cgi?id=35313

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #19 from Gerrit Notification Bot <***@wikimedia.org> ---
Change 132393 had a related patch set uploaded by MZMcBride:
Improve nginx TLS/SSL settings.

https://gerrit.wikimedia.org/r/132393

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

Gerrit Notification Bot <***@wikimedia.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |PATCH_TO_REVIEW

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

Jan Zerebecki <***@zerebecki.de> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|PATCH_TO_REVIEW |NEW
CC| |***@zerebecki.de

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

***@outlook.com changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@outlook.com

--- Comment #20 from ***@outlook.com ---
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

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #21 from Andre Klapper <***@wikimedia.org> ---
*** Bug 67303 has been marked as a duplicate of this bug. ***

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

***@hotmail.com changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@hotmail.com

--- Comment #24 from ***@hotmail.com ---
(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.

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

Daniel Zahn <***@wikimedia.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@wikimedia.org

--- Comment #25 from Daniel Zahn <***@wikimedia.org> ---
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

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #26 from Daniel Zahn <***@wikimedia.org> ---
Wikitech: https://gerrit.wikimedia.org/r/#/c/145491/2

OTRS: https://gerrit.wikimedia.org/r/#/c/145495/

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #27 from Gerrit Notification Bot <***@wikimedia.org> ---
Change 145500 had a related patch set uploaded by Dzahn:
StrictTransportSecurity for lists.wm.org

https://gerrit.wikimedia.org/r/145500

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

Gerrit Notification Bot <***@wikimedia.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |PATCH_TO_REVIEW

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #28 from Gerrit Notification Bot <***@wikimedia.org> ---
Change 145495 had a related patch set uploaded by Krinkle:
StrictTransportSecurity for OTRS

https://gerrit.wikimedia.org/r/145495

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #29 from Gerrit Notification Bot <***@wikimedia.org> ---
Change 145491 had a related patch set uploaded by Krinkle:
Enable StrictTransportSecurity for wikitech

https://gerrit.wikimedia.org/r/145491

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #30 from Gerrit Notification Bot <***@wikimedia.org> ---
Change 145491 merged by Andrew Bogott:
Enable StrictTransportSecurity for wikitech

https://gerrit.wikimedia.org/r/145491

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #31 from Gerrit Notification Bot <***@wikimedia.org> ---
Change 145495 merged by Dzahn:
StrictTransportSecurity for OTRS

https://gerrit.wikimedia.org/r/145495

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #32 from Daniel Zahn <***@wikimedia.org> ---
Just enabled it on OTRS a minute ago.

11:21 < mutante> !log OTRS - enabled STS, updated SSL cipher list, restarted
Apache on iodine

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #33 from ***@hotmail.com ---
Could we now raise the max-age to 1 year or longer?

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #34 from Jan Zerebecki <***@zerebecki.de> ---
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 .

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #35 from ***@hotmail.com ---
Bugzilla: https://gerrit.wikimedia.org/r/#/c/148285/
OTRS: https://gerrit.wikimedia.org/r/#/c/148289/
Wikitech: https://gerrit.wikimedia.org/r/#/c/148290/

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #36 from Gerrit Notification Bot <***@wikimedia.org> ---
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

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #37 from Gerrit Notification Bot <***@wikimedia.org> ---
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

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #38 from Gerrit Notification Bot <***@wikimedia.org> ---
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

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #39 from Gerrit Notification Bot <***@wikimedia.org> ---
Change 148290 merged by Andrew Bogott:
wikitech - raise max-age for STS to 1 year

https://gerrit.wikimedia.org/r/148290

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #41 from Gerrit Notification Bot <***@wikimedia.org> ---
Change 148289 merged by Dzahn:
OTRS - raise max-age for STS to 1 year

https://gerrit.wikimedia.org/r/148289

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #42 from Daniel Zahn <***@wikimedia.org> ---
OTRS (ticket.wikimedia.org) - now "This server supports HTTP Strict Transport
Security with long duration." (1 year)

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #44 from Gerrit Notification Bot <***@wikimedia.org> ---
Change 157789 merged by Dzahn:
gerrit: Enable StrictTransportSecurity max-age=7days

https://gerrit.wikimedia.org/r/157789

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

Matthew Flaschen <***@wikimedia.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Summary|Enable HSTS on Wikimedia |Enable HSTS on Wikimedia
|wikis |sites

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #45 from Gerrit Notification Bot <***@wikimedia.org> ---
Change 145500 merged by Dzahn:
StrictTransportSecurity for lists.wm.org

https://gerrit.wikimedia.org/r/145500

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #46 from Gerrit Notification Bot <***@wikimedia.org> ---
Change 159729 had a related patch set uploaded by Chmarkine:
gerrit - raise HSTS max-age to 1 year

https://gerrit.wikimedia.org/r/159729

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #47 from Gerrit Notification Bot <***@wikimedia.org> ---
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

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

Filippo Giunchedi <***@wikimedia.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@wikimedia.org

--- Comment #48 from Filippo Giunchedi <***@wikimedia.org> ---
sounds good, please let ops@ know this is going on so people are aware (that
is, hsts on non-mediawiki sites being turned on)

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #49 from Gerrit Notification Bot <***@wikimedia.org> ---
Change 162805 had a related patch set uploaded by Chmarkine:
phabricator - enable HSTS with max-age 7 days

https://gerrit.wikimedia.org/r/162805

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #50 from Gerrit Notification Bot <***@wikimedia.org> ---
Change 162805 merged by Rush:
phabricator - enable HSTS with max-age 7 days

https://gerrit.wikimedia.org/r/162805

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #51 from Gerrit Notification Bot <***@wikimedia.org> ---
Change 159729 merged by Dzahn:
gerrit - raise HSTS max-age to 1 year

https://gerrit.wikimedia.org/r/159729

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #52 from Gerrit Notification Bot <***@wikimedia.org> ---
Change 164897 had a related patch set uploaded by Chmarkine:
phabricator - raise HSTS max-age to 1 year

https://gerrit.wikimedia.org/r/164897

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #53 from Gerrit Notification Bot <***@wikimedia.org> ---
Change 164897 merged by Rush:
phabricator - raise HSTS max-age to 1 year

https://gerrit.wikimedia.org/r/164897

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #54 from Gerrit Notification Bot <***@wikimedia.org> ---
Change 161177 merged by Filippo Giunchedi:
lists.wm.org - raise HSTS max-age to 1 year

https://gerrit.wikimedia.org/r/161177

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #43 from Gerrit Notification Bot <***@wikimedia.org> ---
Change 157789 had a related patch set uploaded by Chmarkine:
gerrit: Enable StrictTransportSecurity max-age=7days

https://gerrit.wikimedia.org/r/157789

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #55 from ***@hotmail.com ---
How about installing Extension:HSTS on Wikipedia and other projects? It seems
to be very useful.

[1] https://www.mediawiki.org/wiki/Extension:HSTS

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #56 from Sam Reed (reedy) <***@reedyboy.net> ---
(In reply to chmarkine from comment #55)

Post by b***@wikimedia.org
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.

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #57 from ***@hotmail.com ---
(In reply to Sam Reed (reedy) from comment #56)

Post by b***@wikimedia.org
(In reply to chmarkine from comment #55)

Post by b***@wikimedia.org
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.

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

Seb35 <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #58 from Seb35 <***@gmail.com> ---
(In reply to chmarkine from comment #57)

Post by b***@wikimedia.org
(In reply to Sam Reed (reedy) from comment #56)

Post by b***@wikimedia.org
(In reply to chmarkine from comment #55)

Post by b***@wikimedia.org
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.

[b***@wikimedia.org]

https://bugzilla.wikimedia.org/show_bug.cgi?id=38516

--- Comment #59 from ***@hotmail.com ---
And payments.wikimedia.org should use HSTS as well.

https://www.ssllabs.com/ssltest/analyze.html?d=payments.wikimedia.org