Hacker News Reader

Comment by 2h | Hacker News Reader

Honestly I kind of dislike the security through scaring the userbase tactic. HTTPS is wonderful, but it is not needed in all situations. For your run of the mill static site, its essentially pointless.

Sure, if you are dealing with money or customer data, use all the crypto you want. But I think people should respect tools should be applied where they are actually needed, not just arbitrarily. You dont need a bulletproof safe to guard a stick of gum. Think critically people.

View on HN

HTTPS improves security even for a static site because it prevents an ISP or middleman from injecting ads (or worse) into the page.

It also increases privacy because the contents of the traffic can not be observed by third parties.

Right, but for a static site that’s publicly accessible, even HTTPS leaks the requested URL, any listener can go fetch that page themselves to see the contents.

> even HTTPS leaks the requested URL

It does not. In the olden days the host name was leaked, but with SNI even that is gone. Anything past the first "/" is never and was never sent in plaintext in HTTPS

Most public web sites leak information about page accesses to anyone who can count bytes.

What kind of attack are you describing?

Count how many bytes of TCP traffic you see. Measure the size of each web page on the (public static) website.

The host name is still leaked, SNI is not encrypted and ESNI is still not mandatory in TLS 1.3.

> host name was leaked, but with SNI even that is gone

nope, you can still see it perfectly fine:

https://tlshello.agwa.name/

please don't spread misinformation.

ESNI*

OK, now name at least two public servers that use that. I will wait...

HTTPS does not leak the requested URL to servers between the client and the server.

I respectfully disagree that verifying your domain is pointless. Without proper verification, you leave yourself vulnerable to a range of risks, such as man-in-the-middle attacks and DNS spoofing. These attacks can allow bad actors to intercept your web traffic and inject malware into content or modify it. Recent security breaches have highlighted the importance of domain verification, and I believe that all users should take steps to verify their domains, such as implementing SSL/TLS certificates or using a domain verification service.

And additionally I would't want anyone on my network path to be able to read what data I exchange - even if it is a static site.

That’s a valid concern too. For a lot of static sites I visit, I don’t particularly care if people know I visit them as I live a boring life. My primary concern is malware and verifying identity.

Agree, what I dislike most about https is the way it effectively has a forced expiry date. Have you ever stumbled across someones old abandoned university project page, a blast from the past with all sorts of interesting information. hopes and dreams from a bygone era. not gonna happen with https.

Those pages are abandoned, but the servers aren't abandoned. The same person keeping it running should be able to update certs just fine.

Keeping your certs up to date is a little bit harder than turning it on and off again every now and then

Not if you are using tools like letsencrypt, something most blogs and small university projects would readily use. Yes there may be a breaking change in the future but it's quite set and forget at this point.

Seeing as there are severs that are still running but have expired (letsencrypt) certificates, yes it is unquestionably harder.

That's not how that works!

If servers have an 80% survival chance, and a 95% certificate renewal chance, you'll only see the servers that are running with expired certs. You won't see the inverse.

The https certificate “expiration” date is basically just a “fallback to treating this website as http” date. The site is still perfectly accessible and arguably still more secure than an http only site, you just have to click the scary button saying you know what you’re doing and proceed to the website treating it as though it was compromised which isn’t a big deal for the static pages you’re describing.

Besides the certifacte expiration date there are also expiration dates in the protocol itself as newer clients/servers will refuse to use older SSL/TLS versions or ciphers.

But even with "just" certificate expiration the user experience is not even close to "fall back to HTTP". Browsers won't even give you the choice to override certificate check at all with HSTS.

Then there is the fact that the move from HTTP to HTTPS changes all URLs. If only we would have had StartTLS for HTTP - and no, there is no security issue with StartTLS as you will need something like HSTS preloading anyway if you actually want to guarantee security.

Lack of backwards compatibility is absolutely a concern that the security community seems to care little about.

Everyone else replying is a shill of one sort or another.

Someone might inject javascript into the page? You should not be allowing RCE anyway.

