I don't see the problem. HTTPS is basic internet hygiene. It's no worse than telling people they should mind their body odor when they're in a space with a lot of other people. Possibly indelicate, but undoubtedly true.

Exactly what risk does it have being on a low profile blog?

Will it always be a "low profile blog"? It just got on the front page of HN, which is not exactly "low profile".

As for what risk, two words: Great Cannon. For those who don't know, it's a well-known MITM attacker which injects JavaScript code on non-HTTPS pages, the injected JavaScript being used to do distributed denial of service attacks on other sites. Using HTTPS protects against these kinds of attacks.

I for example just wouldn't like anyone to be able to see what data I exchange with any server, be it small profile blog or a login page.

    I for example just wouldn't like anyone to be able to see what data I exchange with any server, be it small profile blog or a login page.

Note: It's really, "see and modify undetected" what data you are exchanging with any server.

It results in your browsing history being tracked and sometimes sold by your access point and ISP at a page level instead of just domain level, results in injected ads and banners on some access points, results in injected trackers on Verizon, and more broadly it permits unknown third parties to alter the content of your website.

If someone wants to track you, they can just mark the frame. Marking packets isn’t anything new,

Your analogy is flawed because this is Hackernews and, superior beings that we are, we understand body odor to be a symptom of a microbiome that's out of whack due to "modern life". Accordingly, we don't bathe in order to cultivate healthy skin bacteria; some of us wallow in mud instead.

I'm not sure you read what I wrote. At no point did I say to bathe, or in fact proffer any treatment at all for body odor. I merely pointed out that refusing to deal with it when you're in close quarters with a large number of people is antisocial. If somehow wallowing in mud treats it for someone, then that's what they should be doing. The problem is knowing how to solve it and refusing to do so.

Noting an amusing interaction with the context isn't shaming.

Though if someone can set it up in less than 15 minutes, and doesn't, I reserve the right to snark. It's not a bad look in cases like that.

You can do it in 15 minutes if you've already done it before. If you didn't, you'd be very lucky doing it in such a short time frame.

I set it up for my home server maybe a year ago. I'm not a web developer or system admin, but I am a highly experienced software engineer with a deep understanding of network protocols. The documentation didn't seem the greatest, basically being, "copy/paste this if you use Apache." My particular configuration was quirkier than the example assumed, and I had to go through a few rounds of troubleshooting. It definitely wasn't trivial.

> but I am a highly experienced software engineer with a deep understanding of network protocols

Thank you for your service

Lol, thanks. I rarely work on stuff exposed to the Internet. I've implemented multiple bare metal IP stacks from scratch, including Ethernet, DHCP, ARP, ICMP, and UDP. I've run real-time safety critical packets over TCP links. I've tunneled IP traffic through the international space station. I've done unforgivable things with iptables and awk.

The funny thing is that IPv6 short-circuits my brain. Why do I have four addresses, and where did they come from? Why isn't there a link-local address for loopback and wireguard?

For most modern blog hosts, it's a pushbutton solution or automatic.

For self-hosted, it's table-stakes knowledge. Failure to do it implies the site admin knows so little about modern security that their access logs are probably only thinly secured. It's an "admin smell," if you will.

The same people who'd claim http is a bad look would also tell you to pipe curl to bash with sudo.

That's a weird claim to make; what makes you think that?

Though I suppose https is a prerequisite for that pipe to maybe be safe. Piping curl to bash varies from stupid to just fine depending on context.

Just look around at lots of how-tos, particularly ones that tell you how to generate and set up certificates.

Fun fact: HTTPS is implicitly required by the GDPR because the user agent metadata is considered PII and websites are required to implement best current practices, which includes HTTPS. There is no exemption for (public) personal websites as they're still providing a publicly accessible service and processing PII to do so.

The same goes for a privacy policy for that matter.

What traffic between a blog without user auth for comments needs to be encrypted? Why? I understand that Let’s Encrypt exists and it’s “easy” to set up (for people with root access to the system hosting their site + a decent level of technical sysadmin proficiency)

So that middlemen can’t spy on which part of the blog you’re visiting / alter the content of the blog / inject ads. There’s also all sorts of vulnerabilities that crop up if you use HTTP and HTTPS on the same site.

