Certificate rotation/renewal has been the biggest headache of my IT career. It’s always after the fact. It’s always a pain point. It’s always an argument with accounting over costs. It sucks. I’m glad ACME exists but man this whole thing is a cluster fuck.
Whole IT teams are just going to wash their hands of this and punt to a provider or their cloud IaaS.
Man, I agree. The whole thing sucks so much. We started building a centralized way to do this internally last year to get better visibility into renewals and expirations:
Cool but for us, this kind of thing is better solved closer to the edge with automation like Caddy server that does this for us while also being our ingress proxy for all those domains.
I want Apache to do this natively.
I want nginx to do this natively.
I want tomcat to do this natively.
I want express to do this natively.
Every single http server punts on TLS as an afterthought of supply me your private and public key and I’ll do it. Sure there are modules now for those servers for ACME but this process is still old school Web 1.0 deployment logic.
I've built something similar, not as cool as certkit, but using acme.sh i generate a wildcard and then internally my servers can pull the wildcard generates an md5 so i can track if it changes, put the certs where they need to be and restart the services they need that use it. Linux and Windows. It works.
It's fine for fintechs and social accounts to require SSL, but do blogs really need certs? You know what blogs I'm reading from my DNS requests anyway. I doubt anyone is going to MITM my access to an art historian's personal website. There is zero need for security theater here.
All of these required, complex, constantly moving components mean we're beholden to larger tech companies and can't do things by ourselves anymore without increasing effort. It also makes it easier for central government to start revoking access once they put a thumb on cert issuance. Parties that the powers don't like can be pruned through cert revocation. In the future issuance may be limited to parties with state IDs.
And because mainstream tech is now incompatible with any other distribution method, you suddenly lose the ability to broadcast ideas if you fall out of compliance. The levers of 1984.
> I doubt anyone is going to MITM my access to an art historian's personal website.
But that is what ISPs did! Injecting (more) ads. Replaced ads with their own. Injecting Javascript for all sorts of things. Like loading a more compressed version of a JPEG and you had to click on a extra button to load the full thing. Removing the STARTTLS string from a SMTP connection. Early UMTS/G3 Vodafone was especially horrendous.
I also remember "art" projects where you could change the DNS of a public/school PC and it would change news stories on spiegel.de and the likes.
This is a popular refrain from folks hosting read-only sites.
The problem is not "your part", it's the "between you and the client" part.
It becomes trivial to inject extra content, malicious JavaScript, adverts etc into the flow. And this isn't "targetted" at your site, its simply applied to all insecure sites.
TLS is not about restricting your ability to broadcast information. It's about preserving your ability to guarentee that your reader reads what you wrote.
TLS is free and easy to implement. The only reason not to do it is laziness. You may see TLS as a violation of your principles- but I see it as an attitude of "I don't care about my readers safety - let someone inject malicious JavaScript (or worse) on my page, their security is not my problem".
(If the govt want to censor you they can do that via dns).
How do you protect your physical letters from being opened by unauthorized parties along the delivery chain? You don't for the most part because we have made it a very series crime to do that. We could have done the same to badly behaving ISPs. Instead browsers have chosen to make planned obsolescence a requirement for the web.
Making it a crime is very regional, and enforcement is basically non existent. But opening it is not the problem here.
The analogous problem would be letters opened and anthrax inserted. That doesn't (often) happen because mail is physical and hard to do at scale. (And the anthrax cant mine bitcoin.)
Given the ineffectiveness of current laws around ransomware, bonnets, phishing, identity theft, online scams etc, I don't think a law saying "don't do that" would be a solution.
And ISPs are (by far) not the only offenders here. Every public wifi would be an equally attractive attack point.
supply chain - if you put some 3rd party script link, ad, tracking or even just update dependencies to a bad version like the npm packages hack on your page, TLS won't save you if the service or dependency gets hacked
The biggest culprit is the ad network script. Whether it’s a script tag, an iframe, an image pixel, it’s basically allowing the browser to send your visit event and user agent information (or the chrome updated headers) to that 3rd party and if it’s using jsonp, can callback a function on the page to inject malware that can take over your browser. Ask me how I know.
I agree. Fortunately for blogs, we still have an option - make sure your website is accessible via HTTP / port 80. This has the extra advantage that your website will continue to work on older tech that doesn't support these SSL certs. It will even be accessible to retro hardware that couldn't attempt decoding SSL in the first place.
Of course I have modern laptops, but I still fire up my old Pismo PowerMac G3 occasionally to make sure my sites are still working on HTTP, accessible to old hardware, and rendering tolerably on old browsers.
Unfortunately this means that now your pages are available at multiple URLs, one which won't work everywhere - and you have no control over what URL people will share.
If you HTTP between you and the internet, yes, yes you absolutely need SSL. It’s like “If it’s hot out, do I really need to wear shorts or pants at all?” Yes. The answer is always yes.
It started being enforced only after major USA ISPs started injecting malware into every HTTP page. If it was a theoretical concern I might agree with you, but in reality, it actually happened which overrules any theoretical arguments. Also, PRISM.
PRISM works fine to recover HTTPS-protected communications. If anything NSA would be happier if every site they could use PRISM on used HTTPS, that's simply in keeping with NOBUS principles.
They collect it straight from the company after it's already been transmitted. It's not a wiretap, it's more akin to an automated subpoena enforcement.
Whole IT teams are just going to wash their hands of this and punt to a provider or their cloud IaaS.