Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

ISPs and coffee shop wifi injecting ads into webpages wasn't a theoretical attack, but I'm more curious: Which barriers with HTTPS are you referring to?


Only a few of the barriers presented by HTTPS:

Clock sync would be a requirement for access.

A recent device would be a requirement for access (not everyone can afford a new one).

Site admin keeping up with certificate registration would be a requirement.

Approval from the centralized certificate authority would be a requirement.

Server's self domain name matching accessed domain name would be a requirement.

These are all real scenarios where real people can be denied access to information that is crucial to them, up to the point of survival.

Just a few of the reasons why all my websites still allow HTTP.

HTTP is also way faster on slow connections.


You are, of course, free to run your website however you chose. But if those are the first objections you have, I'd be happy to read and address your full list.

> Clock sync would be a requirement for access.

If you're on the Internet, then unless you have a religious reason against the NTP protocol, setting the time accurately is not a problem.

> A recent device would be a requirement for access (not everyone can afford a new one).

It's a fair point to raise, but if we target TLS 1.2 (1.0 and 1.1's been deprecated, and 1.3 support still isn't everywhere.) then all Android phones with Lollipop, which was released in 2014, and up support TLS 1.2. (The shittiness of cheap Android devices means phones from back then don't work anymore, so low end phones from a few generations back are more accessible than a Nexus 6 (Google's launch pre-Pixel phone for Lollipop) would be.

If you're on a laptop/desktop, there are no released versions of Chrome on Windows that are so old they don't support TLS 1.2. This includes the now-unsupported XP SP2+ and Vista. That dates back to 2007. On Apple desktop/laptops, Mac OS X Snow Leopard (10.6) and greater have Chrome support for TLS 1.2. I'm away from my 2012 Macbook Pro right now, but it's on something newer than 10.6.

So if your audience would have to be on 9+ year old Android phones, 16+ year old Windows computers, or a similarly old Apple computers (which is entirely possible), but they've already been excluded from the running any credit card transactions on the Internet (and have been since June 2018 due to PCI forcing the deprecation of TLS 1.0 and 1.1).

> Site admin keeping up with certificate registration would be a requirement. > Approval from the centralized certificate authority would be a requirement.

Let's Encrypt, which has been around since 2014 just handles all that nonsense, with automated support for most of the popular web servers. It's free (gratis) even for commercial and for-profit purposes, and is sponsored by the EFF, among other organizations.

> Server's self domain name matching accessed domain name would be a requirement.

That's not the case, unless you're using bespoke web server software. Name-based virtual hosting is quite common, even in the TLS world, and lets the client specify which service it would like to connect to. The web server is then configured to reply with the hostname that was asked for, and multiple services, (with different names) can be run on the same server on the same IP address.

Regardless though, if the primary failure mode you're worried about is users being denied access to your site, they can always just click through the warning to access underlying site. They'll be used to it from using the rest of the web (eg Wikipedia switched over to be exclusively HTTPS in 2015, and Chrome started labeling HTTP as insecure Jan 2017).

As for speed, I was in South East Asia recently, and found that cities had LTE and 4G, but while there were stretches of no service (which exists even in a rich nation like the USA), what surprised me was finding EDGE cell data. If you're that constrained then sure.


Or I can use HTTP with any browser I feel like today, even Netscape


With how most of the internet already looks like without adblocker the difference would probably be impossible to even notice.

Edit: Also around half the pages I currently have open are passing through cloudflare anyway and signed by them, so a third party hijacking the connection to throw in ads is just one business minded CEO away.


I mean, it's not impossible for Matthew Prince, or his successor, or more likely his successor's successor, will just throw away the company by injecting unauthorized ads, but until they actually do, let's not pretend they have?

Cloudflare's customers aren't going to stand for that and will find a new CDN if it was ever shown to be the case that Cloudflare was intentionally altering content they're rehosting. Cloudflare's imperfect, but Prince isn't that dumb, so we're years away from even the hint of that being possible.


> ISPs and coffee shop wifi injecting ads into webpages wasn't a theoretical attack

I run a trivial site via http and I don’t care about isps and coffee shops injecting ads. I’ve never witnessed this myself or known anyone affected, but my site is free and non-commercial so I wouldn’t care if a location did that.

For me, it’s worth the removal of a minor chore to not run ssl. Comically, my host automatically ads ssl every once in a while, then tries to charge me, then breaks ssl.


>I run a trivial site via http and I don’t care about isps and coffee shops injecting ads

What's even more fun is when people inject actual attack code because every major browser executes javascript by default.

Running non-ssl on the public internet is like unprotected sex with a random partner. Maybe because you've not witnessed a STD doesn't mean that there aren't a entire shitload of them out there that present real risks to the population.


It's not theoretical, but it's also not the end of the world, and I would accept it if it meant accessing information that is important to me over not being able to access it at all.


TBH, I'd probably make the same decision. But I don't know if I could ever really trust any information I got via such a connection though. Unless you had a secure connection to the site to use as a reference point, there's always the off chance you hit the right combination of "paypal" and "email address" or anything like an account number or some other thing that trips up the regexp/whatever to trick you into doing the wrong thing. You hope the alteration's as benign as injecting ads (hopefully they're not loud video ones), but that seems far from guaranteed since they're already modifying the page for their own financial gain.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: