Because it's only the correct version of the web site that comprises "HTML, CSS, and JPG". The problem isn't about what the correct version of site contains, it's about what the intercepted version contains.
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.
I don’t think this is not a likely enough situation to affect design. I think the author is stating that it is an acceptable risk, and users shouldn’t care.
As I mention in my top-level comment, it seems reasonable to say "I don't really care about surveillance risk of my low traffic blog", but it's a bit incongruous when it's combined with "I care a great deal that Big SSL might be rope-a-doping me and five years from now they'll charge me money for my SSL cert for my low traffic blog, and if you don't like it, it's your problem!"
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.
Maintaining your own web server costs more than that.
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 site happens to have a donate page: http://misc-stuff.terraaeon.com/donate.html From my perspective, it doesn't matter much if that page was added through a MITM attack or not - I neither know nor trust the author of the site and have no inclination of donating money to them.
While I can understand the concerns about added complexity, he won‘t be able to keep this up forever. Browsers will deprecate plain HTTP sooner or later.
Yeah, I empathize but he's really not reading current trends at all if he thinks HTTP is still going to be around in 3 years.
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.
Captive wifi is basically dead already, anyone who thinks they are providing a service by running it is mistaken. It's been busted due to https for years now. It's also almost always some sort of pointless CYA wifi license agreement.
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?).
At some point, for everyday users, the amount of friction and bright red will just mean that they move on to another site. What popular site isn't using HTTPS?
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.
I am not so sure of the "everyday users": we are all conditioned to click through a bunch of "warnings" (cookie consent anyone?), that you'd really have to make it bordering on unusable for people to not simply click-through.
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.
Which would be wrong, unless they start accepting self-certificates. You should not need third party certificate provider to be able to run simple webpage. You should not need to pay them money and should not need to jump through their administrative hoops.
I think it would be acceptable if it's automated at the DNS level. You need to have a trust hierarchy anyway to resolve a name, so you can piggyback the same trust hierarchy to encrypt and secure all communications.
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?
I do agree in principle regarding trust level, and regarding pricing.
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.
Yes, there is vhost negotiation happening in TLS before session is setup, and the webserver selects the apropriate certificate. The loss of privacy is minimal, since without this system you would be forced to use one IP per TLS host (or disable TLS), and DNS binding those IPs to websites are public.
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.
They do accept self-signed certificates. The challenge is you need to distribute the root CA and have your end users set them up on their OS as trusted.
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.
>Browsers will deprecate plain HTTP sooner or later.
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.
> if they drop http I hope they would first drop all the other old stuff that are bad and no longer cool.
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.
That is not part of https or html , they also removed RSS ,
i know some big ego dude wants to add to his CV that he killed http buit I think he should maybe create something more useful(like make sure we can css styule the elements scrollbars so designers won't force me to install a JS library because the scrollbars look like shit and can't customize them to look fine on all browsers or to be more objective see what is the most popular workaround that is used and implement that native (maybe is the calendar, or a better color picker, or native support for modals - run the numbers and not implement stuff thazt only look good on your CV)
Worth noting that at the same time, "they" weren't good enough at pushing new things that the same time. For example, all new compression methods work only over HTTPS (actually, this alone can be a reason to switch to HTTPS) - because they were incompatible with some HTTP proxies: https://bugs.chromium.org/p/chromium/issues/detail?id=14801
<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>
Would that completely prevent an off-line device or local LAN basted host from providing a web interface? (without first manually adding a cert on the users machine?)
I like this post as I run a simple, personal blog and don’t care about tls/https (my isp does it for me automagically so it’s less of an issue for me).
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.
great rant, facts stand that people with HTTPS Everywhere never get a glimps. it might not be monetized but what's the point of putting your ideas out there if "out there" has low reachability?
also looking from security standpoint, anyone could mitm your website. that's bad for your name.
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 think it is likely he hosts it himself. And it is a stretch to include the domain registrar since the service it provides is only one of addressing and not content.
Unless he's directly peering at an exchange into his own datacenter (I doubt it), then he's not hosting it by himself - he's depending on a provider for connectivity and hosting.
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.
> I can only say that if an imposter site encourages you to pay for something or download code, you will immediately know you are in the wrong place.
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.
A lot of the complexity the author is worried about is brought on by iconoclastic choices.
> 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.
> 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?
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).
I do run my own Web servers on dirt cheap VPS systems, with Certbot on a Systemd timer. Under Debian Stable at least, I've never had an issue, across multiple major versions.
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.
Yeah I've done the certbot thing for a variety of servers. I have experienced update barfing. I set up a monitoring thing (the same monitoring thing I use to tell me if my website is down) to tell me if my cert is getting near expiry. The certbot tool I used just did a soft stop-start of nginx, which took I think 200ms or so. Either way, I suspect the startup and renewal time costs are significantly lower than the time cost of writing a blog post to justify not doing it.
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.
Before I used DNS verification, Apache had to be down for a minute so certbot could offer the appropriate URLs itself for the 20-something domains/subdomains I have a cert issued for. Maybe there's a parallelize option I missed?
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.
Re the first point: The verification is specifically designed so it just involves fetching files and thus can be done through a folder served by the main webserver. Certbot writes the challenge responses in that folder, informs LE that is has done so, the verification fetches them, your Apache serves them. Years ago when I first setup LE I think one needed to configure some of that manually for nginx (or maybe I just didn't trust it and decided to ignore the automatic setup? not sure).
All the arguments against this being extra work are pointing how it's possible to do it (extra work, ain't it?).
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.
> 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
Not really. How would an end user know the difference between the owner rotating their certificates and a MITM?
> 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.
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.
Now maybe if they were using some decentralized blockchain DNS (is Namecoin still a thing?) and hosting all their files on IPFS, they would be putting their money where their mouth is.
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.
> I mean, we're talking about a task scheduler here.
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 can want whatever the author wants, as I say repeatedly, it's just not of interest to me as a reader if the author is backed into a corner by a series of bizarre lines in the sand on his part.
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.
>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?
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.
Okay, sure, if you don't care about the visitors to your site, don't bother with HTTPS.
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.
I don't want to require an up-to-date computing device to visit my website. I have HTTPS (with modern ciphers and protocols) for my website, but I also serve it as HTTP.
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.
> If some users are afraid of a possible man-in-the-middle attack, I can only say that if an imposter site encourages you to pay for something or download code, you will immediately know you are in the wrong place.
Not really. Though this guy has received a grand total of $19.52 dollars from one single transaction, so I think it's fair to say this problem is a bit of a edge case.
Edge case or not, it shows that the need for secure connections can suddenly appear in unexpected places.
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.
One common mistake in reasoning I see is overestimating how independent we really are. The author enjoys the feeling of independence, but at least some of it is illusory. It seems a little strange to me to draw a line in the sand about something like Let's Encrypt when, try as he might, he's not going to ever be able to enjoy complete independence, especially not on the web.
All of his arguments are false or bullshit, please educate yourself about why. I'm too tired to elaborate false presumptions that has been debunked years ago, but here are some articles:
Sounds like a set of excuses tbh. I am running an ancient Solaris VM in internal network, and still have HTTPS for services, without any issues/added complexity. Unless you call a single cronjob that.
People have made a reasonable rebuttal to the article here... But there's a double edge to the HTTPS sword that I don't think is being discussed. Automating things with cron is the weak and easy argument to defeat. There's a much harder one he's hinting at though.
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.
> You would not expect This is a mother**ing website (Caution: stong language) to be an HTTPS website, so why would you expect the Miscellaneous Stuff website to be?
79 comments
[ 3.6 ms ] story [ 171 ms ] threadThis is totally reasonable. It's just a hobby blog. There's not much that can go wrong here.
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.
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.
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.
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.
> 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.
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.
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.
I actually laughed out loud (it was a dry laugh, I just woke up).
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!
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.
And that’s exactly what you lose when somebody’s ISP injects JavaScript into your page since you have no SSL.
But motherfuckingwebsite.com does have HTTPS.