Fixed up title and description to match what we need out of it today, rather than old audit data and/or old targets.

@Ppena (or anyone) - who's responsible in the WMF for store.wikimedia.org? This is a pretty basic request and it's been outstanding for months. It's one of the few non-confirming exceptions to our HTTPS policy remaining!

found quote from a mail from Seddon "Change in management.. Wikipedia Store project has moved under Michael Beattie.. Sandra Hust [2] will be the primary contact for internal orders, questions and operations, while Michael Beattie will be responsible for the management of the project itself."

Hey @BBlack,

Apologies, this got dropped. Either myself or @MBeat33 will get back to you as to whether we can actually make this change or not, although my hopes are not that high.

Seddon

Any updates here? What we're asking for here is a modern HTTPS-only configuration. I'd think an e-commerce vendor would be all about that...

@Jseddon / @MBeat33: Any news?

@Jseddon @MBeat33 - ping again? The redirect appears to work currently, but still no HSTS header.

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

Hey @BBlack,

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.

The long:

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.

NEXT STEPS:

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.

The store HSTS header now has max-age=31557600, but still no includeSubDomains or preload.

Bump - Whomever's in charge of Shopify on our end, can we check if they've added support for includeSubdomains and preload now in some site setting?

@MBeat33: Could you maybe answer @BBlack's last question? Or do you know who could?
(Asking you because of https://phabricator.wikimedia.org/T228672#5358426 )

T228672 says nobody in charge of the Shop is even on Phabricator :(

Looks like we have to email merchandise@ to get this bumped.

Hi all, @Jseddon is on leave, but this is on his agenda for when he returns. I know he's engaged with Shopify about this issue.

@MBeat33 + @Jseddon - Thank you for the update(s)

@MBeat33 / @Jseddon - Any update yet?

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!

In T128559#8586016, @BCornwall wrote:

Wow, seven years! Hello to those still around. :)

Who is in charge of shopify/store.wikimedia.org nowadays? It would be nice if we could get them talking once again with the company to get this solved. If they're not on phabricator, that's okay, I just need a name so I may hunt them down.

Hi Brett:) thanks for getting this going again:) I don't know who is in charge but I think the easiest might be to email merchandise@wikimedia.org and see who answers, per:

https://store.wikimedia.org/pages/contact-us

@BCornwall found this "contact: Merchandise@wikimedia.org (response platform), Khansen-ctr@wikimedia.org (Store associate), or Shust@wikimedia.org (Store Manager) " on https://office.wikimedia.org/wiki/Requesting_merchandise#Questions

Update: We expect to have more info mid-next week. Thanks, everyone for your patience!

@BCornwall would you mind emailing me with more information about what is needed here so I can better understand + contact the right Shopify representative? Thanks in advance!
Shust@wikimedia.org

See this previous comment from Brandon at T128559#3440144. An admin of the shop should be able to set this but should confirm first.

Also here at T128559#2080643 is more high-level explanation what this is about.

I would suggest let's keep this all in one place on the ticket. If we branch out to emails we just have to add it back here anyways.

@SHust, as @Dzahn pointed out, it would be best if we keep this all in one place.

We specifically need the preload and includeSubDomains attributes added to the Strict-Transport-Security header. Information on this seems rather sparse, so I don't know that I can help any further than that. Hopefully Shopify will be able to give you the answers needed.

I'll do as suggested and keep all communications here, thanks @Dzahn.
@BCornwall I emailed the Shopify rep that takes care of our account and will update this thread as soon as I received a reply. In the meantime can you please share if the test you tried back in 2017, using the link below, looks any different this time around? https://www.ssllabs.com/ssltest/analyze.html?d=store.wikimedia.org&hideResults=on

In T128559#3440144, @BBlack wrote:

It seems like Shopify has been making some improvements on this front since we last checked.
..
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.

In T128559#8599342, @SHust wrote:>

can you please share if the test you tried back in 2017, using the link below, looks any different this time around? https://www.ssllabs.com/ssltest/analyze.html?d=store.wikimedia.org&hideResults=on

Hi @SHust,

the test results are better than back in 2017. They are shown as A+, which is good of course.

