Sounds fine for shopping, online banking, user authorizations. But for every website? If I'm a blogger/publisher or have a brochure type of website, I don't see point of the extra overhead.
Update: Thanks to those who answered my question. You pointed out some things I hadn't considered. Blocking the injection of invisible trackers and javascripts and ads, if that's what this is about for websites without user logins, then it would help to explicitly spell that out in marketing communications to promote adoption of this technology. The free speech angle argument is not as compelling to me though, but that's just my opinion.
Without HTTPS, any MitM could inject ads, malware, or simply manipulate any content on your blog. TLS isn't just useful to encrypt private data, it also makes sure what you see is what the site owner wanted you to see. With http/2, the overhead is minimal and with TLS 1.3 it might soon be gone completely (since it's probably going to add a mode that avoids multiple round trips for the initial TLS handshake; encryption itself isn't really an issue nowadays with AES-NI, etc.)
And this isn't a theoretical threat either, actual ISPs have been injecting adverts, trackers, and other content into third party websites. Even in the US.
They still do that, they haven't be sued, and they haven't lost. One of those articles is from May this year. And as far as I know they're still injecting trackers into the HTTP headers of mobile traffic to this day. It is opt out.
I'm not going to waste my Friday night looking up old lawsuits to save a few HN reputation points. But I can tell you, I remember first reading about this stuff ~1999 when ISPs wanted to get their content in front of the Internet, but I don't remember the exact details. I've been following Boardwatch, WIRED, Techdirt, Digg, Slashdot, TechMeme and TechCrunch since then and consider myself relatively informed. I thought we were beyond this by now, 15 years later, but apparently I was wrong!
Well if you're blogging about something important, you don't want the government to MITM your page and edit it without your permission. Imagine if the government did that for a major news site - lots of control.
Nope, but there is no reason to think that a sufficiently motivated and well funded party wouldn't be able to pull it off. If governments can build things like stuxnet then a project like this should be relatively straightforward.
It should be the default because if only those people who need the protection use crypto, they stick out like a sore thumb, negating much of the protection, if not actually increasing the risk. If only political activists (say) use GPG, then the easiest way to get rid of the opposition in a country is to round up everyone that's been seen by deep packet inspection machines sending a GPG-encrypted message, which is rather trivial to automate.
Also, you just don't have a clue who is watching your traffic and what they are using it for, and machines are only getting more powerful, enabling ever more advanced analysis of your communication (think of someone intelligent, with a brain, watching everything you do, or rather watching everything everyone does, but with sufficient intelligence to pay as much attention to you as a single person could watching a single person - that's probably not an accurate model (yet), but still probably closer than what you imagined). Imagine a representative from your internet provider or the government ringing at your door - if you wouldn't let them in to sit next to you/follow you whereever you go around the clock, you probably would also prefer encrypted communication if you understood what one can do with your internet traffic.
Well there is very little cost for what it offers. It takes developers a few days or more likely now a few hours to setup and only serves the viewer better. It affords the visitor some level of trust that the site hasn't been tampered with and their login credentials aren't being siphoned off for example.
If you are the author of a blog (with comments disabled), and you don't care if your message is manipulated, then thats your choice. But before you know it vanilla http will be blocked in browsers, and you'll need to make the change anyway.
Personally, I do every project through HTTPS only because a client had an atrocious corporate HTTP proxy cache that ignored expiry headers and assumed two files were equal because they had the same name or some shenanigans. Dealing with the endpoints (server and browser) is enough for me, thanks.
For a while, my ISP was using some sort of transparent proxy cache, which for some reason tended to stall HTTP connections (stuck in SYN-SENT IIRC). There were days when the only sites I could access were the ones using HTTPS, since the transparent proxy cache didn't touch them.
The most advertised gain from using TLS is security, but to me an equally important gain is not having to deal with broken middleboxes.
The big thing for non-login websites is the threat of the information being tampered with on the line. Someone could easily MitM your http connection and insert whatever they wanted into the website, making you think that website had said it.
Sure but what's the intent? If I own a lawncare business, or any business, seriously--what can the hijacker do? Change the phone number? Change the map?
Introduce arbitrary code and data for your User Agent to execute and decode.
This can be something as simple as data alteration to mislead the target or disrupt his communications. However, if the attacker has some Sweet 0-Day Sploit, (or some old-and-busted 'sploit that works on the target's old-and-busted User Agent) they can MitM any HTTP session and use that sploit to do $SOMETHING_NEFARIOUS.
This isn't theoretical. The NSA slides spoke of active attacks against older versions of Firefox shipped in the Tor Browser Bundle. Similar attacks making use of WebRTC to leak data were proposed and fixed, posthaste.
An additional benefit of HTTPS is the reduction of metadata provided to passive attackers. (HTTPS sessions encrypt the names of the resources requested from the remote server. There are still ways to get an idea of what's being requested, but all an adversary knows for sure is that you're talking HTTPS to a particular web server.)
Ignoring all the protections that HTTPS-by-default gets you and everyone else, bear in mind that most browsers will support http/2 only over TLS. So if you want the advantages that gets you (significant for a brochure type of website), you will need https anyway.
I'm wondering about that too since I'm running some very low power web servers (ESP8266) and I don't know if HTTPS is even feasible on these devices. I hope HTTPS become the preferred default but is not made mandatory by browser vendors.
Sounds fine for shopping, online banking, user authorizations. But for every website? If I'm a blogger/publisher or have a brochure type of website, I don't see point of the extra overhead.
Update: Thanks to those who answered my question. You pointed out some things I hadn't considered. Blocking the injection of invisible trackers and javascripts and ads, if that's what this is about for websites without user logins, then it would help to explicitly spell that out in marketing communications to promote adoption of this technology. The free speech angle argument is not as compelling to me though, but that's just my opinion.