Hacker News Reader

Hacker News

Comment by sgt101 | Hacker News Reader

Parent Full thread

sgt101

Caches drive the internet.

They are orders of magnitude more important than compression. 99.99% of requests hit a local cache. (1)

Compression is important too.

(1) I worked in a telco. Check it out for yourself!

View on HN

This is why I was flabbergasted by the nonsense internet takeover of HTTPS. You can't cache it. Probably 99% of web traffic is generic public content, but we can't cache any of it, because 1% of it needs to be private.

So then people complain "oh but The Illuminati can see what websites I'm going to!" Yeah, and they still can with HTTPS, it's called statistical network traffic analysis. Decades of research papers show you can uniquely identify a client going to a random internet server (and the page they're browsing) just by sniffing a bunch of POPs. It's used by law enforcement and Five Eyes to identify internet users around the world. Even protocols that have countermeasures (TOR) don't stand up to it.

HTTPS everywhere is not only about privacy but also about integrity. You don't want internet randos (including ISPs) to swap your content with ads, bitcoin miners and put other batshit crazy JavaScript in it.

Also, a lot of ISPs blackbox caching proxies were buggy and breaking websites.

Integrity without confidentiality is trivial.

How so? Your ISP is still the channel over which the integrity information is sent. Why couldn't they just swap the SRI hashes as well?

You could sign the content with the same CA architecture we already use to encrypt it, but leave it plain text (just a thought.)

A browser could render a similar security warning to what it already does, if the signature doesn’t match or if the hash is wrong.

Right, I didn't thank about that part. They could technically replace it with another valid certificate, but if you're looking for specific certificates you will notice immediately.

Well, an ISP that wants to MITM your traffic today can present another valid certificate too, nothing changes there. It’s just that they couldn’t use a valid certificate that has the same Common Name (FQDN) as the site you’re connecting to, without having their root CA in your browser’s store (so, same behavior as we already have with TLS.) Presenting a cert with a different FQDN already causes a browser warning.

Yep, you're right, I had a brainfart there. Thanks for being nice and explaining it! :)

Well, it still involves some kind of public key infrastructure, but encryption could be optional even in https. Linux distros have been hosting their packages on plain http for two decades, PGP signatures (again, not a great example of "trivial", I admit) were sufficient to ensure integrity.

Numerous people are currently sitting in jail in Saudi Arabia for having posted tweets critical of the regime under their own names. Without HTTPS, jails around the world would be a lot busier if authorities could see everything that their populace reads online in clear text, in order to build dossiers on who is most likely to be a dissident.

I don’t think the kind of traffic analysis you mention works as well as you think it does for identifying individual pages e.g. which tweet someone is viewing. Moreover it requires a level of technical sophistication that is beyond all but the most advanced countries, countries that tend to have some measure of rule of law.

First of all, did I say get rid of HTTPS? A protocol that does integrity without privacy doesn't mean HTTPS magically disappears. You can still use it.

Second, totalitarian regimes around the world don't sit on their hands just because you use HTTPS. If they want to know who a dissident is, they go find out. Bribery, tips, intimidation, torture, spy cameras, facial recognition, etc. They also know that everyone who reads a tweet isn't automatically a dissident.

Third, no, it's not hard at all to do statistical traffic analysis, it's part of basic DPI packages shipped with commercial network gear for about a decade. All you need to identify the user is the destination and the source, and the signature of similar connections to specific hosts with specific traffic. You compare the traffic from the target user to the traffic you monitor or simulate with known destinations and content, and highest probability wins. It's child's play.

> Numerous people are currently sitting in jail in Saudi Arabia for having posted tweets critical of the regime under their own names. Without HTTPS, jails around the world would be a lot busier if authorities could see everything that their populace reads online in clear text, in order to build dossiers on who is most likely to be a dissident.

Indeed... When one lives in such regimes, to say that appears to be an utter truism.

Tell me you've never worked on a CDN without telling me you've never worked on CDN.

Compared to transit, last mile bandwidth is effectively limitless and free. Cache fill at the edge is important, last mile caching not so much.

You didn’t need the first paragraph there, the snark is a bit uncalled for.

I felt it was a fair reaction to suggesting that we undo years of work in transitioning to https

1. What is the status of using HTTP content on HTTPS pages with subresource integrity? I think we could save on traffic if CDNs would serve content over HTTPS and HTTP, and browsers allowed embedding the latter without warnings into HTTPS served pages provided page had subresource integrity information.

2. Wasn't there some work on serving presigned HTTPS requests? The one everyone blamed Google (?) for cause they wanted it to put slices of other websites inside the search results. Might make sense to resurrect that work.

I think the only website I visit with any regularity where my traffic does not contain some session information is Wikipedia. The transition to the web being largely for web applications and services happened before the transition to HTTPS everywhere. That's when you get stuff like Firesheep just stealing the Facebook sessions of hundreds of people at once.

Is it still? Afaik now with everything HTTPS, caching proxies on the ISP end are completely useless.

We instead now see (proprietary?) cache boxes by big players like YouTube and Netflix that ISPs can install in their DCs, but that seems less elegant, even though it gives the content providers much greater control over what, when and how much gets cached. Still, as a smaller fish, without going with cloudflare, there's no caching involved anymore, probably not even if I decide to run my site on HTTP only.

A CDN is a cache as are the Netflix/fb/etc local boxes. CPUs have three layers of cache before hitting main memory, which could be considered a cache for persistent storage…

Yes, still

He perhaps meant bandwidth and not requests. Netflix and youtube alone must constitute the bulk of the volume and I believe they are fairly aggressively cached, then you have all the assets stored on CDNs.

How do these cache boxes work? Does the server send them its half of the ephemeral key or something? I can't imagine each isp has a box with a copy of netflix's private key.

They terminate TLS at the cache box and use a different connection altogether from the cache box to the upstream server. (Said tunnel to upstream could simply be another TLS connection, or wireguard, or IPsec, etc etc.)

I don't think your caches would help very much if all media were sent uncompressed. Everything is already compressed, so you might not think about it much, but I'd say that it is at least as important as caching.

Compression is so ubiquitous that people tend to forget it's there. I still encounter people wondering why zipping their movie files does not result in a smaller file size

Yeah it's cache all the way down. CPU has L1, L2, L3 for instructions cache. Server has ramcache, then SSD cache. Then apps with SQL almost always use redis/memcache as first level cache. Then for network side we have CDN which is basically a glorified webcache, even at router/switch there is cache for all the stuffs.

Indeed. And ultimately human neurons cache and we only scroll back, reload the page, or go back to the website when our cache ages out or the request isn’t cached yet.

Most serverside processors will only compile pages once they're hit and cache thz results. As the xkcd goes "there's a lot of caching"

It's a bit silly to oppose these two technologies... Caches also rely on compression to be efficient, they work hand in hand.

Foremost a cache relies upon uneven access patterns, which most real world use cases are

both are correct.

The internet is "driven" by web/mobile which is driven by multimedia, which lives and dies on compression / codecs.

Ok how do they work then?

They store frequently-requested items in a place that permits faster retrieval.

https://en.wikipedia.org/wiki/Cache_(computing)

Wait maybe we should be using the Huffman encoding at the cache level!

I'm not sure what that would mean...

Maybe if you're website is unpopular we move your server to North Korea since no one is accessing it anyways?

There's lot of information about this on the open web, and tons of resources for varying levels of skill.

Ironically, this answer is a cache miss.

Reply on news.ycombinator.com