Someone might MITM? Cloudflare does this with https anyway.

Companies might spy on you? They already are. Cloudflare intercepts all the traffic going to them despite it being encrypted.

Government might spy on you? They already are. They have backdoors and frontdoors into every system.

What would you propose then?

Specifically? Firefox to stop bitching that I enter my passwords into unencrypted pages on my local network. Browsers halt or even reverse their plans of deprecating unencrypted transport. Browsers stop bitching about loading unencrypted static resources on an encrypted page.

Generally? Everyone I accused of being shills off the "everything encrypted" bandwagon. If you want to encrypt your websites go ahead. You don't have to believe my unhinged conspiracies from earlier.

> Browsers stop bitching about loading unencrypted static resources on an encrypted page.

I tend to agree with you on other points but that one is a weird take. If I deliberately visit an https page I want to be reasonably confident that it wasn't tampered with and that I'm not leaking information.

Allowing loading http resources in an https context breaks that trust. Scripts may be tampered with. The website URL is leaked via the referer. Cookies might be leaked.

Note: Mitigations for all those worries do exist. Cookies can be flagged secure-only. Referer can be stopped using CORS, etc. But they all need the developer to be proactive about it and, for the most part, they aren't.

What scaring? Chrome shows a gray "not secure" and firefox has a crossed out padlock. That seems understated to me.

If you're talking about certificate error pages, then yeah there's room for improvement. Not every site needs the same level of warning there. But caution makes sense as a default. Something went wrong.

My Chrome does not allow me to visit HTTP page. Yours will do the same soon.

Why doesn't yours? What do you mean by "soon"?

I just tried http://example.com/ in chrome canary and it's the same.

Edit: Okay, I found the "Always use secure connections" setting, but that has been around for a while. And it doesn't actually stop me, it asks.

Also downloads are or will be blocked on http but that's not too bad of an idea.

An invalid certificate also doesn't technically stops you and just asks if you really want to proceed.

By "soon" I mean that this particular behavior surely will be the default one. Here's old blog post: https://blog.chromium.org/2021/03/a-safer-default-for-naviga...

And quote from it: "HTTPS protects users by encrypting traffic sent over the network, so that sensitive information users enter on websites cannot be intercepted or modified by attackers or eavesdroppers. Chrome is invested in ensuring that HTTPS is the default protocol for the web, and this change is one more step towards ensuring Chrome always uses secure connections by default."

I think that the direction is obvious.

Any browser that actively prevents viewing an HTTP site is not fit for purpose. Set secure defaults, absolutely. Show scary warning pages if you insist. But don't prevent legitimate activity entirely.

I used to think like this, but then I read this:

Troy Hunt: Here's Why Your Static Website Needs HTTPS https://www.troyhunt.com/heres-why-your-static-website-needs...

I don't want to pile on, but security vulnerabilities are often composed of a series of seemingly insignificant weaknesses that get chained together in highly clever ways. Anything that is accessed over http gives a potential attacker the ability to monitor activity, MitM, spread misinformation, and find potential other footholds that can be composed into a larger attack.

TLS ads a lot of complexity and with it come additonal vulnerabilities that a HTTP-based site doesn't have - e.g. most famously Heartbleed.

TLS doesn't add that much complexity unless you're actually writing your own handshake code.

> with it come additonal vulnerabilities that a HTTP-based site doesn't have

This strikes me as being a very strange point to make. HTTP includes no security whatsoever. HTTPS includes quite a lot of security. HTTPS may have vulnerabilities, but even so it's still certainly far more secure than HTTP.

Which part of confidentiality/integrity/authenticity is unnecessary for a static site?

The part where you require those for your ISP, a legal entity that you have a contract with and can enforce laws against, but not for Cloudflare, Netlify, Akamai, GitHub and all the cloud vendors have access and can modify this supposedly authentic and confidentional data.

Static sites serving on a local network that is never exposed to the internet.

Reply on news.ycombinator.com