Enabling Secure HTTP for BBC Online • Hacker News Board

Re: Enabling Secure HTTP for BBC Online

#31

Post by Karunamon » Thu, Jul 14, 2016, 4:23 PM UTC

reedloden wrote: post #26

> There are always practical limitations to site-wide technical changes, and HTTPS Everywhere is no different. Sites and content we consider ‘archival’ that involve no signing in or personalisation, such as the News Online archive on news.bbc.co.uk, will remain HTTP-only. This is due to the cost we’d incur processing tens of millions of old files to rewrite internal links to HTTPS when balanced against the benefit. N…

Sites and content we consider ‘archival’ that involve no signing in or personalisation,

AUGH! Seeing this "SSL is just for private things" mindset in 2016 is really disheartening. It's to keep people from screwing with your connection, not just snooping on it.

I really hope the browser vendors start treating HTTP the same way they treat broken certs sometime soon. This will change once users start asking, en masse, "Why am I getting all these warnings", not before.

Re: Enabling Secure HTTP for BBC Online

#32

Post by multjoy » Thu, Jul 14, 2016, 4:24 PM UTC

Buge wrote: post #25

blowski wrote: post #12

Earlier quoted context omitted.

> Even a 2012 MacBook Air can sign an SSL key in only 6.1 milliseconds. The BBC has to deal with machines much older and much less powerful than that.

Every TLS speed concern I've heard has been about the server speed, not the client speed. The servers shouldn't be running on old MacBook airs.

It is the BBC

Re: Enabling Secure HTTP for BBC Online

#33

Post by buro9 » Thu, Jul 14, 2016, 4:24 PM UTC

reedloden wrote: post #26

> There are always practical limitations to site-wide technical changes, and HTTPS Everywhere is no different. Sites and content we consider ‘archival’ that involve no signing in or personalisation, such as the News Online archive on news.bbc.co.uk, will remain HTTP-only. This is due to the cost we’d incur processing tens of millions of old files to rewrite internal links to HTTPS when balanced against the benefit. N…

Plus... they don't have to do this.

They could put in place redirects, and then use HSTS to tell browsers to only visit the HTTPS links.

They could leave the old HTML unprocessed and pointing at HTTP and HSTS will fix it for modern browsers.

Only the first request would be via HTTP, and Chrome and other browsers can be told to use HTTPS when they see the links even then: https://hstspreload.appspot.com/

Re: Enabling Secure HTTP for BBC Online

#34

Post by gilgongo » Thu, Jul 14, 2016, 4:27 PM UTC

_uhtu wrote: post #14

blowski wrote: post #9

Earlier quoted context omitted.

Calling FUD on your comment. It hasn't been "standard on full sites for years", and still isn't now. Only recently with the 'HTTPS everywhere' move has the idea that public sites with no authentication should support HTTPS. And even now, that's not a universally supported opinion, because of its effect on caching. The BBC has used HTTPS on pages with forms that submit secure data, as has been the historic standard. M…

Can you point out some other major sites used by the general public which have spent the last few years without site-wide SSL to back up your claim?

MailOnline. SSL would just cost too much in Akamai billing. Otherwise they'd do it straight away for the SEO uplift.

Re: Enabling Secure HTTP for BBC Online

#35

Post by gilgongo » Thu, Jul 14, 2016, 4:29 PM UTC

vtlynch wrote: post #29

_uhtu wrote: post #14

Earlier quoted context omitted.

Can you point out some other major sites used by the general public which have spent the last few years without site-wide SSL to back up your claim?

Washington Post. Buzzfeed. The Guardian. New York Times still dosent have HTTPs.

