Hacker News Reader

> This is a client bug, IMO. And sensible servers like Caddy (and yes, before people complain about disclosure, I made it) staple OCSP automatically.

As a client I don't get to choose how the servers interact with are configured.

> But optional (and often discouraged), not required. Separate issue!

Not at all a separate issue. The issue is the absolute fantasy that HTTPS makes your connection secure.

> Don't use clients you don't trust, period. And some big-name clients like Chrome let you dump keys to inspect data transfers locally.

Are you really telling me I have to implement every piece of software I want to run myself from scratch, write custom firmware for my processor, for my router, then sit down and create a custom ROM with a custom operating system for my phone?

> As a client I don't get to choose how the servers interact with are configured.

Clients are the ones that cause the privacy leak, not servers.

> The issue is the absolute fantasy that HTTPS makes your connection secure.

Oh, OK.

> Are you really telling me I have to implement every piece of software I want to run myself from scratch, write custom firmware for my processor, for my router, then sit down and create a custom ROM with a custom operating system for my phone?

If you don't trust them, then yes. Nothing new here though.

> Clients are the ones that cause the privacy leak, not servers.

Regardless of where the leak is, this is not a problem that exists in HTTP. You could not just go to a central server and gather a log of some NN% of the HTTP connections being made. No, DNS is not analogous. You can choose your DNS server, you can even run your own.

> If you don't trust them, then yes. Nothing new here though.

What's new is that it's become a lot harder to examine the information my software is sending to servers on the Internet. If they all talked HTTP, it would be trivial for me to intercept and examine. You can do that with HTTPS, sometimes, but it's a lot harder and relies on the software obeying OS proxy settings.

You probably want a layer 7 firewall that only allows HTTPS traffic to/from the internet to your terminating proxy.

Stuff that doesn't obey the system proxy (or a few of the other pitfalls e.g. HPKP) will break, but at least you'd be aware of what's not allowing itself to be intercepted.

> Not at all a separate issue. The issue is the absolute fantasy that HTTPS makes your connection secure.

HTTPS is reasonably secure if the person in control of the domain is making sure it is reasonably secure. Setting up your whole domain to be MITM is not that.

Your connection to whatever place the person in control of the domain has delegated your connection to is reasonably secure.

> HTTPS is reasonably secure if the person in control of the domain is making sure it is reasonably secure. Setting up your whole domain to be MITM is not that.

And how do you know how secure is a certificate issued by Google or Cloudfare or Microsoft ? Those certificates are just trusted. Good luck with security.

> The issue is the absolute fantasy that HTTPS makes your connection secure.

Well, this is a kind of compromise. It is similar with COVID-19 vaccines: even though they don't prevent transmission, hospitalization and death, they do reduce them (at least the last two).

Even though HTTPS can not offer a very high protection level, together with accompanying technologies they do make certain attacks more problematic - especially sniffing. So for most intents and purposes, HTTPS may make a connection more secure.

As a client you get to choose whether to check ocsp or not. If you don't like it, don't do it.

> That's just plain false across most dimensions. https://css-tricks.com/http2-real-world-performance-test-ana...

I always feel like any performance claims are nowhere near my real life experience, not even when talking about synthetic benchmarks.

For example I recently set up an Apache server that returned a 304 response, on an AWS t3.micro instance and with the Apache Benchmark tool I got around 3.5k[0] requests per second. Once I've enabled HTTPS that fell to around 500 requests per second.

From what I've read at the time (because I was aware of the general consensus that they should have comparable performance), there is some type of underlying hardware feature the TLS decryption/encryption routine can use to speed things up, but it's only available in AWS in m3 type instances and above. Read it from a Mozilla (I think) article, that I couldn't find again right now.

[0] that 3.5k/500 rps might be higher for you because I used maxminddb IP mapping on each requests which I'm sure adds some considerable factor to the rps.

If all your server does is respond with a single small no-body response, then yes http will be much quicker. If you do a somewhat normal page (even something considered small by current standards like 5-10 resources each being 10-ish kb) it will be a wash or http2 will be better.

Relying on microbenchmarks is always dangerous.

Still, it's not a great look when your claim that something is "just plain false" is readily disproved by the obvious microbenchmark. You can certainly argue that it doesn't matter, other factors mitigate it, &c., but at least then you can have the honest talk about how that's true and why you need encryption to make those optimizations.

... except that you don't, they're flagged behind https expressly to strongarm https implementation.

Is there a layperson explanation for why https is faster than http? On the surface, "read file-> send to client" seems like less steps than "read file -> encrypt -> send to client"

"Faster" is ambiguous, and there are a lot of factors involved. HTTPS isn't just "add encryption", it's also "do more at once and don't block as much" because HTTP/2 (a faster version of HTTP) only uses HTTPS in practice.

You can discuss "HTTPS performance" in a purist way that makes it look slower than plain HTTP, but in practice (the only way that matters) HTTPS is faster than HTTP.

I didn't see any claim that https is faster. If you benchmark https on a path where encryption is the only significant work being done, and on hardware that does not have encryption acceleration, then it will appear to be a lot slower. However, in real world applications the https encryption is usually accelerated by a dedicated processor feature, and the other work being done for a request is going to make the encryption time irrelevant. If you are serving static files over http, on a machine with an old cpu, with enough volume to saturate your cpu on http, then https will slow it down significantly. But typically, any server doing that will have 100x more capacity than it needs anyway.

http/2 is faster (for various technical reasons but basically it sends multiple things at once better than old http) and http/2 requires security.

So technically http/2 is faster, but it is only possible with https.

> So technically http/2 is faster, but it is only possible with https.

Because of arbitrary client restrictions. http/2 can be unencrypted, and would be faster unencrypted than encrypted. It's just that all servers/clients decided to not implement the optional unencrypted mode.

I'm not arguing either way, but technically it is possible to do it without https.

The article they linked explained it pretty simply, I thought. One of the improvements is that rather than grabbing resources one-by-one in separate requests, it groups them into bundled single requests.

> TLS supports a "NULL" cipher in certain cipher suites for signed-only transmissions, but mainstream server and client support are limited (for good reasons).

IIRC Windows Update used to do that in XP days, to guarantee responses were signed but to alleviate the pressure of encryption from the CDNs handling updates at the time. (When SSL/TLS was fairly heavy, and Windows Update traffic was 10s of % of internet traffic)