Why this Website is not, and may never be, HTTPS
misc-stuff.terraaeon.com
misc-stuff.terraaeon.com
> Code exists for authomating [sic] [LetsEncrypted renewal certificates], but when I last checked, it did not run on my hardware platform
I mean, we're talking about a task scheduler here. *nix and BSD and MacOS have Cron. Windows has a task scheduler. Every cloud platform has a mechanism to schedule tasks. Is this a Temple OS situation?
But if minimal complexity is what the author wants, they should consider building a static site and deploying it, say, using GitHub Pages, which supports SSL out of the box right now.
> Lastly, as the operator of a personal website, I object to any outside control. I run my own website on my own server for exactly this reason.
So then let's dispense with the notion that HTTPS is adding complexity and get back to the actual point here: potentially well justified neuroticism about having everything under your control is leading to additional complexity. That's fine. Just own it. The whole thing boils down to "I don't want to do HTTPS and I don't want to let someone else do it for me because I don't want to and that's what I want". You do you, dude.
> A TLS certificate is issued by an organization that is not controlled by website owners, website developers, or users of the Internet. That means any time the issuer wants to raise requirements or fees for issuing TLS certificates, he is free to do so.
Turn off your certificate when that happens? Unless you do pinning or HSTS you have no obligation to use HTTPS in perpetuity just because you use it now. If it was someone who wasn't familiar with system administration I'd appreciate that maybe they don't know how to set up their webserver as such, but given that this is a person who's chosen to run their own.
I'm actually not really sure why even this parade of horribles would be coherent. The author has a custom domain for which they pay a registrar. If the registrar raised it prices, he would have to migrate to another registrar or allow the domain to deregister or pay the additional fee. Everything on this earth is transient, it's OK, be at peace. If anything I'd be more interested in a parallel blog post that says "Why I ran my own domain registrar rather than give someone else $10 USD a year for a custom domain" -- that'd actually be the kind of adorable crankery I love to see.
I do get wanting to internalize the locus of control as much as possible, but at some point -- running your own email, running your own domain registrar, issuing your own SSL cert -- the level of complexity leaps up to the point that almost no one does. Which is totally fair! But also not a big deal! It's OK to use external services.
Oddly I actually agree with the author about the underlying point that HTTPS is not really in a cosmic sense necessary for every little domain, but because it's trivial to implement and free -- even notwithstanding engaging any of the ideas about privacy and surveillance that militate towards HTTPS -- I don't understand the objection.
Are you running your own personal web site and have LetsEncrypt certificates set up? It's not all roses, and most obvious tools like certbot would frequently barf on upgrades or what have you when run from a cronjob. And you need to stop your web service for the duration of the "verification" or switch to DNS-based verification, which is not supported by all DNS providers. And I am sure there are different tools to integrate into your reverse proxy so you do not have to stop the service...
But just figuring all this out is additional complexity, and there is regular maintenance work involved. It's not hard, but for my personal websites, other than dealing with certificates and pushing new content, I don't need to touch them for months or years even.
Thus, even though I do invest time in having Lets Encrypt certificates on my personal server, I fully buy their "complexity" argument. It is the most time consuming part of my setup.
> ...about having everything under your control is leading to additional complexity. That's fine. Just own it. The whole thing boils down to "I don't want to do HTTPS and I don't want to let someone else do it for me because I don't want to and that's what I want". You do you, dude.
There is another problem with "I want to control stuff" argument: DNS is, ultimately, not under their control either. I, personally, hand over reins of DNS and certificates to "other parties", and draw the line there.
Still, one can use self-signed certificates to keep full control, and yet allow conscientious users to be susceptible to tracking/MITM only once per browser (or those extra careful who really love this web site could simply trust their CA, though it's unfortunate no browser allows CA-trust to be established per domain IIRC). The validity date can be pretty far in the future so the maitnenance burden is non-existent (unless your CA cert or private cert leaks).
That's a suggestion I'd make for them.
That, and Borg backup. The hardest part about setting up a new machine for me is remembering the incantation to append my SSH public key to the authorized keys on Rsync.net. I never think about Certbot.
Then again, my needs are very simple. Maybe with more complicated set ups, you have issues.
And again, this is assuming you start from the premise that you must host your own thing and manage your own thing; if you actually want to zero out this complexity, just use GitHub Pages.
I tend to think that if you are talking to someone and they say "I'm having problem <x>", and you say "Have you tried a, b, c known solutions?", to which they say "I can't do those because I also need <y>", so you say "Have you tried d, e, f known solutions?", to which they say "I can't do those because I also need <z>", the longer the conversation goes on the more it's obvious the person in question is just happy being grumpy. Which is fine. I have tons of different crank views, I can't tell you how much code I've written rather than use something off the shelf because of whatever screws are loose in my head. But it's sort of the price of admission, right? Like, other people are not experiencing any of this stress, the entire problem domain is self-imposed.
I am sure there is an Apache module to short-circuit this (i.e. offer whatever verification tokens are needed on top of whatever Apache is serving otherwise), but I personally did not bother.
> And again, this is assuming you start from the premise that you must host your own thing and manage your own thing;
Sure, but that's what the premise is. "Must" is a strong word, but I'd go with "want".
And one can satisfy the "want" without the unnecessary work like HTTPS certs. No matter how minute, they are significant compared to the maintenance burden otherwise.
All I am saying is that it's a perfectly valid position OP has, and that there is more work and maintenance needed even for "automated" LetsEncrypt certs.
In a nutshell, I agree and it's worth it to _me_. It is still extra work :)
FWIW, my Apache is a reverse proxy to multiple VMs for each different service I run, so without pulling out my mod_rewrite skills out, "just serving a folder certbot can write to" is anything but.
Not really. How would an end user know the difference between the owner rotating their certificates and a MITM?
I have been using the webroot option. Minimal web server configuration which I have standardized across my web servers and put into configuration management, and doesn't require the web server to go offline, just a reload at the end to pick up the new cert.
Also I don't update software on running system but will build a new system and replace the old one after testing. All automated.
I took the time to set this all up to make it easier on me in the long run, and it has. To each their own.
Heck, why not just use GNU Freenet?
Until that happens, this sounds more like religious fervor than reasoned argument, and this article is one big post-hoc rationalization.
Not just that, the certbot tooling as well, which can be arbitrarily flaky.
> Is this a Temple OS situation?
And so what if it is? Why shouldn't someone be able to run a website on Temple OS, or a 68K Mac, or whatever, if he wishes?
> But if minimal complexity is what the author wants, they should consider building a static site and deploying it, say, using GitHub Pages, which supports SSL out of the box right now.
He wants to publish his own site, not engage someone to publish it for him. As you quote below, he objects to outside control.
If one hosts one's site on GitHub Pages, then one is beholden to their rules and standards.
The author is responding to a discourse that says "You should serve your website SSL-enabled" in a passionate enough way to write a blog post about why he shouldn't, and it turns out the reason why he shouldn't is more or less that he doesn't want to. OK. Cool.
The choice to want to control everything (except all the things you don't fully control, like the domain name, the DNS system, and probably the SMTP server) means that there's a little overhead setting things up. This is known. It's not particularly interesting.
Absolutely. Or even a gopher site or a Fidonet BBS.
The technology mainstream moves on, and if you don't stay with it, you have to expect that there will be implications. At this point, the technology mainstream is moving towards TLS as table-stakes.
There is a donation page that seems to contradict the above: http://misc-stuff.terraaeon.com/donate.html .
I know literally nothing about bitcoin. Can a key like that be verified before using it? Or you just trust you have the right key?
https://www.blockchain.com/btc/address/1DsNqMZHhU54WJdSXeAa5...
It might not matter there and then. But in a couple of years that website might become more profitable, or might grow and include more content that is dangerous when insecure.
Personally, I don't want visitors to my site having adverts injected by their ISPs or public wifi networks they're connected to. I don't want to needlessly expose my visitors to having malicious JS being run on their machines. I don't want a MITM to be able to change the text that a visitor receives on my website, and make the reader believe that I said something I didn't say. Especially when the fix for all of this is incredibly simple and introduces only a miniscule overhead.
https://www.troyhunt.com/heres-why-your-static-website-needs...
I really do appreciate the advantages of HTTPS, but I have issue with the time-bombed nature of the technology: website certificates, root certificates, and ciphers that become less secure. I do not like that old devices can essentially no longer use the web due to HTTPS.
Anyone in the middle can change the web site into anything they like. They could add a "donate link", saying that the author needs money to sustain the site.
We're talking about a free thing that on one hand takes five minutes to set up and on the other hand provides almost no benefit! It's hard to imagine lower stakes for anyone involved.
5 minutes every two months isn’t a great amount, but it’s great compared to the benefit to this blogger.
I can imagine lower stakes with something that takes zero minutes.
Zero minutes would use an external provider. Otherwise you're opening an unmaintained insecure webserver - a potential bounce for all sorts of illegal activity.
The author objects to outside control, yet is at the mercy of their domain registrar, to whom the same set of problems seems to apply, as well as their hosting provider.
If the author objects so much to outside control, they might think on the fact that offering their content unencrypted allows it to be rewritten by ISPs to introduce ads or other content outside their editorial control while still inside the network.
I don't see what distinction you're trying make between "addressing" and "content". In either case he would be dependent on a third party (that he may have to pay for their services) to keep his site online.
He renews his certificate every two years, or his site effectively goes offline. He renews his domain every two years, or his site effectively goes offline.
What's the difference supposed to be?
That is such a flawed argument. If someone makes an imposter site, they're not gonna keep that warning there. And first visitors would have never seen the previous warning.
Of course the chances of that happening are very low for a website like that, but the argument is still flawed.
The whole thing could be summed up "Because I don't want to", all of those other arguments seem weak at best. Which fine, do whatever you want with your blog, but it doesn't change the fact that the arguments brought up are bad under the disguise of being a big reason for not having https.
If everyone had their own simple blog (or plan file) instead of Facebook/etc, I think the world would be a better place.
I can't wait for the pure hell that is captive WiFi once browsers provide sufficient friction to accessing non-HTTPS sites. Most devices are good enough at popping up the portal but far too often I find myself pulling up http://neverssl.com to force things to start working.
HTTP is here to stay. Maybe browsers on PCs will make accessing it extra hard, though I suspect that's untrue as well (maybe POSTing data to HTTP web sites will be harder in that people will see extra pop-ups).
But sites which have lived as HTTP forever are not going to magically get some maintenance done on them to move to HTTPS, and people will still visit those web sites.
And let's talk about all those crazy cheapo IoT devices that are already spreading through the world that have their "http" servers hard-coded.
Don't get me wrong, I've been on the HTTPS bandwagon since forever (before LetsEncrypt, the best deal you could get for multi-domain personal webpage certs was StartSSL, an Isreali company with very buggy software that you had to fight to get a cert issued). And I've long (decades?) advocated that browsers should first try an HTTPS page when protocol-less URL is given (which they are only now moving to, duh?).
But I'm not even talking about desktop browsers, here. It'll start with mobile devices. iOS and Android going HTTPS only with their default browsers is entirely within the realm of reason. Flash was functionally dead once Android gave up on it within a few years. Yes, there was a long tail of enterprise users and people who refused to give it up.
Similarly, there will be a very long tail of HTTP. But Apple and Google are in a position to kill it just like they did Flash.
Even with mobile devices, I imagine another cycle is coming where people care more about what their seemigly-general-purpose computers restrict them from doing.
But I'd still wager that it ain't happening in the next 3 years.
In the fee paid for the domain name, the owner should get perpetual free secure DNS and certificates for any purpose and sub-domain.
The current issuance of (non-EV) certificates is an unsecure hack over DNS anyway[1], so why not merge certificate issuance at the protocol level?
[1] https://en.wikipedia.org/wiki/Domain-validated_certificate
But that can quickly become impractical. I run a bunch of small personal web sites (different domains) on a single IP, which a certificate is tied to (since HTTP "Host" negotiation only happens after the encrypted connection is established). I think there were changes to allow this negotiation to happen before encryption, but that loses some privacy.
I also use a couple of registrars, so coming up with a solution to this existing complexity is extra hard. Maybe with IPv6 where I can cheaply use a bunch of fixed IPs instead.
For the second concern, it can be in principle automated to the point where you only need to inform the webserver of its hostname(s). If the DNS A records are correctly configured, it's trivial for the DNS server to verify the IP address and sign the CRL generated by the webserver on the fly. Like a letsencrypt operated by your DNS provider that simply works.
If you aren’t using some centralized platform like LetsEncrypt, you’re lacking that layer of known trust that is required with the SSL system. It is not a trustless system.
This is a stupid idea, it means the browsers will not be compatible with old websites, if they drop http I hope they would first drop all the other old stuff that are bad and no longer cool.
A big warning should be enough, old websites should still work in a competent browser.
They have been doing this. Gopher, FTP, XUL extensions, NPAPI browser plugins, old TLS versions, for examples in the last few years, and alert()/confirm()/prompt() for Chrome's current push.
<rant> I'm actually looking forward for them to drop HTTP digest auth, because it's the only auth scheme which doesn't rely on sending shared secret over the wire with each request </rant>
I get questions about why don’t I require or default to tls and I’ll point those folks to this post to explain my reasons.
I don’t like pointless security and, as a developer, get annoyed by many “security” requirements that just seem to increase complexity without any tangible benefits.
Yes, there is some benefit, but it’s not much. As the author says, MITM and isp snooping isn’t really applicable to simple web blogs. So who cares about protecting the content.
It’s like protecting against Martian attackers. Yes, it’s nice to be safe from Martian attackers but not worth a penny or second of time.
And that’s exactly what you lose when somebody’s ISP injects JavaScript into your page since you have no SSL.
The year is 2040. HTTPS is by and large well adopted, and certificate authorities have waned under the power of let's encrypt. Firefox and Chrome have progressed from showing a warning, to refusing to load sites that are insecure, much like how expired certificates are handled today.
However, the government has adopted control over much of the internet. Facebook is now run by the federal government, and most online interaction requires a government photo ID. Further more, comments you made in the past have damaged your social credit score, and Let's Encrypt will no longer issue you certificates, and traffic to your static blog has dramatically dropped to near zero. Not to mention, the hit your site takes in page rank for not offering https any more.
There's a million things that can be said about how to operate in such a world -- and by and large it seems we're headed that way. But this fact remains: certificate authorities are a centralized power that the public can't control. And that means you're at their mercy.
I actually laughed out loud (it was a dry laugh, I just woke up).
But motherfuckingwebsite.com does have HTTPS.
https://www.makeuseof.com/tag/https-ssl-certificate-myths/
https://aboutssl.org/debunking-https-and-ssl-security-myths/
Also there was a website which explained everything mentioned in this article, but I can't find it anymore.
You should not care about TLS performance anymore!
This is totally reasonable. It's just a hobby blog. There's not much that can go wrong here.
also looking from security standpoint, anyone could mitm your website. that's bad for your name.
Not anyone, just a select few and it’s more likely that the notoriety would be good for your name, not bad. The MITM would be detected and corrected.
The odds of a MITM on a self hosted blog are much lower than just normal stuff like the host being rooted.