But as Brandon Black said back in 2017, it does not tell us whether we can also turn on the includeSub and/or preload settings.

And I just checked the headers with curl (and this matches what the ssllabs test you linked shows), and I only see:

strict-transport-security: max-age=31557600

Per crrent ticket description the issue is:

Currently has: Strict-Transport-Security: max-age=31557600
Needs: Strict-Transport-Security: max-age=31557600; includeSubDomains; preload

So what we want here is the "We can always file a support request afterwards asking for those additional attributes to be configurable.".

hope that clears things up a bit.

The additional information did help clear things up, thanks @Dzahn. I'm also glad to see that the test results have improved. I have added a substantial amount of information and the request you shared to the ticket I have with Shopify, and I'll come back once I receive a reply.

@Dzahn, After I shared the issue I'm having with Brendan Campbell (who added himself as a subscriber) + a few other colleagues, he suggested that I ask you for help!
For Shopify to be able to provide a certificate to allow us to turn on 'includeSub and/or preload' settings, I must first change the DNS record shown by their system as having at least one AAAA record which prevents them from doing anything. Such change must be done via the third-party provider managed by Mark Monitor (https://foundation.wikimedia.org/wiki/Resolution:MarkMonitor). I have contacted them via email and several phone calls without any no luck. I also see that Joseph Seddon ran into the same issue back in 2017... Do you have any idea how the ownership can be transferred to the Foundation or if there’s a workaround?
Other than that, Shopify cannot help and I have no clue what else can be done!

Hi @SHust let me clarify, so shopify is saying that store.wikimedia.org must have a AAAA record?

The current status is that store.wikimedia.org is an alias for c.ssl.shopify.com. and that is an alias for shops.myshopify.com. We are just pointing to THEIR records and they don't have a AAAA record themselves.

We control the first step and they control the second step.

I don't think MarkMonitor is involved in this at all.

So this doesn't really add up for me yet. Can you double check with them which DNS record exactly they think should change and can you ask them what value we should use for the AAAA record? (That would be an IP address in the IPv6 format).

I believe they should be able to tell us because all we are doing is point to their services.

All that being said, I am not in the traffic team that specializes in this.

Cheers,

Daniel

@Dzahn, Here's a screenshot from my Shopify chat ( I hope I didn’t share anything I shouldn’t have):

It looks more like a generic response to delegate a whole domain to shopify than what we are currently doing with store.wikimedia.org. As @Dzahn mentioned, we got store.wikimedia.org as a CNAME to c.ssl.shopify.com:

store.wikimedia.org.    3600    IN      CNAME   c.ssl.shopify.com.
c.ssl.shopify.com.      1800    IN      CNAME   shops.myshopify.com.
shops.myshopify.com.    60      IN      A       23.227.38.74

HSTS isn't related to their capacity to issue certificates against store.wikimedia.org but the HTTP headers that their servers sends. Maybe we should escalate the ticket on their side and talk to somebody familiar with the store.wm.o setup.

Regarding their ssllabs result, even if they get an A+ we could benefit from some changes on their TLS v1.2 ciphersuites configuration, mainly dropping all of the ciphersuites using SHA, CBC or non PFS, those listed as WEAK in their ssllabs result.

Also it would be interesting if they can set up an elliptic curve certificate as we are in the path of deprecating RSA ones and they don't currently offer an EC certificate

@Vgutierrez, thanks for your share. May I bug you for a comprehensive summary if possible, of what is needed, what I should put more pressure on, what to say no, etc, so I can reach out to our Shopify account rep again? I won’t lie that my knowledge and understanding are very limited so apologies for asking for additional help, and thank you in advance for anything you or @Dzahn might be able to provide!

In T128559#8618724, @SHust wrote:

@Vgutierrez, thanks for your share. May I bug you for a comprehensive summary if possible, of what is needed, what I should put more pressure on, what to say no, etc, so I can reach out to our Shopify account rep again? I won’t lie that my knowledge and understanding are very limited so apologies for asking for additional help, and thank you in advance for anything you or @Dzahn might be able to provide!

Under the scope of this task, we need them to adjust their HSTS (HTTP Strict Transport Security) header value to match the one used for wikimedia.org. That means raising the max-age value from 31557600 to 106384710 and appending the directives includeSubDomainsand preload.

strict-transport-security: max-age=31557600

strict-transport-security: max-age=106384710; includeSubDomains; preload

Sharing Shopify's latest update below. If anyone has any ideas, please send them my way since I still have no clue what to do!
I made a few tests and found the issue. The subdomain does not point to Shopify. The CNAME records are not valid. The domain has an A record pointing to 23.227.38.74. The domain has a CNAME record pointing to c.ssl.shopify.com. Here's what’s needed: an A record pointing the root domain to 23.227.38.65, and/or a CNAME record pointing any subdomains to shops.myshopify.com. You will need to change the DNS records on the domain itself for it to point to Shopify which involves logging into the domain provider, accessing the domain settings, and following the instructions. 

Hi, @SHust. We appear to be running in circles here! What we're after has nothing to do with DNS/domain names/CNAME/A records, etc. This is entirely about adjusting a security header (i.e. what shopify's servers are sending when people visit the webpage). The keyword to keep in mind is "header", so unless they're actively using that word in their replies then their support is going down the wrong path.

