Hacker News Reader

Comment by adwhit | Hacker News Reader

When I read things like that, I always think of the paper "The Rational Rejection of Security Advice by Users". [1]

Yes, content injection is bad, but the chance of it happening multiplied by the damage it could cause to your users is probably less than the the effort required to shift a static blog site to HTTPS. (Do not underestimate the leap in difficulty from copy-pasting from an Nginx tutorial to understanding how Let's Encrypt works).

[1] https://www.nspw.org/2009/proceedings/2009/nspw2009-herley.p...

View on HN

As a website visitor, if I don't see HTTPS, I worry -- ever so slightly -- that someone has added some junk to the content along the way, whether it's my ISP or someone with a fake AP in a coffee shop.

I also just don't want ISPs etc. knowing what content I read, in minute detail. No, I don't "have something to hide", but I'm sick of it being so easy for companies to build detailed profiles of my habits and then sell that information to people who want to sell me things. No thanks.

Sure, I could run a VPN all the time. But I think to be a good web citizen, site operators should do all they can to protect their users from malicious actors out there. TLS is just one piece of that.

And honestly, for a modest static blog site, you can set up Let's Encrypt in less than an hour.

The worry is well-founded too, as e.g. tons of hotels I've visited have added junk, even recently, as have some coffee shops (mostly prior to widespread wifi-ification though, I haven't seen it in a while). Airplane / airport wifi has as well.

HTTP feeds this kind of hostile behavior.

No need to worry. That static site is probably loading dozens of javascript libraries and mining every click on the page anyway... err, analytics.

https://www.usenix.org/system/files/conference/usenixsecurit...

A big part of the problem here is that vendors do a _lousy_ job of making this easy. An out-of-box Apache is a fairly good HTTP server, but it'll take you an hour with a good tutorial to make it a half-way decent HTTPS server. Not because HTTPS is inherently difficult but because no relevant expertise was brought to bear in Apache's implementation.

And this isn't just a Unix flavour problem, the IIS handling of TLS is garbage too. Microsoft has documentation that's incomplete or flat wrong, and then you're expected to muddle along following blog posts and video tutorials.

There's a LOT of cargo culting in this space. Almost every instance of the name "Middlesex" you see in an X.509 certificate is a result of this sort of cargo culting, because the postal county of Middlesex ceased to exist before X.509 was even created, but it looks superficially as though you need to specify a "county" in X.509 and so people based in London dredged up Middlesex. And it didn't _break_ anything so they kept doing it without knowing why.

FWIW, Apache is getting native support for ACME certs: https://letsencrypt.org/2017/10/17/acme-support-in-apache-ht...

Hopefully in the future more web servers will implement this, and HTTPS will be enabled as the default configuration.

That was one of my favorite Mozilla Open Source Support projects!

My house is insecure. There's no alarm, so anyone could just smash a window and steal my TV. But replacing my TV costs a lot less than an alarm system, and the risk of being caught for theft is greater than the TV's value.

My landlord sent a handyman in while I was on vacation once, and the handyman didn't close the front door all the way (or try to lock it). My door was open for 3 days, visible from the street, and I don't live in the nice side of town. No one stole the TV, but my electric bill was high that month.

A MITM attack on a static site is definitely possible, maybe even easy, but I'm not going to worry about it unless I have something important to protect.

High bill because someone walked in and watched TV for three days? (I'm guessing it was actually due to heating/aircon)

> A MITM attack on a static site is definitely possible, maybe even easy, but I'm not going to worry about it unless I have something important to protect.

HTTPS doesn't protect the content of your site from being stolen, it protects your users from hostile third-party content masquerading as yours.

>it protects your users from hostile third-party content masquerading as yours

Exactly. What does anyone lose if my anonymous untrusted blog does something untrustworthy for that one reader who has an infected router?

Should I encrypt messages I write on post cards, because I'm afraid a disgruntled postal worker will write "you suck" on the bottom? The worst case scenario here is temporary vandalism.

No, the worst case scenario is that the user gets compromised/infected and becomes part of a botnet that attacks the rest of us.

The same argument applies to littering. It's only going to harm strangers, and you're unlikely to get caught, so strictly from a cost-benefit perspective it seems like a good idea. But if everyone makes that "rational" decision then we all lose.

The problem is that as a community we want to move to where no traffic is unencrypted so the MITM don't have to be trusted. If your static site wants an exception then your static site is going to be where I get hit.

> HTTPS doesn't protect the content of your site from being stolen, it protects your users from hostile third-party content masquerading as yours.

Hostile third party content is only hostile because the client used to access the content does not take client security seriously.

Food for thought: As an end user consumer visiting random, benign websites, I want my browser to be protecting me against hostiles, rather than relying on website operators to do that for me. Just like I run antivirus on my machines instead of relying on everyone else to run it.

Just make it so that your browser doesn't render any http delivered content. Problem solved. From a client point of view that's the only protection you can do. A MITM over http is undetectable for you. With current OSes and hardware there is no sandboxing which will protect you under all circumstances.

If you do this, site providers are forced to switch to https anyway.

> If you do this, site providers are forced to switch to https anyway.

No, if everyone does this, providers are forced to switch. If you do it, it just means you're cut off from some portion of the web.

I guess one problem with risks on the web when compared to your house analogy is that automation can make all the difference there. For the specific MITM example automation might be less likely, but on computer networks, even very unlikely risks can get amplified by the fact that someone can just automate the exploitation.

If automated drones roamed the country looking for open doors to break into, people might be more worried about their home security. Fortunately, the physical world protects us from wide-scale exploitation.

You know what's even easier than a simple Nginx server setup? A simple https://caddyserver.com server setup. Which will automatically provision a LetsEncrypt cert for you, no configuration required.

Or, let's go even simpler: no server of your own at all. Anyone who uses GitHub Pages for their static site, gets an automatic LetsEncrypt cert provisioned for their custom domain if they set one. (I'm honestly surprised that other SaaS hosts that set you up with some service on a subdomain, and allow you to map it to a custom domain, haven't followed along and done the same. It's an easy feature to offer!)

