store.wikimedia.org HTTPS issues:
- Currently has: Strict-Transport-Security: max-age=31557600
- Needs: Strict-Transport-Security: max-age=31557600; includeSubDomains; preload
store.wikimedia.org HTTPS issues:
|Resolved||BBlack||T104681 HTTPS Plans (tracking / high-level info)|
|Open||None||T128559 Enable HSTS on store.wikimedia.org for HTTPS|
|Resolved||None||T39790 shop.wikimedia.org should be HTTPS only|
|Resolved||Krinkle||T93959 Shop homepage on HTTPS loads insecure content|
|Resolved||Krinkle||T96818 Shop homepage on HTTPS contains insecure submission form|
|Resolved||BBlack||T131131 Canonical URL in Store points to HTTP address, should be HTTPS|
Setting the HSTS header means that the webserver will tell the clients (browsers) "only ever use https to connect to this site and never http again". So it ensures that it's only possible to talk to this site using a secure (encrypted) connection. It protects against certain kinds of attacks where a client is convinced to "downgrade" to http which means data is not encrypted anymore and potential attackers can sniff traffic and get private data out of it. In the worst case this could be credit card data in the case of a shop. The tricky part is that once you turn this on you can't simply revert it if something goes wrong, so you have to be sure that you are ready to do this. Shopify must be sure that all parts of the shop system are https-only and stay like that in the future.
found quote from a mail from Seddon "Change in management.. Wikipedia Store project has moved under Michael Beattie.. Sandra Hust  will be the primary contact for internal orders, questions and operations, while Michael Beattie will be responsible for the management of the project itself."
It seems like Shopify has been making some improvements on this front since we last checked.
I google'd around a bit to see what I could see about Shopify's current level of support myself. What I found was https://help.shopify.com/manual/domains/ssl which says: HSTS policy can be set on a domain for a fixed length of time. Shopify's default length is three months (90 days).
I suspect this means that whoever has the admin control panel for our Shopify site should be able to turn on HSTS through some standard configuration setting, and probably set a custom length of 1 year as well. The help page doesn't indicate whether their settings allow turning on includeSub and/or preload, but even if those turn out to be missing, some HSTS would be better than none at all. We can always file a support request afterwards asking for those additional attributes to be configurable.
Digging a little deeper, Shopify open-sources a lot of their infrastructure code. It seems likely that they already support the appropriate attributes at least in the lower levels of their stack (who knows in the user interface), as the specific options exist in their modified clone of Rails: https://github.com/Shopify/rails-mirror/blob/master/actionpack/lib/action_dispatch/middleware/ssl.rb#L20
Been working on this over the last week.
The short: We have HSTS but its set to 90 days. Shopify have confirmed that this can be extended in length but they can’t set preload and includeSubDomains on the store at this point in time.
So the store does have a HSTS header https://www.ssllabs.com/ssltest/analyze.html?d=store.wikimedia.org&hideResults=on
However the age is only 90 days. Shopify confirmed that this is set by default. This does run slight contrary to shopify's own software production stack which has a default length of 180 days.
They can adjust the stores hsts_age however the header is set for all domains on the store. And currently they do not have domain specific HSTS header options, it’s a all or nothing situation which works fine for us.
Whilst we are currently hosted by Spotify themselves, they can’t set preload and includeSubDomains on the store. In the future this may be an option - but right now its not.
This latter option i think would be different if we were host independently of Shopify but with the current setup not achievable.
Currently having some issues in getting store ownership transferred so once that's sorted we can look at getting this HSTS change done. I might be able to get that started this evening but if not it will be when I come back from leave on October 2nd.
Thanks for the updates! Even a 90d HSTS without the preload/includeSub flags is better than nothing. If we can get the time extended out to 1y that's even better. Of the two missing attributes, preload is the more important of the two. I suspect Shopify will be getting increasing pressure about all of these things from customers over time, so hopefully the situation will continue to improve.
Update: sometime since I last checked, they've changed the header to: strict-transport-security: max-age=31557600 (~1 year, vs ~90 days before). Still missing the other attributes (preload and includeSubDomains)...
Do we have a document somewhere describing the requirements of hosts pointed to by records under the wikimedia.org zone? If not should one be made and a compliance requirement date set?
The swap of Traffic for Traffic-Icebox in this ticket's set of tags was based on a bulk action for all such tickets that haven't been updated in 6 months or more. This does not imply any human judgement about the validity or importance of the task, and is simply the first step in a larger task cleanup effort. Further manual triage and/or requests for updates will happen this month for all such tickets. For more detail, have a look at the extended explanation on the main page of Traffic-Icebox . Thank you!