The thing that needs to happen is "Change strict-transport-security: max-age=31557600 to strict-transport-security: max-age=106384710; includeSubDomains; preload". Nothing else they say will make sense unless it's "okay we changed it" (or, less likely, a cogent reply telling us why they cannot). These are changes that are highly likely to be out of our hands since there's no end-user documentation at all on the matter.

It might be worth throwing your weight around and asking to be escalated to a higher support tier considering how long it's taking this to get done.

In T128559#8638381, @SHust wrote:

Sharing Shopify's latest update below. If anyone has any ideas, please send them my way since I still have no clue what to do!

Hi, thank you for this! So let's see.. it says to follow this and it says what the requirements are but somehow it seems to be missing the actual steps to be done after having the requirements. Is there a second page to this maybe?

I made a few tests and found the issue. The subdomain does not point to Shopify.

Cool, let's make sure we are talking about the same thing. Which subdomain exactly are you referring to? store.wikimedia.org, right? not shop.wikimedia.org or one of shopify.com, correct?

The CNAME records are not valid.

store.wikimedia.org is a CNAME for c.ssl.shopify.com. Is shopify saying this is incorrect nowadays and should be changed?

shop.wikimedia.org is an A record for dyna.wikimedia.org. This is because we redirect from shop.wikimedia.org to store.wikimedia.org but I think we can ignore that for this ticket.

So there is only one CNAME record that I can see

The domain has an A record pointing to 23.227.38.74.

c.ssl.shopify.com is an alias for shops.myshopify.com
shops.myshopify.com has address 23.227.38.74

So yes, shops.myshopify.com has that IP address. That's right, but this is outside our control, this is controlled by shopify.

The domain has a CNAME record pointing to c.ssl.shopify.com.

Yes, store.wikimedia.org is a CNAME for c.ssl.shopify.com. This is confirmed.

Here's what’s needed: an A record pointing the root domain to 23.227.38.65

Well, we could point store.wikimedia.org directly to 23.227.38.65, but not the root domain wikimedia.org. Not sure if they mean that though.

and/or a CNAME record pointing any subdomains to shops.myshopify.com.

That is already the case and describes the status quo, except that c.ssl.shopify.com is still in between. Maybe they mean that middle step should be dropped now.

You will need to change the DNS records on the domain itself for it to point to Shopify which involves logging into the domain provider, accessing the domain settings, and following the instructions. 

This can safely be ignored. We run our own DNS servers and can change the records ourselves as needed. There is no other provider there. They are just assuming that for most of their customers.

P.S. Yea, just listen to what @BCornwall said above. That is going to make it less confusing. And thanks for doing this!

Latest Shopify update after escalation -->

Thanks, Sandra, I have a good direction to go on this with my team.

Looks like we do have a hard no on the "includeSubDomains; preload" part of your team's request. That's a limitation we do have, and I'd be happy to share your team's requirements.

Here's the technical on that, you can share with your team:

"Security headers are set by Shopify for connected domains to support the security and functionality of the platform. This is a common false positive flagged by security scanners as they only look to see if the optional includeSubDomains directive is enabled. Where the includeSubDomains directive makes sense to be enabled on the connected domain Shopify has enabled it, but in some locations, it will not be set."