Deploying Nginx is a uniquely-bad example to use right now for TLS ease-of-use. There are all sorts of setups where TLS "just happens"—some of which web-development novices will likely encounter before they become experienced enough to consider "deploying their own web server" to be a sensible action.

Thank you for sharing Caddy -- haven't heard of this until your comment. Cheers!

This is important. Because the discussion around HTTPS tends to train users into think that HTTPS = Web Security.

I totally agree that it's important, and I understand the attack vectors. But what about your outdated WordPress/Joomla installation? What about your default password on your admin site? Those I think are more serious issues, but of course harder to tackle.

To exploit a MiTM you need to be on the same network, this could be achieved through your local-cafe's WiFi or by compromising an internal system of a local network. Not a trivial task I would say. If you manage to pull it off, the impact is contained to that local network.

If you compromise the insecure site directly, you can have an much wider audience and HTTPS won't help you in this scenario.

> To exploit a MiTM you need to be on the same network, this could be achieved through your local-cafe's WiFi or by compromising an internal system of a local network.

Or, say, your ISP injecting ads and tracking scripts into unencrypted pages your browser requests.

Holy, I forgot about that one! You're totally right and I'm surprised it's not one of the main arguments for this push for HTTPS.

I think thats why google has been pushing so hard for https, isps were able to do tracking just as well under http, so google wants to shut that door.

IMO it's really the only compelling argument for HTTPS on sites that don't deal with traffic worth intercepting. Other than that, I agree with you re café Wi-fi, etc: the man-in-the-middle risk is so small and localized that it may as well not exist.

Not only is the coffee shop using an ISP that is likely MITMing you, insecure coffee wifi routers can be exploited at scale to MITM a lot of coffee shops at once.

The other side I would pose is: do you want anyone to alter your responses? I'm currently trying to find the RFC, but I recall an ISP defining an RFC for tampering with HTTP responses in-transit. In addition, I also recall seeing Comcast (I believe) injecting JS to users that they are approaching their plan limits.

Obviously, not the end of the world. But do you want any third party to easily alter the response from your server to the client(s)?

Exactly this. If you can't imagine the harm in that - pretend they are injecting NAMBLA ads or Goatse-type images into your blog.

I've also seen airlines do this with their in-flight wifi. Looking at you, Icelandair.

> In addition, I also recall seeing Comcast (I believe) injecting JS to users that they are approaching their plan limits

This has happened to me. Re-installed Windows on my gaming computer and re-downloaded all my games. By the time I hit 900GB usage, any HTTP page would display a popup with "You have 100GB of data left".

I thought it was malware on the website trying to phish me the first time I saw it.

I believe you're think RFC 6018: https://tools.ietf.org/html/rfc6108

Related HN discussion: https://news.ycombinator.com/item?id=15890551

It's not just about the chance of problems, it's also the fact that browsers are making it very obvious when a site doesn't have https, and this is enough to scare users away.

You don't need to "understand how Let's Encrypt works" to use it. You can still copy & paste from a tutorial in order to set it up.

Cpanel comes with easy to use Lets Encrypt module. Auto-new the certificate and sends optional email alerts each time it renews or fails.

Web hosts are making it easy to use Lets Encrypt, which surprised me. I thought they'd be reluctant to give up the revenue from high margin certificate sales.

This varies a lot from web host to web host.

Not GoDaddy

I've had a quick look at the paper you reference, but my immediate question is ... this was written around 2009. If the costs and likelihood of getting hacked or phished have increased significantly, some of the conclusions of the paper may now be misleading, at least in detail. Has anyone done an update in the last year?

I still like the paper for one good reason ... it challenges IT people to ask the question: what risk am I mitigating with this rule on the users, and is it worth everyone's effort that will go into it? If yes, see if you can impose the rule. If no ... just be sure you didn't get the numbers wrong.

wait, what? if you can get nginx running you can get lets encrypt running

Pretty sure you can use certbot and just run like... a few commands. Even easier than setting up Nginx.

The point isn't that it is particularly difficult (if you know what you are doing). The point is that from a cost-benefit perspective, it probably isn't worth more than 2 minutes of your time, if that.

Given that Chrome now throws a "not secure" message against your URL when it's HTTP makes it more than worth two minutes, IMO.

It's true that certbox is very easy to install and single run on stable machines with full command line access. Then a lot of Paas providers pre-package a let's encrypt feature to allow for simple setup of SSL cert (as simple as checking a checkbox most of the time)

Now certbox in itself is not really simple in my opinion, and one feels it very fast as soon as we fall out of the beaten path. For instance having it run for volatile instances isn't simple, or if the Paas misses the single feature you need (ex: wildcard support on heroku) you'll have to bear all the complexity again on your shoulders.

In particular the base principle is to renew the cert every 30 days, so inherently proper automation and error handling is the first barrier to entry for certbot. That's already a bit further than "a few commands" in my opinion.

Certbot has a issue with dependencies that I’d rather not deal with on a production server:

https://github.com/certbot/certbot/issues/1301

Not to worry though, there are over 100 other ACME clients that I can choose from.

There's always things like CloudFlare? You have to use them as the main NS, but both transfering the domain and enabling HTTPS is a few clicks (properly configuring your server to only be accessible by CF might be harder, but may not be needed in a static site case).

Reply on news.ycombinator.com