Sorry, I didn't have it at the time. It should be the same as the one SPBS has posted above.

https://valep.vc.univie.ac.at/virtualarchive/public/Archive/...

(from https://news.ycombinator.com/item?id=33244723)

I regularly get astounded feedback about how fast it is.

The web doesn’t need to be slow and shitty, web browsers are extremely fast if you use them correctly. Static pages are your friend.

I have fun using that text stack, and with Next every page is just delivered as static HTML.

Clearly, it'd be easy to compare 'apples' with 'oranges' thus quite a difficult analysis to get real figures.

Since there isn’t an open source version, I didn’t dive deeper into the slowness of it or it’s architecture.

I see this so many times in my line of work (software development, consultancy); companies throw millions at a solved problem like e-commerce, the over-enthusiastic engineers jump on it but won't just pick something off the shelf, they will re-engineer it in $cool_tech because just solving the problem is boring.

To MITM you need to be on the way of the traffic, or manipulate the DNS. None is obvious.

These are always the same tricks that work in a lab, but then when it comes to do an actual MITM on a web site - there are no solutions.

If my web site is www.example.com, you would need to get very close to the site (network topologically speaking) and insert yourself in the traffic. This is in practice undoable, except if you hack the local network where the web server lives (specifically some equipment) or the server itself.

Or hack the DNS server.

None of these are remotely easy with basic security in place.

The most obvious and profitable use case were those ISPs who returned 404 pages riddled with advertisements for domains that were unregistered (e.g. if you mistyped a URL)

Certain ISPs even injected JavaScript into every page.

“I” in the OP’s comment probably means “government” or “ISP” rather than a friendly roommate on the same wifi network.

This never existed in France. That would have been completely illegal.

https://www.usenix.org/legacy/event/foci11/tech/final_files/...

France isn’t listed, but Germany, Netherlands, United States (obviously) are. This was a thing that used to commonly happen before TLS became standard.

You want your website to work on vintage computers where they run super old browsers? Then you probably need a HTTP version of the website without TLS/SSL as it's not gonna be accessible otherwise.

Running a software/package repository/registry where every package is signed and verified locally? No need for TLS/SSL and it would just slow down downloading 1000s of packages as handshaking does add latency to requests.

But again, probably 99% of cases it's better to have HTTPS than not. But sometimes not having HTTPS is indeed a positive thing.

That's incredibly niche. I don't think it deserves to be an example of "meme needs to die".

> Running a software/package repository/registry where every package is signed and verified locally? No need for TLS/SSL and it would just slow down downloading 1000s of packages as handshaking does add latency to requests.

Need some secure way to pass around the SHA256 (or whatever) hash you're using for verification.

And thinking of "memes that need to die", https://istlsfastyet.com suggests this isn't as bad as I think you think it is.

The very website we're talking about in this submission is specifically made for vintage computers! But I agree, relatively niche.

> Need some secure way to pass around the SHA256 (or whatever) hash you're using for verification.

That gets passed out-of-band before actually downloading anything from the registry. In the case of Arch, every package is signed by developer keys that are securely fetched on initial install, and later fetched as a package.

Less niche use cases are doing latency sensitive things over HTTP (which overall I wouldn't recommend, but sometimes you're stuck with 3rd party stuff), then adding the handshake can easily double the time for the connection.

For example, one website I have can have the TCP connection be established in ~40ms, while the SSL/TLS handshake takes ~100ms. So because of SSL/TLS, the request time more than doubled. If I was serving signed packages over this connection, you can easily skip the handshaking part and when you download thousands of packages, save some time. I don't think that use case is as niche as you think.

Are you compromising my ISP, the server host, or my client?

In any of these situations, I have a bigger problem than TLS, and a lot of vectors I can be attacked from.