Hacker News Reader

Comment by mtkd | Hacker News Reader

They mention it has been a complex undertaking and not complete yet - does anyone know why they can't just sit a traffic manager in front of everything with SSL offloading?

Also does anyone know what the new personalisation features are that they mention being able to offer now HTTPS in place?

View on HN

According to WaPo's move to HTTPS blog post:

>Ask any developer at a major media organization what the biggest hurdle to HTTPS adoption is, and the answer is always going to be advertising. However, unless you understand the ins-and-outs of how digital advertising is implemented, it’s difficult to see why this presents a challenge.

from https://developer.washingtonpost.com/pb/blog/post/2015/12/10...

Fortunately, even that is changing. Google forced advertisers who want to buy inventory through AdX to switch their creatives to HTTPS in 2015 already. In my experience, any non-compliance to that comes from shitty agencies that haven't gotten the memo that you're better off just switching everything to HTTPS these days.

This is likely an organizational, rather than a technical problem. Having worked for large media organizations, often different parts of the site are different deployable applications that share only a hardware device or small nginx or haproxy layer if they're on the same subdomain. It may be that in order to enable SSL on all parts of nytimes.com you need to affect ssl termination at a higher layer on a number of different servers/deploy locations which requires time and testing.

It's also possible that terminating the SSL and then passing through unsecured traffic lower in the stack is not ideal due to where the different parts of the site are hosted - e.g. passing traffic unsecured back and forth between private DC and public cloud.

Note: All speculation based on having implemented SSL migrations at large media companies.

For our media website, it took us one year before we could move to HTTPS, mainly because of the AdServers which wasn't ready. We had to talk to each ad provider in order to ask them to upgrade to HTTPS. Unfortunately as media companies have most of their revenue from ads you just can't switch like that.

Also, features that are now available once the HTTPS by default on a website, is the AMP, Notifications, HTTP2 (faster loading) and, of course, the little advantage that Google gives to the HTTPS websites.

Google started the process of enforcing HTTPS on AdX about 2.5 years ago. Not implementing HTTPS in that large timeframe is rather inexcusable. It's just technical debt that you need to acknowledge, and then get rid of it.

Nowadays an Ad Server can call another one and so one, due to programmatic. So you might have one Ad server enforcing and serving their tags in HTTPS, but in the end the little local Ad Server which is part of a bigger network doesn't have the HTTPS and so his material isn't delivered.

Third party content. You have ad providers that won't agree to you delivering their content. They want to keep control over that (which is by the way a huge security risk on its own, but that's the state of things).

> Also does anyone know what the new personalisation features are that they mention being able to offer now HTTPS in place?

Not sure what features the NYT is referencing specifically, but Chrome has certain features [like the Geolocation API][1] disabled for pages loaded over HTTP. See [Deprecating Powerful Features on Insecure Origins][2].

[1]: https://developers.google.com/web/updates/2016/04/geolocatio...

[2]: https://www.chromium.org/Home/chromium-security/deprecating-...

At any large media organization, there are tremendous amounts of content no longer connected to any CMS that may have hard-coded insecure links/resources in them. Some of them may live on obscure servers or domains. Or the developers/journalists who worked on them and have knowledge of their construction are long gone. These pages are very laborious to find and update.

If you don't mind 404ing or breaking a ton of your old content, it's probably not too difficult. But if you're the newspaper of record, it's a big deal that URLs live on and continue to work as expected.

You also mention "insecure resources", wich I think is a big deal too. I'd imagine there'd be the oddA hard-coded http link to an image that serves an important purpose to an article... that suddenly going missing because a browser refuses to load it would be bad.

But I think you hit the nail on the head -- being the "newspaper of record" means you want to ensure that all your content displays like it did the day it was published.

HTTP URLs redirect to HTTPS

Well, in our case that was the easiest thing to pick, thanks to the Report-Only option on the CSP header, we enabled it and in about a week, we got all our insecure links and resources.

We could also set a header forcing the browser to upgrade to secure when the resources are in the same domain.

HTTP URLs redirect to HTTPS, done. That's a basic step of turning on HTTPS

Reply on news.ycombinator.com