3 ms·
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
by amiga386 1y ago
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 1y ago> 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?
- XorNot 1y agoFor 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 1y agoI 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 https://www.rfc-editor.org/rfc/rfc6920.html but I haven't seen any support for it.
- drob518 1y agoThe argument doesn’t even make sense for static content ignoring mitm attacks.
- pixl97 1y agoThere 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.
- RiverCrochet 1y agoWell there is the integrity atttribute. https://www.w3schools.com/Tags/att_script_integrity.asp https://www.w3schools.com/Tags/att_script_integrity.asp