Please put yourself in the shoes of someone actually operating a site. Every single issue mentioned in that post only affects end-users. Not a single issue for the operator, who has many other issues that are more urgent such as turning a profit, securing that database that got wiped last week, and writing actual content. Point being that the incentive to force https for a static site for an individual site operator is just not that great.
The sad reality is that http->https redirects are like vaccination. In some specific cases they are needed (such as login pages), but for some it's more about herd-immunity (normalizing https usage and ensuring availability). Mind you that there's a solid argument for allowing self-signed certs to allow encrypted but unauthenticated transfer. This mode allows MitM, yet does protect against the threat model of a passive eavesdropper.
"Please put yourself in the shoes of someone actually operating a site." - I run 8 sites right now and one of them is processing 10,000,000,000+ requests a month. I speak from a position of experience on this topic.
"Every single issue mentioned in that post only affects end-users. Not a single issue for the operator" - so don't care about the user and the risks we expose them to, only ourselves? This isn't really an approach I'm happy taking.
With 10B monthly requests, you speak from a position of having an operations team who spend 40+ hours a week on keeping your site secure (possibly even a dedicated security team?). Most sites do not have that luxury. If you're doing that on your own, then you're far from the average site operator that I'm referring to here. In fact, most everyone on HN is not the average site operator I'm talking about here.
My poorly communicated point is that by using extreme language like "I'm going to hack your static site" dilutes the message and makes average operators less receptive to more advice in the future. Troy does a lot of good work on reducing friction and advocacy, but sometimes he puts out more extreme content like this which makes me worry that it may have the opposite effect.
PS - Do you think the vaccine analogy works? I'd appreciate some advice on how to improve it
Yes. When you make a website your obligation is to your users. Can you imagine any other engineeting field where people were willing to say "well that's a problem for my customers and not a problem for me" and think that was okay?
Let's sum the discussion up - the advantages of HTTPS on static websites is that the content can't be (1) sniffed, (2) manipulated. To which I reply that (1) the person able to sniff your network traffic is also able to see or quite reliably predict what URLs you visit, and (2) if someone is modifying your network traffic specifically, you have much bigger problem than the one that could be solved by HTTPS. And really, each time I hear "HTTPS is secure" I get frustrated, as if people really had no idea how these protocols work.
You're thinking too narrow. Attackers cast wide nets then narrow down the attack to what they've caught in the net. They don't blindly bait individual traps targeting individual users and hope they get a catch.
I'm a hacker at a local Starbucks. I go there every Thursday and use a WiFi Pineapple in my backpack. By naming my WiFi access point similar to the Starbucks' free WiFi I trick a few dozen people a day to connect through my Pineapple instead of the Starbucks provided WiFi. Over a period of a few weeks I log all traffic and devices. I see a number of regulars - many with their own unique browsing habits. I create a few phishing sites to target these unfortunate users who routinely browse at the coffeeshop. Over the course of the next few days I MITM all traffic in the shop and successfully phish a small number of the users. Now imagine a wider net. A collection of compromised networks that don't require my physical presence in a coffee shop and a small team of individuals selecting vulnerable targets based on their browsing patterns.
Neither you nor your users need to be individually targeted by some 3 letter government agency for this attack to work. They only need to be an unfortunate victim and you only need to be too lazy to spend 10-15 minutes setting up a TLS certificate.
This attack is heavily thwarted by sites using TLS certificates. I'd need to get my hands on a number of invalid certificates and even that can be thwarted by HSTS. Now instead of my attack being completely transparent I need to worry about raising suspicion of users browsing https:// sites not getting errors about invalid certificates.
Even on a completely static site one could introduce links if they can manipulate content. Create a fake blog post linking to Reddit asking for support, make up a story that a family member fell ill and please donate to your Go Fund Me. Add a cryptocoin miner Javascript. The possibilities are quite endless when you have full control to manipulate a website and an easy way to make a profit off of someone elses' reputation, audience, and laziness.
The point is, if you're able to manipulate someone else's network traffic, you will be able to modify their DNS traffic as well, and HTTPS won't help with that - you can do all these things you listed and worse.
That's why I cringe whenever I hear the mass propaganda that "HTTPS is secure". It encrypts traffic between the two endpoints, that's it.
To which browsers will warn the user that the certificate is invalid. Something that, if it was an HTTP site, the user would never be made aware of. The user would then need to ignore the certificate warnings at which point you've done your job by having HTTPS - the rest is up to the user to not ignore security warnings, you can't control that part. Having to generate false certificates at scale for an attack on a number of websites is unlikely - even with the Comodo/DigiNotar blunders of the past. Especially when arguments against these attacks are "nobody would attack me anyway" (you're only making it easier for them to target your visitors by not requiring them to jump through a hoop to get a fake cert).
If they send your user to https://dvfjsdhgfv.com (malicious server) instead of https://dvfjsdhgfv.com (your server) the browser will yell at them about the site being insecure. If they try to use http://dvfjsdhgfv.com your user can see that it isn't secure. They would need a fake certificate for dvfjsdhgfv.com to serve with their malicious version of the site. Arguing against the increased security theoretical attacks exist is a bit misguided - especially when certificates have been revoked or CA's been blacklisted/go out of business for this behavior. It's extremely uncommon - there have only been a handful of instances of it occurring/being caught (an important distinction I'm sure you'd bring up). Because of the difficulty in getting an invalid cert signed by a CA they tend to only go after the big fish (Google/Alibaba/Facebook) and hope they don't get caught quickly.
If fake certificates were as common as having an unlocked bike left in central L.A stolen, the argument would be a lot stronger.
>It encrypts traffic between the two endpoints, that's it.
Which is why it is important. The attack is called "man in the middle" and not "man at the ends". Also "mass propaganda"? Propaganda from who exactly?
I don't understand the refusal to implement https, even on static sites. It takes literally minutes and provides additional security to your readers/users. Refusal to do so is laziness at best and maliciousness at worst. I have a personal file host that receives <5 unique views/day, mostly only by friends, and 99% of all traffic only comes from me - I still took the time to set up TLS [1]. It took me under 10 minutes to implement and it was my first time ever doing so. If you expect to have 0 visitors ever why not just use localhost?
> To which browsers will warn the user that the certificate is invalid.
Only if the attacker is very, very stupid. They will happily redirect the request to paypal.com to https://www.xn--paypl-7ve.com (which resolves to https://www.xn--paypl-7ve.com that Let's Encrypt will happily give you a certificate for). The latter looks exactly like paypal.com and has a green padlock - so for an unsuspecting user it's "secure". Only having implemented DoH correctly you could talk about benefits you mentioned, without it it only gives the user a false sense of security. Seriously, people need to be aware of that.
I'm aware of that attack. I'm not sure if you're aware; but the only modern browser it still works against is Firefox.
Chrome patched in in Version 58, Opera patched it not long after. Safari and Edge quickly followed suite (or always displayed the punycode) and I believe IE has always shown punycode. Leaving the only browser with significant user share that's susceptible to this attack being Firefox. At least for users who haven't enabled `network.IDN_show_punycode` in about:config, which is probably most (if not all) users who haven't heard of this attack. Firefox is 6%~ market share - so this attack would fail on 94%~ of your viewers as long as they were paying any attention to the domain. Probably the only way Mozilla will stop dragging their feet in joining everyone else is if someone creates a malicious punycode version of Mozilla with a cert and brings the battle to their doorstep.
This isn't an argument against TLS/HTTPS - this is an argument against Firefox as far as I'm concerned.
To be clear, I'm not against HTTPS at all. I'm against exaggerating by marketing it as "secure", and on insisting on its benefits in the case of static websites, where the case is very weak.
Even if you don't use punycodes, many users are still vulnerable to another type of attack that Let's Encrypt allows:
Even without altering the network traffic many people fall victims to these vicious tricks. The big question here is how much attention do you pay to the address bar.
Nevertheless, the benefits of HTTPS are obvious - there definitely is some protection when the user is sending some data. But for reading a static website, I'm sorry, but I hardly see any benefit. I installed Let's Encrypt on all my websites, but each time I see someone calling it "secure" I really get frustrated.
Users being ignorant (not dumb, just ignorant) doesn't make it less secure. The user ignoring the security benefits or not knowing where/how to check things or being complacent and simply not checking things doesn't make it less secure. I don't have any good metaphors for it - but the problem is 99.98% on the users and 0.02% on "this could probably be better". But even with giant red warnings saying a site is insecure, an absurd amount of users just ignore the warnings and click past them (these users are also not necessarily dumb... too many legitimate programs and websites have conditioned users to just click past warnings and errors to get things to work).
Every single one of those paypal.com phishing URL's issued could be prevented if users understood how domains work. That's asking an awful lot, I know.
Security, much like any other form of personal safety, is equal parts of following protocol and being educated about the dangers. You can't reasonably protect yourself from something you don't know exists and you won't protect yourself from danger if you don't follow protocol (see also: OSHA, lab safety). If the user's understanding is that "https/green padlock = correct site!" then that's terrible, I agree. If the understanding is "https=secure!" that's better but a bit misguided. A secure connection with a malicious server probably isn't what the user has in mind when thinking "secure". But even this misguided approach is a vast improvement over the alternative of "nothing at all" which is why there has been such a strong push towards it. It's quite literally "something is better than nothing" being applied to the general population of users who will probably never be educated enough to protect themselves properly.
By your last reply I had kinda pieced together that your issue is more with the "https=secure!" generalization and not necessarily an "https isn't any more secure than http" argument.
>The big question here is how much attention do you pay to the address bar.
I check the cert for every site I visit - although if I were to become the victim of a MITM attack using DNS spoofing while in the middle of browsing a site and it was targeted directly at me... I don't check the cert on every page load so would probably be fooled for that small window. I also don't lock my front door when I go get the mail, it's a risk I'm willing to take. I understand this makes me in the 0.001% of "maybe a bit too paranoid" users - if there are even that many of us.
>But for reading a static website, I'm sorry, but I hardly see any benefit.
The benefit is very small but still existent. Simply because the time to implement is in the order of minutes instead of days/weeks - I can't see a good argument against taking the time to implement it. Even if it only ever protects a single user.
Well, it's almost nonexistent. To reiterate: if the attacker can only sniff your traffic, they will see what static websites you visit and that's it - whether you use HTTPS or not. On the other hand, if the attacker can modify your network traffic, they will attack you in million ways but using any dynamic website (i.e. requiring some interaction on your part - sending a login etc.). Such an attack on a static website doesn't make any sense when you can do so much damage everywhere else. Can we agree on that? If so, I find the past Google's policy of marking as insecure websites with forms etc. as pretty responsible and I applaud it. Whereas now it looks like blackmail on their part. And I still don't have a feeling I'm protecting any of the users who visit my static websites, I'm just forced to do that because Google rules the Internet now.
Doesn't HSTS thwart this? Unless paypal.com were omitted from the preload list, AND you had never browsed to paypal.com before with that browser, it should refuse to connect over HTTP and the attacker won't be able to issue their redirect. It will try HTTPS instead and immediately fail out of certificate validation.
That wasn't quite what they were talking about. They were talking about IDN Phishing [0] and not http-->https redirection (which is what HSTS is directed towards). But since we're talking about DNS redirection the http:// handshake against the legitimate server never happens, you're only ever visiting a malicious website (which the certificate checks would all fail - except visually in the case of IDN phishing which only works against Firefox users).
No, HSTS relies on the server sending the relevant header to the web browser. In this scenario you have total control over all servers the user connects to.
