[shkkmo]

> If we abolished mass surveillance then we wouldn't need encryption for read-only sites, we could have our cake and eat it too.

Mass surveillance is not the only reason to have HTTPS everywhere. It protects not just from snoopers, but from MITM attacks.

[the8472]

Did you notice the "read only sites" part? MITM is hardly relevant for those.

[sunaurus]

You should still protect against MITM attacks even with read-only websites - not all attacks are based on stealing user input.

[the8472]

What's the threat model here?

[sunaurus]

Random examples of MITM attacks I could do on a read-only website:

* Inserting malicious JavaScript

* Changing content on trusted websites in order to mislead people

* Replacing downloadable application binaries with versions that contain malicious code

[the8472]

Malicious JS can be served directly, e.g. via ad iframes. Injecting it into a low-stakes (read-only) site doesn't gain much, does it?

Points 2 and 3 are the same, they're about integrity which could be had cheaper with content-addressing (hashes uniquely identifying the content) rather than pulling in the full TLS+CA machinery.

[NovemberWhiskey]

Your ISP inserts random javascript and pop-ups into HTTP sites to tell you that you're nearing your data cap and that you should go buy an additional-data-pack.

Like Airtel used to (still does?) in India.

[pixl97]

Ok, you have a site with signed firmware downloads. I mean, they are signed securely right? A user messing with the stream can only send you another signed firmware the device takes, and not anything they attempt to create (unless they guess your signing key somehow).

But, you make a mistake in firmware version XYZ and there is an RCE in it. So you pull it off your site and now XZZ is the latest version.

Only problem is, anyone that can MITM you can serve version XYZ that the client will accept and make the machine exploitable by an RCE.

[xoa]

>Did you notice the "read only sites" part? MITM is hardly relevant for those.

I'm sorry but you're not thinking this through very carefully. People still care about authentication of read-only stuff, in the same way much (and it should be all) open source software, particularly from repositories, is signed these days. A great deal of mischief can be done by modifying info in flight, even ignoring privacy concerns entirely. Plenty of not just governmental but corporate bodies could benefit by being able to trivially rewrite whatever populations (or targeted segments of populations) read. Even ignoring what a vector it could be for other attacks. In principle, we could have some universal standard for signing and authenticating as unaltered websites without bothering to encrypt them. But frankly that seems pointless vs just having encryption as well.

Further, like all practical public crypto use in the face of adversaries, there is a lot of benefit from using it universally and thus "hiding in the herd". Otherwise, the mere usage of crypto itself is a signal, and also easier to target and block (not just technically but via laws). Whereas when it's just baked into literally everything that's much harder to outright infeasible, and also destroys that extra bit of signal.

This was all debated and considered extensively while the moves to universal HTTPS were happening. People moved read-only sites as well for a reason.

[the8472]

> This was all debated and considered extensively while the moves to universal HTTPS were happening. People moved read-only sites as well for a reason.

And the entire discussion was primarily motivated by pervasive surveillance. Which is the point I was making that we're living in a bad equilibrium (low trust society) where there is an attacker and there is a costly defense against the attacker that demonstrates that this particular kind of attack can be rendered useless but we cannot stop paying for the defense because as soon as we do the attacks would resume. If we could instead solve the regulatory problem and forbid surveillance then we would not have to pay that price.

> Further, like all practical public crypto use in the face of adversaries, there is a lot of benefit from using it universally and thus "hiding in the herd". Otherwise, the mere usage of crypto itself is a signal, and also easier to target and block (not just technically but via laws). Whereas when it's just baked into literally everything that's much harder to outright infeasible, and also destroys that extra bit of signal.

That's just a different angle on the surveillance, no? If we had no surveillance then nobody would be there to observe those bits of information you would leak by using or not using encryption.

> In principle, we could have some universal standard for signing and authenticating as unaltered websites without bothering to encrypt them. But frankly that seems pointless vs just having encryption as well.

There are plenty of benefits such as lower latency, much simpler zero-copy IO on the server side (sendfile), improved caching, less energy and silicon area wasted on encryption, less technological obsolescence, a smaller your-ciphersuite/OpenSSL-has-flaws maintenance treadmill. To some extent we could even do without CAs (via content-addressable data).

These may all be papercuts, but we're still getting cut because we can't collectively just tell the NSA to get off our lawn even though we have the means to keep them out anyway.

[shkkmo]

Examples of read only sites that adversaries might want to alter the content you see:

Your banks support numbers, election poll information, binary downloads/checksums are some really critical ones but the list is really endless given the wide range of possible adversaries and their motives.

One big advantage to pushing HTTPS everywhere is that we don't have to trust people to be able to correctly predict which read only content is sensitive.

I do wish browsers handled expired certs for longstanding sites in a way that was clearer to nontechnical people. We should have the ability to look at a project like the Internet Archive to know the history of a site in terms of both content and the certs it was served under.