Strict Transport Security Header

[Rosella_Fernand]

Hey There,

I sent out an email from Marketo and they are getting a site not secure error. After they get this error the were redirected to the 404 Error page on our Web site.  There was a good chunk of our audience, so Marketo is now unusable:(  How do we fix this ASAP? #support‌ #customer support‌ #safari‌ #tracked links redirect‌ #redirects‌

[SanfordWhiteman]

Please do not obfuscate your domain, it will not be possible to help if you do this.

[SanfordWhiteman]

Singling out Safari 13 is incorrect. Your branding (email tracking) domain, go.aryaka.com, indeed does not have a valid SSL certificate. This is true in any browser that validates the cert.

[Rosella_Fernand]

Cool...thanks for the insight.  The go.aryaka.com is what we use via Marketo for tracking, we would prefer just taking them to our main https://www.arkaya.com site which has the SSL certificates enabled.  How can we change Marketo to do that?

[SanfordWhiteman]

You can't both track links (Clicked Email) and send people directly to your main website. The 2 are mutually exclusive.

By default in Marketo, all links are tracked, meaning they are rewritten to bounce off your branding domain, then go to the final destination domain. If you want to turn off tracking, you must add the class="mktNoTrack" to your links. And indeed, you need to do this with all your links until you add SSL to your Marketo subscription.

The root cause here is that your web team broke connections to Marketo. They added the HSTS (Strict-Transport-Security) header to your main website without testing it first, and included all subdomains of aryaka.com even though they don't manage those domains. In a nutshell, HSTS requires that all connections be secure, which is great... but only if indeed all of your sites can be accessed securely. Even worse, they added a 1-year expiration (!!!) to the HSTS header, meaning everyone who's seen that header cannot unsee it.  Incredible rookie mistake.

Note that if your web team hadn't added that header, you'd be fine not having SSL in Marketo. The branding domain doesn't have to support SSL. It's better if it does -- for the net as a whole -- but is by no means required.  But if the link claims it supports SSL (that is, it begins with https:// because HSTS requires it) then the cert must be installed.

[SanfordWhiteman]

Also, please change the title of your thread -- this doesn't have anything to do with Safari in particular and it's going to confuse anyone who comes across it.

[Rosella_Fernand]

Done and Thank you!

[SanfordWhiteman]

Thanks, if you could mark my post above (the one where I first mentioned HSTS) as Correct that would help future searches.

P.S. If you're wondering why it might have seemed like Safari 13 was specifically affected, remember that's a new major release. As such, people who installed Saf 13 likely started with a clean HSTS cache. In contrast, people on other browsers might have been using cached versions of your HSTS header which didn't yet have the ill-advised includeSubdomains directive. If the older header was also set to be cached for a year, people wouldn't fetch the new problematic header until they cleared their cache/switched browsers. Unfortunately, now everybody who has the problematic one will not be able to follow your links for a year.

[Rosella_Fernand]

Thanks.  Not sure how to move your other post to the front, but will do so if/when I figure it out.  Quick question, on your last post, if we replace the go.arkaya.com domain with an SSL one, or we revise the HSTS header to not include subdomains, can this fix the issue of people who landed from subdomains without SSL?  Again.  I truly appreciate your help/insight.  

[SanfordWhiteman]

Not sure how to move your other post to the front, but will do so if/when I figure it out. 

There's a "Correct Answer" link you can click.

Quick question, on your last post, if we replace the go.arkaya.com domain with an SSL one, or we revise the HSTS header to not include subdomains, can this fix the issue of people who landed from subdomains without SSL?

If you add a cert to go.aryaka.com (I wouldn't say "replace the domain" really) then it will fix the problem for all visits to that domain (include existing, now-broken links you already sent out).

Revising the HSTS header on aryaka.com so it no longer includes subdomains is the right thing to do if you aren't going to add an SSL cert to go.aryaka.com. But it will not fix the problem for those people who have the includeSubdomains entry cached -- i.e. anybody who has visited aryaka.com after your web team made that decision. That includes today: literally everybody who is visiting aryaka.com today is going to think that go.aryaka.com supports SSL for the next year. I would urge them to turn off includeSubdomains immediately (should've been done yesterday, as soon as it was discovered) as you're digging yourself deeper into a hole, affecting revenue, etc.