Http to Https redirect after SSL encription

[Grégoire_Miche2]

One of my customers is being asked to implement SSL encryption of the Marketo instance. The rationale behind it is that the web site and documentation center will have the SSL encryption implemented.

As they have been using Marketo for a couple of years now, the problem is they have literally hundreds of programs running with LP's and emails, all of them using content (mostly images and links to download docs) that we need to edit to replace http into https.

Is there an alternative solution?

Thx to all

-Greg

[Dan_Stevens_]

Greg, when we did the same thing a couple of years ago, all of those links were changed to https automatically. We didn't have to manually change anything.

[Grégoire_Miche2]

Hi Dan,

Yes all the URL of the images and files are changed together with that of the landing pages. But then, in order to avoid any "unsecure content" alert in browsers, one needs to edit every LP and every email and change the URLs of images and other files from HTTP to HTTPS.

I am hoping that someone knows a way to avoid the workload associated with this change, but I am afraid there is none.

-Greg

[Dan_Stevens_]

That's what I'm referring to. All image references (in emails and LPs), URLs of, and links to LPs, were changed automatically.

[Dan_Stevens_]

Ok, scratch that. I suspect you're referring to references to non-Marketo resources/assets - correct?  This wasn't really an issue for us since most of our LPs and emails reference Marketo assets (except for the occasional external link to a third-party site).  Also, any references to third party code, like bootstrap, already uses https.

[Grégoire_Miche2]

Hi Dan,

Apparently, from this FAQ and this post and the comments (specially the post from Justin), there is nothing automatic unless you implement HSTS on the top level domain. Maybe this what you did, didn't you?

-Greg

[Dan_Stevens_]

To be honest, I can't remember since it's been so long.  All I know is that is was pretty effortless on our end.  We (Marketo Support and our IT folks) did need to be on a call together when they "flipped the switch".

[SanfordWhiteman]

HSTS can only "solve" the problem in browsers that support it (notable exception being IE < IE 11).

More important, treating HSTS as ensuring security is wrong unless your domain is on the browsers' HSTS Preload list.  If you're not on Preload your site is insecure for every initial visit (which is to say: it's insecure). HSTS is at best a transitional mechanism while you hard-code https:​// links (or protocol-relative // links, of course).

[Grégoire_Miche2]

HI Sanford,

Thx. What does it take to implement HSTS?

-Greg

[SanfordWhiteman · Accepted solution]

In its most basic form, it just means adding an HTTP header to the parent registered domain, that is, whoever controls http:​//example.com (with no hostname) adds the header to Apache/IIS/Nginx and that's it.

This gives an unprecedented -- and dangerous -- level of control to the people who operate the uppermost parent domain.  Not that they would mess anything up on purpose , but it means the webmaster of http​://example.com in effect has control over how people are allowed to access http​://pages.example.com -- and not just marketing-related hostnames but any other hostnames, like webmail.example.com or documentmgmt.example.com or some-internal-app-not-running-over-https.example.com.  Aside from HSTS there really isn't any other to exert this kind of control (and you don't even need access to DNS records to do it) so it's pretty freaky.

So this kind of migration is not to be taken lightly and requires a thorough audit of all hostnames in use, both internally and externally, to ensure that they are listening for HTTPS connections.