The Guardian has moved to HTTPS | Hacker News Reader

The Guardian has moved to HTTPS

theguardian.com

103 pointsrobin_reala60 comments

It's always good to see more web sites switching to HTTPS. I can't help thinking about something I read on Twitter a couple of years ago, and I wonder if they are mitigating the risk:

"I'm all in favor of news sites using HTTPS, but I assume they're also going to pad all their articles to a uniform length?" -- https://twitter.com/matthew_d_green/status/53504312624809574...

this is called "moving the goalposts", right?

An interesting attack and something that we'll consider. HTTP/2 should add a significant amount of noise to this, but ultimately adding random padding to every response or padding that compresses to a consistent length would be the best solution.

The important thing to hide on news sites is not so much what you're reading (who cares, it's public news and clicking through a link means nothing), but rather hiding your username for the comments section.

I am slightly worried that a lot of public Wifi seems to be unable to redirect you to the login page (think Starbucks) if you visit https:// sites. The Guardian was my go-to for such situation so that I could login and get online.

I'm not sure how these redirects work (DNS? Inserting JS into the page?) but it seems to be a common problem.

If you go to the Starbucks website the Accept Terms Of Service redirect seems to work fine... that's what I've usually done anyhow (shrug).

Starbucks.com is https and I'm pretty sure it didn't work in Japan. YMMV.

They usually work by MITMing your connection to whatever site you're trying to visit and serving an HTTP redirect (maybe 307?) to the captive portal page.

As a substitute for The Guardian, maybe try http://example.com?

But eventually all the sites will be HTTPS - I've no idea what non-techy users do when faced with this apparent brokenness.

I’d be surprised if example.com goes https-only. Regardless, if all sites go https only then free wifi providers will have to come up with some other way of redirecting you to their signup page.

Ran into this with Southwest's wifi this week. HSTS preloading makes it worse too. No dice with Google, Facebook, my website, etc. Just lots of error pages until I figured out what was going wrong.

http://neverssl.com/

There seems to be some protocol by which operating systems automatically launch the login page upon connecting to the WiFi network. Unfortunately, it seems to fail pretty often and probably doesn't work for bridged connections.

On Nougat it seems to work flawlessly most of the time. I wonder what the protocol is. Maybe a request to the access point's DNS server to see what IP is returned and then connect to that?

There's no standard protocol in widespread use. Typically operating systems attempt to fetch a known resource when connecting to a new Wi-Fi network, and if it redirects, then they treat the destination as the captive portal sign-in page and display it with special chrome / modally. The URL each platform attempts to load varies by vendor and version.

Do you have any links to resources or know what name(s) people use when talking about this strategy? I'd be interested to know which URL Debian attempts to fetch, but I'm not sure how I'd even begin to search for the answer.

"Captive portal detection"

And here's your answer: http://network-test.debian.org/nm

Thanks!

cf. http://blog.erratasec.com/2010/09/apples-secret-wispr-reques...

My understanding is that this is just the OS trying to fetch a known page over HTTP and, if redirected, assuming it got a login portal and presenting it to the user.

