←back to thread

596 points pimterry | 2 comments | | HN request time: 0s | source
Show context
uwagar ◴[] No.36863072[source]
im gonna remove even https from my server. gotta go http in protest against this nonsense.

i'm already pissed off that firefox warns people that my site is unsafe for them when i dont even stick a cookie on them and yet provide useful Free software.

replies(1): >>36863131 #
Avamander ◴[] No.36863131[source]
That's like pissing in your own pants to try and keep warm and you weren't cold in the first place.
replies(1): >>36864587 #
uwagar ◴[] No.36864587[source]
i mean if i'm not tracking the user at all, why should i use https?
replies(1): >>36866892 #
hellojesus ◴[] No.36866892[source]
To prevent isp or mitm injection... ISPs have a history of injecting ads into http connections.
replies(1): >>36866986 #
0xbadcafebee ◴[] No.36866986[source]
They're right though. The browser should have had a mode that ensures integrity without privacy (it's trivial; use PKI to sign the content, send the signature as a header, client validates the signature, and you have integrity over plaintext; or just a form of HSTS, if you don't need PKI, because if HSTS is good enough for certs, it's good enough for anything ELSE, right?). There could be protocol extensions that support clients only loading dynamic or identifying content for specific requests. All sorts of features could allow basic plaintext connections with public content to be as secure as HTTPS.

But the browser oligarchy doesn't want to allow that. They want to force everything to be private, which has caused tons of issues on the internet. And actually, it has strengthened the oligarchy, by forcing us to use private services (such as DNS-over-HTTPS, VPNs, CDNs, etc) which locks more of the internet into the control of a tiny handful of super powerful companies. To the point where if one of them decides to change something, it ripples across the entire internet, and everyone is forced to adopt it or break everything.

Crazier still... HTTPS isn't even that secure! Every year there are examples of valid certs being created for MITM. There are multiple vulns that work at any time. Mitigations that are optional and only a tiny fraction of the web use. And cert expiration, HSTS, and other issues still take down sites accidentally. But they force everyone to use it anyway!

replies(2): >>36867880 #>>36869845 #
1. hellojesus ◴[] No.36869845[source]
> The browser should have had a mode that ensures integrity without privacy (it's trivial; use PKI to sign the content, send the signature as a header, client validates the signature, and you have integrity over plaintext; or just a form of HSTS, if you don't need PKI, because if HSTS is good enough for certs, it's good enough for anything ELSE, right?).

Can you help me understand this please? Without a trusted CA, anyone can mitm by generating their own public/private keys for the user to pretend to be the destination server. They can then sit in the middle and view/alter traffic as it's passed back and forth between the true destination.

How does your proposal prevent that?

replies(1): >>36877708 #
2. 0xbadcafebee ◴[] No.36877708[source]
I mention two different things:

1. "use PKI". That's Public Key Infrastructure, what you know as the CA (Certificate Authorities) part of TLS. Basically, keep everything about CAs that you know about now. But rather than using TLS for the connection, you use plain HTTP. The web server would read the content being sent to the client and cryptographically hash it, then sign the hash using the server's certificate, and put this signature in an HTTP header. When the client receives the plaintext, it would look for the header; without it, it can't validate integrity, and could, like, put up a red bar, error page, whatever. By reading the header, and then validating the signature on the hash, and comparing the content to the hash, it can now confirm 1) the content came from the server, and 2) the content is exactly what the server says it's supposed to be. MITM isn't going to happen unless the MITM attacker can create a valid certificate, to use to hash and sign a modified payload with. Integrity verified, content stays plaintext.

2. "use HSTS". HSTS is a crappy hack that browsers use to say "ok, when you first connect to a HTTPS site, if the site tells you this domain should remain HTTPS, then only use HTTPS to connect to it, until a timeout expires". It's similar to SSH's asking you to confirm a host key on first connection. If this dumb hack (which can be defeated if you MITM the first time they connect, or when it expires) is good enough for the web's security with TLS, it's good enough to, say, cache a host key or certificate, if you didn't want to use PKI above. Again, we're just talking about validating the integrity of data, not a full-blown private secure TLS connection, so we don't need the best security in the world (if we did we wouldn't be using HSTS...)