Their traffic is too high for them to afford it (and probably wouldn't outweigh the SEO uplift)

Re: Enabling Secure HTTP for BBC Online

#36

Post by jpetrucc » Thu, Jul 14, 2016, 4:29 PM UTC

blowski wrote: post #12

jpetrucc wrote: post #3

> The CPU overhead of TLS encryption has historically been significant. We’ve done a lot of work behind the scenes to improve both the software and hardware layers to minimise the load impact of TLS whilst also improving security. I thought that it hasn't been significant overhead for a while now? related: https://www.maxcdn.com/blog/ssl-performance-myth/ https://istlsfastyet.com/

> Even a 2012 MacBook Air can sign an SSL key in only 6.1 milliseconds. The BBC has to deal with machines much older and much less powerful than that.

Even if it took an ancient machine 10x longer than a 2012 MacBook air, that 61 milliseconds more is really not all that much time in the grand scheme of things.

I'm sure the people using these machines that are "much older and much less powerful" than a 2012 macbook air are not expecting sites to load as fast as a newer machine, and probably don't care about the loss of less than 0.1 seconds to load time. If you're running a 6+ year old machine and expecting high performance you'd have to be insane.

Even if BBCOnline cared this intensely about performance, there are more than a few other things they could do to speed everything up. The switch from Apache to NGINX for one. I know that this takes many more developer/sysadmin hours, but if they really cared about a tens of milliseconds then it is definitely something they'd invest in. NGINX has quite a lot of support and is very stable, as well as generally known to much faster than Apache in most cases [1]. It's also not like NGINX is a hipster/unused server, it has quite a respectable share of the 'market' [2].

I also noticed on this page that they docwrite a script (probably to force it async?). This type of 'hack' is terrible for performance [3]. You could just add the 'async' attribute to the script tag and actually move it in the html and reduce the cycles wasted by a hacky solution.

[1]: https://www.rootusers.com/web-server-performance-benchmark/ [2]: http://news.netcraft.com/archives/2016/03/18/march-2016-web-... [3]: https://www.stevesouders.com/blog/2012/04/10/dont-docwrite-s...

Re: Enabling Secure HTTP for BBC Online

#37

Post by 0x0 » Thu, Jul 14, 2016, 4:32 PM UTC

reedloden wrote: post #26

> There are always practical limitations to site-wide technical changes, and HTTPS Everywhere is no different. Sites and content we consider ‘archival’ that involve no signing in or personalisation, such as the News Online archive on news.bbc.co.uk, will remain HTTP-only. This is due to the cost we’d incur processing tens of millions of old files to rewrite internal links to HTTPS when balanced against the benefit. N…

I don't think you can just run 'sed' on any random iOS app, any random symbian app, any random smart-TV app, some other guy's service that hits your APIs and feeds, and so on... :)

Re: Enabling Secure HTTP for BBC Online

#38

Post by _uhtu » Thu, Jul 14, 2016, 4:32 PM UTC

blowski wrote: post #17

_uhtu wrote: post #14

Earlier quoted context omitted.

Can you point out some other major sites used by the general public which have spent the last few years without site-wide SSL to back up your claim?

I can do better than that - I can give you a report published by Google in March 2016 which listed lots of them. https://www.google.com/transparencyreport/https/grid/ For example, the following are all in the world's top 100 websites and none of them support any form of HTTPS. The link includes quite a few more. * alibaba.com * ask.com * ask.fm * baidu.com * cnet.com * cnn.com * dailymail.co.uk * ebay.com * globo.com…

That's scary honestly. Thanks for sharing at least.

Re: Enabling Secure HTTP for BBC Online

#39

Post by reedloden » Thu, Jul 14, 2016, 4:34 PM UTC

0x0 wrote: post #37

reedloden wrote: post #26

> There are always practical limitations to site-wide technical changes, and HTTPS Everywhere is no different. Sites and content we consider ‘archival’ that involve no signing in or personalisation, such as the News Online archive on news.bbc.co.uk, will remain HTTP-only. This is due to the cost we’d incur processing tens of millions of old files to rewrite internal links to HTTPS when balanced against the benefit. N…

I don't think you can just run 'sed' on any random iOS app, any random symbian app, any random smart-TV app, some other guy's service that hits your APIs and feeds, and so on... :)

Now, that could be a valid issue, indeed, though not sure for how long I care about those devices continuing to work without any valid upgrade path... Using things like HSTS and CSP's `upgrade-insecure-requests` would help here for clients that do support it.

Re: Enabling Secure HTTP for BBC Online

#40

Post by michaelt » Thu, Jul 14, 2016, 4:37 PM UTC

reedloden wrote: post #26

> There are always practical limitations to site-wide technical changes, and HTTPS Everywhere is no different. Sites and content we consider ‘archival’ that involve no signing in or personalisation, such as the News Online archive on news.bbc.co.uk, will remain HTTP-only. This is due to the cost we’d incur processing tens of millions of old files to rewrite internal links to HTTPS when balanced against the benefit. N…

  haven't people written tools to help with this?

Let's say you have a web page with a javascript slippy map that imports openlayers from a CDN; and openlayers then retrieves map tiles from openstreetmap.

If you serve that page over https but the javascript CDN url is http, the javascript library won't load. And if the js CDN supports https and you switch to it, the library might still compose a http URL to retrieve the map tiles - causing some browsers to block the tiles as mixed content. Other browsers are willing to load http images on https pages and will work. Unless the tool understands how the map library composes its URLs, someone will have to fix this manually.

To detect bugs like that automatically, after changing to https you'd have to spider every page in your site with several different browsers / browser configurations looking for errors and bad links. And if your archived site had a bunch of errors and bad links to start with, you'll need some way to compare the before-and-after error reports too.

TLDR: It can be more complicated than you think.