I assume this can continue "working" (with your noted caveat that it doesn't even always work today) forever, as the process that checks doesn't need to understand HSTS or to ever try HTTPS, regardless of what actual web browsers start doing.

Basically, they try to phone home and if it redirects, they assume it's a captive portal login page. It's a sort of controversial practice, because it means that the OS vendor now always knows where and when you're accessing the internet.

ha, American here and I use usatoday.com for that. But neverssl.com is great find.

In-flight wifi on United has solved this problem by giving you an explicit page to go to. They say to go to unitedwifi.com to activate the connection.

The more websites on HTTPS the merrier. It's interesting that they mention being able to use new HTML/JS features that are now only available over HTTPS. That's one way to push more people for HTTPS even if they don't care about the privacy/security reasons.

So what's involved in compromising a site using HTTPS? Off the top of my head, you would have to have control over a trusted CA, and the ability to MITM a connection to the site. Probably not plausible for bedroom hackers, but seems trivial for state actors.

Do browsers offer any kind of certificate pinning for arbitrary sites? It seems strange that this is a default feature in ssh but not https.

HTTPS doesn't provide any protection to the website, it can hinder MITM attacks against modern browsers and aware users, but it doesn't reduce the attack surface on the website (in fact it actually increases it).

As for certificate pinning, some browser do e.g. I'm pretty sure that Chrome has certificate pinning for at least some google services.

Also HSTS with HPKP (HTTP Public Key Pinning) can be used to further increase the resilience of HTTPS services against MITM attacks (both local and network adjacent).

That said if an adversary is capable of doing even basic network adjacent attacks they can still do a redirection via DNS which is why it's important to not have HTTP support only or have a fully enforced redirect which will likely to get the target stuck on a redirect loop.

For DNS redirection attacks all they need to do is to be faster than the DNS responder or poison the local DNS cache.

HTTPS stops MITM except for nation-state attackers.

How does it increase the attack surface?

On the website?

An additional library e.g. OpenSSL (heartbleed), HTTPS crypto attacks (e.g. beast), an additional business processes that can be compromised both from the CA/issuers standpoint and from the website admin POV, and an additional resource to protect and securely distribute(private keys).

All and all you now have a greater attack surface as an entity, it doesn't mean that you shouldn't use HTTPS, but as far as risk management goes things change.

You as a user aren't affected unless you erroneously implicitly trust encrypted traffic considerably more than unencrypted one.

HTTPS also doesn't stops MITM attacks from non-state actors. People trust untrusted certificates, the certificate supply chain can be easily poisoned as time and time again we've seen that everyone and their mother managed to make CA's issue certificates under false pretences or otherwise erroneously and DNS / packet racing attacks still can work unless the website implements HTTPS strictly.

> An additional library e.g. OpenSSL (heartbleed), HTTPS crypto attacks (e.g. beast), an additional business processes that can be compromised both from the CA/issuers standpoint and from the website admin POV, and an additional resource to protect and securely distribute(private keys).

If these things are attacked, your security is not worse than HTTP.

HPKP and HSTS fix the problems you've described.

Again you are talking about 2 different attack vectors here, the GP was talking about compromising the website, an attack against the traffic between the website and the client does not compromises the website in any case.

And no if these things are attacked, at least as far as the library goes things aren't no worse than HTTP because it's a completely different threat scenario which can actually compromise the website/host rather than just poison a single client session.

For example https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6309 which poentially allows for RCE if you use a vulnerable version of OpenSSL exposes your website to completely different threats than if you would only use HTTP, not worse, not better just an additional and quite different threat.

This is why when you implement HTTPS or any other additional service you need to understand how it changes the attack surface of your service from both a technical and operational perspective.

Actually heartbleed was a lot worse than using HTTP: attacker could steel everything in the RAM of the server with vulnerable OpenSSL.

I don't buy that unencrypted traffic is equally trustworthy.

Encrypted traffic cannot easily be snooped by a man in the middle. It's arguably the entire point of HTTPS. With HTTP, I have no hints, much less guarantees, that the website I'm talking to is actually who it says it is. There is no mechanism whatsoever to establish trust, and my traffic is up for easy analysis.

HTTPS may not fix that problem completely (CAs are the biggest weak point) but it does wonders to solve MITM type snooping of my traffic (a boon to me, as a user) and has the mechanisms in place for me to inspect the certificate chain if I need to be sure of the server I'm communicating with. I agree with a great many of your criticisms against the standard and feel like CAs in particular need to be re-thought, but don't dismiss the entire technology because you assume that the "user" is too stupid to know how to use it.

>I don't buy that unencrypted traffic is equally trustworthy.

Neither do I, which is why I never made any such claims. Encrypted traffic even in ideal circumstances can and is equally untrustworthy especially under certain threat models ;)