All of this was present in the 90s and early 2000s so not really theoretical attacks.

> inject ads.

If you believe that your ISP or a middleman can't inject ads without breaking the S in HTTPS, I have a bridge to sell you.

They can just push the content into a frame and inject the content outside that frame. I encountered this more than once.

Unless the ISP forces the use of its own Certificate Authority on its users, this isn't possible. TLS and the infrastructure surrounding it were designed with integrity of the connection in mind. Knowing this, I would be very curious to know what specifically you encountered and where. I see you added some details elsewhere, but it still doesn't jive with how TLS works.

Our ISP doesn't force MITM certificates, but used to try to mess with the retrieved pages sporadically with stream-hijacks (you navigate to HN, and got greeted with a full page ad) or banner insertions, forcing connection to mixed status while keeping the inner frame HTTPS.

They're not doing this anymore, because I guess they now know how to use their DPI infra in useful ways to them.

My mobile carrier still injects stuff to HTTP pages, but doesn't mess with HTTPS ones, at least yet.

That is not possible. You would get a cert mismatch error.

The overall connection will drop to "mixed status", but the inner frame will still be HTTPS.

My ISP used to do that when they started deploying DPI hardware as a technology demo. They'll hijack your traffic and inject full ads w/o redirection or added (bill) warning banners or ads sporadically to retrieved pages.

My mobile carrier sometimes injects SMS & Notifications arriving to my modem if they find the chance w/o disturbing the connection too much.

So, having a HTTPS connection doesn't make it tamper resistant, but tamper evident, at most.

> The overall connection will drop to "mixed status", but the inner frame will still be HTTPS.

That is not possible. You would get a cert mismatch error.

Consider what your browser does when you navigate to the page: it directly opens a TLS connection to port 443. There's nothing your ISP can do to force the browser to request the page using a non-TLS connection.

What might have happened, is that you might have carelessly typed the address in your URL bar without the "https://" prefix, as in "www.example.com"; for legacy historical reasons, most browsers (except IIRC some very old browsers from the dialup era, which always required an explicit URL scheme) treated that as if you had prefixed it with http:// (so it actually was the non-HTTPS "http://www.example.com" that you were using). Many sites would then redirect you to the HTTPS site, but your ISP could hijack the page before that redirect (since the redirect was not protected by HTTPS). Had you been careful to always prefix any address you type with "https://", there would be no initial non-HTTPS connection to hijack.

Afaik not actually possible in practice. Browsers these days will a) remember valid certs for a domain b) remember that a domain is HTTPS (no downgrades) c) sniff certificates based on crowdsourcing.

Maybe this is why it reduced and stopped over the years. I'm not as knowledgeable in contemporary HTTPS and its capabilities, probably.

Because I'm pretty sure that happened.

Yeah. I hope you realize though why there’s a stern castigation, on a particularly techy and security conscious forum, of using HTTP instead of HTTPS. People here both remember the problems and what’s been done to combat them. It’s discomforting to see backwards progress when so much has been done. Security isn’t purely a technical problem. It’s an educational one too.

can you explain further?

Two things have happened in the past.

Scenario a:

1. Navigate to https://www.example.com

2. Arrive at https://www.completelyunrelated-adsite.com while your address bar reads https://www.example.com

They used to do this regardless of your DNS. They directly hijacked that stream/connection.

Scenario b:

1. Navigate to https://www.example.com

2. Get https://www.example.com with an ad-banner on top.

They happened rarely, and never survived a reload or further navigation. They completely stopped after a while.

I have a 4G modem from my mobile carrier. They inject a info popup when I receive an SMS or any other notification' if they can manage it. It's very rare now, too.

Scenario A is impossible and has been impossible for as long as https has been a thing.

The only way it would be possible is if you installed a root cert from your ISP onto your computer so that it would trust a cert issued by them. Otherwise, they would not have a valid cert for example.com and you would be presented with a cert error.

This is literally the exact thing https was designed to prevent. It is and always has been impossible (again, unless the client machine is administered by the ISP or whoever the middleman is, and they can install a cert on the machine)

It's possible if the connection goes through an http proxy.