Hacker News Reader

But it's not just for personal information.

HTTPS keeps your ISP, your wifi hotspot, a dodgy router, or anything else from injecting ads and tracking information into your pages

HTTPS ensures that the server and information the user is requesting actually comes from you (and not a shady middleman who might give out bad information or just annoy the user with a slightly broken setup)

HTTPS ensures that content isn't being blocked by a bad government actor based on it's content

HTTPS keeps bad actors from injecting malware into your javascript, your images, even downloaded executables (there is "one click" software out there to inject malware into any .exe download it can find on the network in real time)

HTTPS helps protect against "dragnet surveillance". That doesn't just include bad governments, but also an ISP which might build a profile on you based on your browsing habits.

HTTPS treats information as "secure by default". You won't always know what is and isn't "private" to each person. "phrasegenerator.com" might just be a fun game to you, but to someone else it might generate a phrase that could get someone fired, or worse, based on the content of that phrase.

And using HTTPS everywhere means that it's harder to identify "secure" information from "insecure" information. Breaking one HTTPS connection one time for one person and one server isn't "easy", but it's not impossible. Breaking HTTPS for all connections to everyone every time for every server becomes practically impossible.

The overhead is next to nothing, the complexity mostly abstracted away, and with stuff like Let's Encrypt the "maintenance factor" is quickly getting reduced to "fire and forget".

There's no excuse to not use HTTPS any more in my opinion.

>HTTPS keeps your ISP, your wifi hotspot, a dodgy router, or anything else from injecting ads and tracking information into your pages

I suspect this is the main reason Google is so gung-ho about "https everywhere". Because of the popularity of GA, adsense, Double Click, and Google local caches at every ISP...they already have near global tracking. Closing the ISP MITM hole ensures that nobody else does.

Of course, "https everywhere" is good for other reasons, so not complaining...

i agree, though i'm worried about the security it actually offers and what protocols and ciphers are still considered secure.

Next PCI DSS will require most services to be using (and not honoring lower then) TLSv1.2; i'm not sure about what to do when (not matter of if, but when) that is considering no longer secure, TLSv1.3 isnt ready yet from what i understand.

Now that i write this i wonder, are there btw server/client solutions that utilize PGP? E.g. send requests via encryption with public pgp key server and response back to client with public key of client?

I understand your reasoning, but I respectfully disagree. The reason I think its important that ALL sites use HTTPS is that by encrypting everything "important" data becomes indistinguishable from "unimportant" data. This helps the security of the herd by making it more difficult for an attacker to identify what packets to collect and expend their compute resources on. In addition, anything we can do to normalize the use of encryption in such a way as basic crypto knowledge becomes mainstream is a win for the security of everyone.

The fight isn't about a hacker stealing your passwords. The fight is about every single entity on the Internet being hostile towards user privacy with a strong monetary and power incentive to use any and every inch you give them to take a mile. So let's not give them any inches. Encrypt everything using the strongest cipher suites available and the best methods of identity verification we have. It may not be enough, but it's better than giving up and letting the baddies win without a fight.

And to clarify before the inevitable reply points out that HTTPS isn't sufficient by itself to protect user privacy. Yes, I understand that. But it's an important basic building block for doing so.

So should we all browse through a Tor relay when we're looking at cat pictures? Maybe a new protocol can be invented that allows websites to force us to use one? I tend to dislike these dogmatic rules - you have to be aware of the particulars of your situation and design a solution that fits that. For a lot of sites HTTPS seems to me like overkill. If the environment changes where ISPs are routinely injecting ads etc. into your content streams maybe always-HTTPS will make sense, but the cases of that at this point in time seem relatively rare, not worth wrapping the entire internet in an unneeded software layer.

Actually, yes. Most tor users would be greatful if you used tor to browse cat pics, as it strengthens the entire network by having more people using it.

> but the cases of that at this point in time seem relatively rare

What, like the largest US mobile carrier injecting supercookie tracking headers into every unencrypted HTTP request? [1]

Yeah, I guess that's only 144 million people.

[1] https://www.eff.org/deeplinks/2014/11/verizon-x-uidh

If you've ever been on hotel wifi that injected content into every unencrypted page load, you might think this was less about dogma. Such things are cheap and easy to do now, and people will do them more and more where they think there is an advantage. Unless they can't.

Then there is the whole MUTANT BROTH program, which maintains a database of billions of intercepted cookies, and can be correlated with other traffic to identify particular engineers behind a corporate firewall for targeting and exploitation, as was done with Belgacom [1]. To thwart such an attack requires encrypting any request that contains a cookie (or, conversely, never accepting a cookie from an unencrypted site).

The problem is that it's really hard to make judgments about what's "security sensitive" for someone else.

[1] https://theintercept.com/2014/12/13/belgacom-hack-gchq-insid...

> But for a lot of sites (like phrasegenerator.com, one of mine) I'm not sure it makes sense

An attacker could replace your site with anything: ads, viruses, malware, payment prompt. HTTPS also allows you to add HTTP2 support which can lead to faster page loads.

Given that there's a lot of low effort ways to add HTTPS (e.g. Netlify, Cloudflare, Heroku), the question should really be why go with HTTP 1?

For me, the possibility of faster page loads with HTTP/2 is the main selling point, plus the usual TLS advantages of guaranteeing the integrity of page content, etc.

Plenty of info on speed out there, here's one example: https://blog.httpwatch.com/2015/01/16/a-simple-performance-c...

HTTPS would at least prevent shady WiFi providers from messing with your content before it gets to the user e.g. injecting ads into your content (or even replacing your own ads, if you use them).

I think this comment about the extra hassle is worth thinking about in the context of an open internet.

If you're a generic human being and want to do something like create a little blog or share some artwork online or whatever, any little extra barrier or complexity is just a big pain in the butt that discourages you from doing that. I think this trend towards https is a factor in subtly encouraging people to just sign up up for one of many walled gardens out there in Facebook/Tumblr/Twitter/whatever because it's a lot less work and that's a bad thing for a free and open web in the long run.

If you're not running your own VPS (which you shouldn't for a little blog), then your host should take care of this for you.

I agree with avoiding a VPS when you can. I think e.g. Digital Ocean + Let's Encrypt is just way too low level to be toying with when there's lots of hosting services that let you work at a higher level of abstraction where they deal with all the SSL details for you (e.g. GitHub Pages, Netlify, Heroku).

GitHub Pages doesn't handle SSL for custom domains. The usual workaround is to throw Cloudflare in front of it, but the Cloudflare->GitHub link is still out in the open, and unencrypted.

>GitHub Pages doesn't handle SSL for custom domains.

That's a problem of GitHub, not of TLS

Precisely.