> HTTPS stops MITM except for nation-state attackers.

Technically yes, but in practice no.

Sure, you can't MITM a running HTTPS connection. But in HTTPS without HSTS it's easy to transparently stop users getting to HTTPS in the first place, and unless they reliably check the URL bar and verify they have a cert and exactly the right domain then that gives you almost as much damage as a MITM, super easily. We can all agree that users are terrible at constant vigilance, and attacks like this are surprisingly practical.

MITMing HTTPS sites that you browse to directly:

* You type "site-without-hsts.com" into your URL bar. * Your browser makes an initial plain HTTP request to site-without-hsts.com, and instead of getting an HTTPS redirect I MITM you, and just proxy the plain HTTP to the real HTTPS-only site. * I see and/or change everything on your 'secure' site. Game over.

301's sort-of protect you here, but a) you don't want to user security to depend on browser caching, b) that doesn't work for the first load of a site, and c) if I'm running a wifi hotspot, it's reasonably easy to get people to clear their caches before you let them log in, since it's a fairly standard technical fix now.

Alternatively, MITMing HTTPS sites reached through some other page:

* You load any plain HTTP page while browsing, on route to a secure site. * I MITM the plain HTTP, replace 'https' with 'http' in all links in the page, and MITM every subsequent page as above, proxying through to real HTTPS sites where required. * I see and/or change everything on your 'secure' site. Game over.

Functionally, if you have any insecure step in your browser session, I can stop you reaching the secure step, and if you're not carefully paying attention you won't notice. Sometimes, sure, you might, but most of the time you won't, and 99.9999% of the time your average computer user won't ever check. HTTPS coverage is getting better, but I suspect the vast majority of browsing sessions still go through an insecure step somewhere along the pipeline.

HTTPS doesn't fully protect your users from MITMs. Add HSTS though (so the browser will refuse to ever make a plain HTTP request to your HTTPS site), and you get substantially closer.

BTW, why can't browsers try HTTPS first and then fallback to HTTP?

I agree with you.

At some (hopefully in about a year) we hope to list theguardian.com in the preloaded HSTS list that ships with the browsers. This would prevent many of these attacks. Unfortunately this is some time away as there are a handful of other subdomains on theguardian.com that are not yet HTTPS (you can only preload a domain along with all of its subdomains).