I CAN go to another team to discuss if we can review the max-age requirement so it could hopefully match the main page though, Sandra.

I'll reach out to that team to review further, and will follow up with you over email when I hear back from them, probably next week. Thank you for your patience and understanding.

What a mess. So if I'm understanding this correctly:

• They refuse to include includeSubDomains unless it "makes sense" (what does that even mean?)
  • Which means that preloading won't work since includeSubDomains must be present
• They might be able to increase the max-age
• The best we can do for preloading is complain

@SHust thanks, and keep us posted on their verdict for increasing the max-age

I assume "makes sense" here is probably cases where shopify knows of or has configured actual subdomains of the domain in question, or something like that. In either case, yes, probably pointing out the "preload" requires "includeSubdomains" should help with that part. preload is what we really want.

Also, I saw mention of this earlier in the ticket: the max-age is fine as it is with the value 31557600 (~1yr); we don't need that number changed. The other value mentioned before is unique and only for our own infra (in part because it makes it easy to tell where the number came from).

Maybe worth pointing out (I had an old stale link to this years ago earlier in the ticket), if nothing else because it may cause whomever at shopify to actually reach out to an engineer:

Shopify's fork of Rails does support the attributes in question. That doesn't necessarily mean that their application layer or configuration tools do, but it's there in the underlying libraries: https://github.com/Shopify/rails/blob/main/actionpack/lib/action_dispatch/middleware/ssl.rb#L24

My interpretation of the response was that they also refuse to set the preload value.

Final Shopify reply below. Sorry everyone, I really tried...

Thank you for your patience while I checked on this HSTS inquiry with my team. My team who manages this dug really deep on this, to be sure we can support as much as possible, if possible, but at this point, we're not able to make the changes your engineer has requested. This is a limitation of the platform at this time.
My team has offered that if there is a specific impact on the business, and how this is affecting your store's sales, we can review further if needed. Please let me know the reason for this change, above the already mentioned specification, and I'd be happy to review it with the team further.

Unless I'm mistaken, the only recourse we have at this point is to throw our "top-ten website" gut around and demand the improvements for the security of our users. I don't think that's worth pursuing - what do you think, @BBlack?

Is there a reasonable shopify alternative that meets policy? That would be my question. If there isn't, we're stuck with this policy violation, but shouldn't stop calling it out as a violation. If there is, we should take a look at whether they can also meet our tech policies for our domains. Another viable resolution is simply to move the service to a novel domainname that isn't entangled with our infrastructure (wikipedia-shop.com or whatever), and manage it entirely separately from our production policies and practices.

There's WooCommerce which could be created alongside all other WordPress installations (VIP has unlimited sites, right?) with Stripe as payment provider (preloads HSTS).

That would probably take some time/effort for setup. Just an option that popped into my head.

Maybe it would make shopify reconsider if you merely mention that you _might_ consider using an alternative, combined with pointing out that it's "top 10 website".

I suspect we generate little revenue for them and I don't see any sort of "Businesses that rely on Shopify" section on their site (they seem to prefer showing small mom-and-pop stores, furthering the idea that maybe we're the wrong consumer :P) I suspect they'd just shrug and say "sorry... see ya!"

Should the shop move from store.wikimedia.org to another, separate domain if we're unlikely to switch vendors and our vendor isn't willing to fix this? The issue here is that the security standards dictated for *.wikimedia.org domains are not met with the shop.

Hi @BCornwall ! I'm just jumping in as an FR-Tech representative. I think I've got the summary here (basically, in the end, Shopify can't meet our hsts header needs which blocks overall improvements for all of *.wikimedia.org, right?), and I just want to verify that this need is only for *.wikimedia.org. Is it also applicable for eg *.wikimediafoundation.org? And, just to be explicit, a single-use domain like wikimediashop.org would be OK?

Hey, @greg. It's not blocking overall improvement, it's just not complying with standards. Since shopify cannot meet our requirements, that invalidates the shop using any of these canonical domains. Any domain name that doesn't utilize any of those listed on the page are fair game!