Things change over time.

Part of not wanting to let go is the sunk cost fallacy. Part of it is being suspicious of being (more) dependent on someone else (than you are already dependent on a different someone else).

(As an aside, the n-gate guy who ranted against HTTPS in general and thought static content should just be HTTP also thought like that. Unfortunately, as I'm at a sketchy cafe using their wifi, his page currently says I should click here to enter my bank details, and I should download new cursors, and oddly doesn't include any of his own content at all. Bit weird, but of course I can trust he didn't modify his page, and it's just a silly unnecessary imposition on him that I would like him to use HTTPS)

Unfortunately for those rugged individuals, you're in a worldwide community of people who want themselves, and you, to be dependent on someone else. We're still going with "trust the CAs" as our security model. But with certificate transparency and mandatory stapling from multiple verifiers, we're going with "trust but verify the CAs".

Maximum acceptable durations for certificates are coming down, down, down. You have to get new ones sooner, sooner, sooner. This is to limit the harm a rogue CA or a naive mis-issuing CA can do, as CRLs just don't work.

The only way that can happen is with automation, and being required to prove you still own a domain and/or a web-server on that domain, to a CA, on a regular basis. No "deal with this once a year" anymore. That's gone and it's not coming back.

It's good to know the whole protocol, and yes certbot can be overbearing, but Debian's python3-certbot + python3-certbot-apache integrates perfectly with how Debian has set up apache2. It shouldn't be a hardship.

And if you don't like certbot, there are lots of other ACME clients.

And if you don't like Let's Encrypt, there are other entities offering certificates via the ACME protocol (YMMV, do you trust them enough to vouch for you?)

▲

pixl97 2 days ago | parent [-]

> thought static content should just be HTTP

Yep, I've seen that argument so many times and it should never make sense to anyone that understands MITM.

The only way it could possibly work is if the static content were signed somehow, but then you need another protocol the browser and you need a way to exchange keys securely, for example like signed RPMs. It would be less expensive as the encryption happens once, but is it worth having yet another implementation?

▲

drob518 2 days ago | parent | next [-]

The argument doesn’t even make sense for static content ignoring mitm attacks.

▲

pixl97 2 days ago | parent [-]

There is no such thing as static content. There is only content. Bits are sent to your browser which it then applies the DOM to.

If you want to ensure the bits that were sent from the server to your browser they must be signed in some method.

▲

drob518 2 days ago | parent [-]

Right, that’s exactly my point.

	▲	pixl97 a day ago \| parent [-]
		Oh sorry I misunderstood your statement, yes, that's correct.

▲

RiverCrochet 2 days ago | parent | prev | next [-]

Well there is the integrity atttribute. https://www.w3schools.com/Tags/att_script_integrity.asp

	▲	pixl97 2 days ago \| parent [-]
		Pretty useless in this case if I control the stream going to you. The main page defining the integrity would have to be encrypted. Maybe you could have a mixed use case page in the browser where you had your secure context, then a sub context of unencrypted protected objects, that could possibly increase caching. With that said, looks like another fun hole browser makers would be chasing every year or so.

▲

bigstrat2003 2 days ago | parent | prev | next [-]

> Yep, I've seen that argument so many times and it should never make sense to anyone that understands MITM.

Rather, it's that most people simply don't need to care about MITM. It's not a relevant attack for most content that can be reasonably served over HTTP. The goal isn't to eliminate every security threat possible, it's to eliminate the ones that are actually a problem for your use case.

	▲	kbolino 2 days ago \| parent \| next [-]
		MITM is a very real threat in any remotely public place. Coffee shop, airport, hotel, municipal WAN, library, etc. I honestly wouldn't put that much trust in a lot of residential/commercial broadband setups or hosting/colocation providers either. It does not matter what is intended to be served, because it can be replaced with anything else. Innocuous blog? Transparently replaced with a phishing site. Harmless image? Rewritten to appear the same but with a zero-day exploit injected. There's no such thing as "not worth the effort to secure" because neither the site itself nor its content matters, only the network path from the site to the user, which is not under the full control of either party. These need not be, and usually aren't, targeted attacks; they'll hit anything that can be intercepted and modified, without a care for what it's meant to be, where it's coming from, or who it's going to. Viewing it is an A-to-B interaction where A is a good-natured blogger and B is a tech-savvy reader, and that's all there is to it, is archaic and naive to the point of being dangerous. It is really an A-to-Z interaction where even if A is a good-natured blogger and Z is a tech-savvy user, parties B through Y all get to have a crack at changing the content. Plain HTTP is a protocol for a high-trust environment and the Internet has not been such a place for a very long time. It is unfortunate that party A (the site) must bear the brunt of the security burden, but that's the state of things today. There were other ways to solve this problem but they didn't get widespread adoption.
	▲	pixl97 2 days ago \| parent \| prev [-]
		MITM is a risk to everyone. End of story. The browser content model knows nothing if the data it's receiving is static or not. ISPs had already shown time and again they'd inject content into http streams for their own profit. BGP attacks routed traffic off to random places. Simply put the modern web should be zero trust at all.

▲

XorNot 2 days ago | parent | prev [-]

For catching purposes form content distribution an unencrypted signed protocol would've helped a lot. Every Linux packaging format having to bake one in via GPG is a huge pain.

	▲	PhilipRoman 2 days ago \| parent [-]
		I think it would be enough to just have a widely supported hash://sha256... protocol with a hint of what host(s) is known to provide the object (falling back to something DHT based maybe). There is https://www.rfc-editor.org/rfc/rfc6920.html but I haven't seen any support for it.