We'll also continue to look at key pinning, although that's also some time away due to the increased burden of certificate management (essentially we'd need to have at least two valid certificates, one kept offline, at all times to mitigate against another heartbleed or similar attack).

A Google search yields https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning

Looks good, but extremely limited browser support.

Is Firefox and Chrome "extremely limited" support? Sure, it isn't supported by many browsers, but it isn't rare either.

The iPhone browser seems a major exemption.

While HPKP looks good, I really wouldn't implement it. Too dangerous for big sites in it's current form.

Ivan puts it better than me: https://blog.qualys.com/ssllabs/2016/09/06/is-http-public-ke...

"what's involved in compromising a site using HTTPS?"

It just takes the user clicking through some scary prompts, which they'll do if they're unconcerned or desperate enough to get to whatever website they're trying to reach.

> which they'll do if they're unconcerned or desperate enough to get to whatever website they're trying to reach

This is actually an enormous percentage of users. Google's research on real live Chrome users suggests up to 70% of those big full page HTTPS security warnings are being clicked through: http://static.googleusercontent.com/media/research.google.co...

> It just takes the user clicking through some scary prompts

If you turn on HSTS, you actually stop this completely. Chrome and Firefox will not allow you to click through the prompt for an HSTS site - you're just blocked.

Our HSTS header is set with an expiry of a year. Provided you've visited the Guardian in the last year then you will not be able to click through an invalid certificate, nor can an attacker intercept an HTTP connection as none will be made.

At some stage we hope to list theguardian.com in the preloaded HSTS list that ships with the browsers, but unfortunately this is some time away as there are a handful of other subdomains on theguardian.com that are not yet HTTPS (you can only preload a domain along with all of its subdomains).

https://observatory.mozilla.org/analyze.html?host=www.thegua...

Still getting a 50/100... somehow that's a "C" on the Mozilla curve.

"The reasons for our move"

If they wrote this 5+ years ago, kudos. Now, today... seems a bit like a very bad (and very late) ad campaign or excuse.. And in all fairness, it could have summarized, as 'we cared more about money then serving https to our readers'

The primary reason is SEO:

  It also gives us other benefits such as a potential increase in
  search results. For the reasons mentioned above Google has
  announced that it will favour https content. It is also helping
  us decipher traffic from secure and ‘unknown’ referrers.

As far as I know, they are one of the few big media outlets to support https. So yes, this should have been done earlier, but kudos to them for pioneering this in their field and for publishing a short instruction manual for whoever else is planning this.

I'm not surprised that they are worried about the financial impact of https on their (very modest) revenue. It's a big investment for an industry struggling financially.

The BBC is in the process of making the switch, and sometimes blog posts are published about progress:

http://www.bbc.co.uk/blogs/internet/entries/f6f50d1f-a879-49...

RT switched to HTTPS a while back. https://www.rt.com/

> I'm not surprised that they are worried about the financial impact of https on their (very modest) revenue.

I don't see anything to that effect in the article.

I don't consider a SSL certificate as a big investment? There is no ROI on ssl usage. Nor do they break the bank; There is a 'not running away because you don't' return, which in the end hurt more. NY times SSL capable since 2014, also late, but already 2 years earlier then this website.

time to review this superuser answer and ponder some deep questions about public wifi's http://superuser.com/questions/1132148/how-do-you-force-publ... and new vocab word of the day is "captive portal"

The Guardian uses Fastly CDN as a result the TLS certificate is Fastly's SAN certificate, which also has over 150+ DNS entries to cover. Just thought it's interesting to point out.

$ openssl s_client -connect theguardian.com:443 | openssl x509 -noout -text | grep 'DNS:' | tr ', ' '\n' depth=1 /C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2 verify error:num=20:unable to get local issuer certificate verify return:0 DNS:i.ssl.fastly.net DNS:.am-autoparts.com DNS:.am-autopartsqa.com DNS:.i.ssl.fastly.net DNS:.s.tmol.io DNS:4ormat.com DNS:.4ormat.com DNS:500px.net DNS:.500px.net DNS:500px.org DNS:.500px.org DNS:abtasty.com DNS:.abtasty.com DNS:api.yerdle.com DNS:biomedcentral.com DNS:.biomedcentral.com DNS:bliyoo.bruna.nl DNS:cdn.mmgcache.net DNS:cleverbot.io DNS:.cleverbot.io DNS:collective-media.net DNS:.collective-media.net DNS:decalgirl.com DNS:.decalgirl.com DNS:engagesciences.com DNS:.engagesciences.com DNS:famous.co DNS:.famous.co DNS:fitbit.com DNS:.fitbit.com DNS:format.com DNS:.format.com DNS:github.app.secretcdn.net DNS:.github.app.secretcdn.net DNS:global-pop.tumblr.com DNS:.global-pop.tumblr.com DNS:goodeggs.com DNS:.goodeggs.com DNS:grindr.com DNS:.grindr.com DNS:guim.co.uk DNS:.guim.co.uk DNS:hackster.io DNS:.hackster.io DNS:harveynichols.com DNS:.harveynichols.com DNS:help.optimizely.com DNS:huevosbuenos.com DNS:.huevosbuenos.com DNS:img.society6.com DNS:.img.society6.com DNS:inverse.com DNS:.inverse.com DNS:kilmer.io DNS:.kilmer.io DNS:kindsnacks.com DNS:.kindsnacks.com DNS:learn.optimizely.com DNS:live.cf.public.springer.com DNS:.live.cf.public.springer.com DNS:logoscdn.com DNS:.logoscdn.com DNS:m.au.vjukebox.com DNS:m.ca.vjukebox.com DNS:m.uk.vjukebox.com DNS:m.us.vjukebox.com DNS:maps.tmol.co DNS:mapsapi.tmol.co DNS:mapsapi.tmol.io DNS:mapsint.tmol.co DNS:mapsintqa.tmol.co DNS:mapsqa.tmol.co DNS:meerkatapp.co DNS:.meerkatapp.co DNS:modafinilcat.com DNS:my.ticketmaster.ca DNS:offerpop.com DNS:.offerpop.com DNS:ogol.io DNS:.ogol.io DNS:optimizely.com DNS:performance.service.gov.uk DNS:.performance.service.gov.uk DNS:preview.performance.service.gov.uk DNS:.preview.performance.service.gov.uk DNS:production.performance.service.gov.uk DNS:.production.performance.service.gov.uk DNS:q-static.com DNS:.q-static.com DNS:qa.cashstar.com DNS:.qa.cashstar.com DNS:reissdev.com DNS:.reissdev.com DNS:s.sellocdn.com DNS:.s.sellocdn.com DNS:s2.tmol.co DNS:s2.tmol.io DNS:scanscout2.com DNS:.scanscout2.com DNS:screenshot.click DNS:.screenshot.click DNS:skedge.me DNS:.skedge.me DNS:snapshot.raintank.io DNS:spotfront.mathtag.com DNS:springer.com DNS:.springer.com DNS:squarecdn.com DNS:.squarecdn.com DNS:staging.performance.service.gov.uk DNS:.staging.performance.service.gov.uk DNS:static.awesomeom.com DNS:subscribe.theguardian.com DNS:teamtreehouse.com DNS:.teamtreehouse.com DNS:theguardian.com DNS:.theguardian.com DNS:timeout.cat DNS:.timeout.cat DNS:timeout.com DNS:.timeout.com DNS:timeout.es DNS:.timeout.es DNS:timeout.fr DNS:.timeout.fr DNS:timeoutkorea.kr DNS:.timeoutkorea.kr DNS:timeoutmexico.mx DNS:.timeoutmexico.mx DNS:u.sellocdn.com DNS:.u.sellocdn.com DNS:venue.tmol.co DNS:venue.tmol.io DNS:venueint.tmol.co DNS:venueqa.tmol.co DNS:vjukebox.com DNS:.vjukebox.com DNS:www.alarmgrid.com DNS:www.edgee.com DNS:www.freshbooks.com DNS:www.graspwise.com DNS:www.modafinilcat.com DNS:www.msdayofgiving.org DNS:www.neste.com DNS:www.optimizely.com DNS:www.optimizelystaging.com DNS:www.reiss.com DNS:www1.ticketmaster.ca DNS:www1.ticketmaster.com DNS:xkcd.com DNS:*.xkcd.com ^C

We're working on it!

We're in the process of switching to a dedicated certificate that only contains Guardian properties.

Great! Now if only they would move back to the center...

Just out of curiosity, where would you place them currently?

Left of center?

Their news coverage is good (SportsDirect being a case in point). Its the opinion pages which makes me wonder.

Yeah I would agree that they're left of centre. But I would say that they have moved more to the right in the last few years.

I guess that probably says something about our politics too :-)

Interesting that you believe that they've moved right. I sorta think they've (particularly the opinion pages) moved left, especially with regards to social issues.

> I guess that probably says something about our politics too

I was gonna agree with you and then I thought that in fact, it should be possible to place someone's politics on a scale that is independent of the observer. Keynesian is to the left of supply-side economics for instance. Social issues are on their own scale.

Reply on news.ycombinator.com