7 ms·
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 chan
by adwhit 8y ago
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.pdf https://www.nspw.org/2009/proceedings/2009/nspw2009-herley.p...
- MichaelApproved 8y agoCpanel 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.
- tudelo 8y agoPretty sure you can use certbot and just run like... a few commands. Even easier than setting up Nginx.
- deleted 8y ago[deleted]
- adwhit 8y agoThe 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.
- untog 8y agoGiven that Chrome now throws a "not secure" message against your URL when it's HTTP makes it more than worth two minutes, IMO.
- hrktb 8y agoIt'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.
- mr_toad 8y agoCertbot has a issue with dependencies that I’d rather not deal with on a production server: https://github.com/certbot/certbot/issues/1301 https://github.com/certbot/certbot/issues/1301 Not to worry though, there are over 100 other ACME clients that I can choose from.
- kuroguro 8y agoThere'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).
- pcnix 8y agoIt'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.
- modzu 8y agowait, what? if you can get nginx running you can get lets encrypt running
- tialaramex 8y agohttps://www.usenix.org/system/files/conference/usenixsecurity17/sec17-krombholz.pdf 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.
- Ajedi32 8y agoFWIW, Apache is getting native support for ACME certs: https://letsencrypt.org/2017/10/17/acme-support-in-apache-httpd.html 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.
- patrickmcmanus 8y agoThat was one of my favorite Mozilla Open Source Support projects!
- th3l3mons 8y agoThe 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)?
- lostapathy 8y agoExactly this. If you can't imagine the harm in that - pretend they are injecting NAMBLA ads or Goatse-type images into your blog.
- saryant 8y agoI've also seen airlines do this with their in-flight wifi. Looking at you, Icelandair.
- squeaky-clean 8y ago> 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.
- Aaron1011 8y agoI believe you're think RFC 6018: https://tools.ietf.org/html/rfc6108 https://tools.ietf.org/html/rfc6108 Related HN discussion: https://news.ycombinator.com/item?id=15890551 https://news.ycombinator.com/item?id=15890551
- mrfredward 8y agoMy 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.
- crtasm 8y agoHigh bill because someone walked in and watched TV for three days? (I'm guessing it was actually due to heating/aircon)
- dragonwriter 8y ago> 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.
- mrfredward 8y ago>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.
- lostapathy 8y agoNo, the worst case scenario is that the user gets compromised/infected and becomes part of a botnet that attacks the rest of us.
- deleted 8y ago[deleted]
- trash_panda 8y agoThis 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.
- jakelazaroff 8y ago> 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.
- trash_panda 8y agoHoly, 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.
- plopz 8y agoI 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.
- jakelazaroff 8y agoIMO 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.
- eridius 8y agoYou 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.
- kelnos 8y agoAs 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.
- Groxx 8y agoThe 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.
- linuxftw 8y agoNo need to worry. That static site is probably loading dozens of javascript libraries and mining every click on the page anyway... err, analytics.
- derefr 8y agoYou know what's even easier than a simple Nginx server setup? A simple https://caddyserver.com 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.
- yboris 8y agoThank you for sharing Caddy -- haven't heard of this until your comment. Cheers!
- Area12 8y agoI'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.