So, I'm definitely not against vanilla HTTP where appropriate, but here are three arguments for the "all must be encrypted, heretic!" side of things:
1. The vast majority of web developers/IT people/etc. aren't really knowledgeable enough to make the call whether something actually needs to be encrypted. Very smart developers have told me they weren't worried about security because their application didn't hold any sensitive data. Sometimes this was because they thought emails and/or passwords weren't sensitive data. I've also had very smart people tell me they weren't worried about security because nobody had any incentive to hack their server. But there is always incentive for bad people to hack a server: even if they can't ransomware you, they can host botnets or child pornography. Having seen situations like this enough, I'm no longer even convinced that even I am correct when I think security isn't necessary. Maybe you're qualified to make that call, but even then, evaluating the system may be harder than just adding security.[1]
2. Just because your system doesn't need HTTPS now, doesn't mean it never will. YAGNI conveniently doesn't specify whether "A" stands for "Are" or "Aren't". In my experience, most systems involving HTTP do eventually have a requirement that passes sensitive data over HTTP, and it would be all-too-easy to forget that channel wasn't encrypted.
3. Even if you don't need encryption for yourself, do it for everyone else who does need encryption. Before HTTPS was required in every browser, users would happily submit their passwords over completely unencrypted channels. Now, browsers will give big warnings that hopefully prevent users from doing this. Those warnings probably aren't necessary if, for example, you're submitting an anonymous comment to a Disqus conversation. But it's important not to normalize clicking past those warnings for nontechnical users, because if they click past those warnings to post an anonymoust Disqus comment, they'll click past them to submit a password. And in a more political sense, normalizing encryption for stuff where it isn't important protects encryption for stuff where it is. "If you are encrypting you must be hiding something bad" is a dangerous narrative which is pervasive in politics, and default-on encryption is one of the best tools against that.
[1] As an example of this, it appears that there are a few attack vectors in your own posts, which you either didn't think of or don't care about, but which I would very much care about as a user of your library catalog.
I've heard these arguments. I am not unsympathetic.
For the first, I don't know what to tell you. If they aren't qualified to know when security must exist, they are not likely qualified to implement it.
For the second, when it is needed, it can be added. A staff directory with no interaction does not need it now. It may never need it.
As to the third, in a story, here is a great argument against that:
So years ago I ran this dumb little site, by request, for the users to submit stuff, nothing too special. They suddenly wanted the HTTPS, which was at that time outside of their budget, which was zero, and we would have had to move it off of a shared IP (this was some time ago). I told them it wasn't necessary for their use case.
"But the LOCK thing makes it safe!" They were so insistent ... but they still demanded the results be sent to them over SMTP. Oh, how I facepalmed. I explained that SMTP was its own channel. No, no, they insisted. The LOCK.
HTTPS can result in a false sense of security.
At the end of the day, I think I would rather have choices available even if mistakes could be made. Removing choice from people for their own good is fantastic if and only if it will never ever cause any kind of issue on its own. Here, in the article, we discuss some of those issues. If HTTPS were possible to just implement retroactively with nothing ever breaking, not even some ancient software on a floppy disk, fine. For anything other, it's a tradeoff, and I believe for tradeoffs we ought to have the ability to assess the tradeoffs and make a choice. Even choices others do not agree with!
> For the first, I don't know what to tell you. If they aren't qualified to know when security must exist, they are not likely qualified to implement it.
...which is why numerous high-quality implementations already exist.
There isn't a way to say this without risking offending you, but if you can take it for what it is, I think you would benefit from it: you have posted a few examples in this thread where you think no one would care about encryption, and there are people posting here saying they do care about encryption in those cases. It might behoove you to approach this with a bit of humility and acknowledge that you are one of the people who isn't qualified to know when people need/want security, and your opinions are borne from that fact.
This feels like a no-true-scotsman argument. A true security-minded person understands the benefits of TLS, and if you don't, then you're not qualified to understand security.
"If you have not yet attained Buddhahood, you cannot understand the value of enlightenment." is also a non-controversial tautology, but it also doesn't leave any room for anyone to do anything else.
I think there are people who care about just about everything. Let's make those certificates expire every month. Also without a way to say it without risking offending someone: the tinfoil hat brigade can make everything grind to a halt. People can have concerns, and they can be very invested in those concerns, but they can be so concerned that I don't know if I could ever satisfy them. They could be concerned about what operating system that HTTPS-serving software runs on, and their set of requirements might be such that I cannot run anything.
> I think there are people who care about just about everything.
True. But I'm not one of those people. You'll note that there are a few of your examples which I haven't objected to. That's because I don't have objections to all of your examples.
> Let's make those certificates expire every month.
I get your point--people do ask for excessive security measures sometimes. But as an aside, the point of frequent certificate expiration has nothing to do with security. It's to encourage automation of renewals.
Yeah it is more work. If you're a sysadmin, that is your job and it's why you get paid. You're welcome to choose another job if it's too much work for you.
Yes, it is more work. And doing it doing it once every month instead of once a year is yet more work. But is it valuable work? Does that work accomplish anything? Or is that effort wasted when I could have been doing other things?
I was not a sysadmin -- I kept trying to avoid that, but got sucked in, as a programmer (my title), with the reasoning I have been doing "web stuff" for a long time, as well as the sysadmin duties that were required for setting up websites "back in the day." I could have been programming and solving real problems on a more permanent basis, but here I am, carrying water with a hole in the bottom of the bucket. Once the DevOps wand got waved, I got out.
If people are truly concerned about security, even the much-disliked sysadmin duties foisted upon me could have had the time more wisely spent then flipping certs around.
1. I am extremely skeptical of your claim that cert renewals couldn't be automated.
2. Nobody here is saying that you need to renew your certs every month. Just because some completely different person asked for something that didn't provide any value, doesn't prove that what anyone here is saying is incorrect.
Okay, be skeptical. I didn't want to void our support contract over finding out. Would you come to my rescue if I did?
First the certs need to be renewed every three years. And some browsers want to raise warnings if they're past a year old. And Let's Encrypt is down to three months. Just waiting for the next click of the ratchet.
> Okay, be skeptical. I didn't want to void our support contract over finding out.
Really? Your support contract would be voided if you automated certificate renewal? If what you're saying is true, the problem isn't with short renewal times, it's with your absurd support contract. Automatic renewal is the industry standard at this point. If anything, your support contract should be voided if an error occurs because you failed to automate this. I suppose it's possible that your support contract is that absurd, but given it sounds like you didn't even check, it seems a lot more likely that you don't know how to automate it and refuse to learn.
You don't get to critique Let's Encrypt, a system built with automatic renewal as a fundamental component, if you refuse to use the very simple to use tools[1] they provide for automatic renewal. Maybe it's the support contract's fault, maybe it's your fault, but it's definitely not LetsEncrypt's fault that you're stuck in 2010 through incompetence or bad contract negotiation. You could spend literally 5 minutes per server and never have this problem again.
All of the cert stuff was hidden behind a very complex series of menuing and more. I keep saying it in different ways: This wasn't just an Apache server.
Could I have pried behind the curtain? Yes? Would it have worked? Most likey! Were there lots of big warnings about not screwing with various sections of the configuration even if I could get to them? Also yes. They really didn't want you to interact with the system beyond a few set points and that was clarified to me in a call with tech support. I didn't like it, but that's what I had to work with.
This just wasn't one a thousand bog-standard Apache rollouts that you could chuck certs into. Want your CSR? Go through their menu system to generate it. Want to install it? Upload it to this specific directory, then hit the menus again.
CertBot is fine for what it does. Great. But it wasn't appropriate for what we had.
Another one of the servers isn't based on Apache at all, it's a compiled executable (yeah, .exe) running on Windows. It starts off of .ini files.
CertBot doesn't work everywhere for everything that has ever served HTTPS in the history of computing. This shouldn't be something I have to mention but I guess I have to do it.
> Another one of the servers isn't based on Apache at all, it's a compiled executable (yeah, .exe) running on Windows. It starts off of .ini files.
So? If you think any of what you've said means Certbot can't be used: again, it's pretty clear that you don't know what Certbot does.
Certbot works anywhere you have a command line and an internet connection, and can be automated if you have cron or a cron-like utility.
There might be a bit more complexity if you have to open a port for callback or store the certs in memory or in a database, but we're still talking < 20 lines of shell code.
> CertBot doesn't work everywhere for everything that has ever served HTTPS in the history of computing. This shouldn't be something I have to mention but I guess I have to do it.
That may be true, but so far all the examples you've given are just examples of you not knowing how Certbot works.
Really dude, I don't know why you want to have an argument about Certbot without knowing anything about Certbot. Anyone who spends a few minutes reading the Certbot docs can see you haven't researched it. Probably nobody is reading this besides me, but if they are, you aren't impressing them, and you aren't persuading me. There's nothing wrong with not knowing anything about Certbot, but it's a bit silly to pretend you do when you don't.
If there are technical reasons you can't use Certbot, you certainly haven't said any of them, and the things you think are reasons just demonstrate a lack of knowledge. Again, there's nothing wrong with not knowing things. But seriously, this would save you so much time! Why wouldn't you at least look into it?
> If they aren't qualified to know when security must exist, they are not likely qualified to implement it
Actually that's incorrect. It's simple to add a LetsEncrypt cert in the right way -- but not easy to come up with all possible ways people might want to attack your site.
@kerkeslager wrote: "But there is always incentive for bad people to hack a server ..."
Those are good reasons, the ones you listed -- and yet another reason is that someone might want to use your website or app, to break into someone's else's website, e.g. by adding a link to, say, Google's login page, but the link is in fact to a password stealing site. -- And it's impossible to know when or if someone has the motivation to do such things to some of one's visitors / users.
> 1. The vast majority of web developers/IT people/etc. aren't really knowledgeable enough to make the call whether something actually needs to be encrypted.
> 2. Just because your system doesn't need HTTPS now, doesn't mean it never will
The web... used to be a place where people, companies, and organizations shared linkable information publicly. The whole point was to make a massive web of interlinked information. If your goal is to contribute to this web, the cost of entry was to buy a DNS name and push out your content on an inexpensive server.
The modern web has greatly degraded this experience and HTTPS adds friction and implementation costs which degrades it even more so more and more information which used to be easily shared and accessible becomes trapped in FaceBook and other walled gardens.
> 3. Even if you don't need encryption for yourself, do it for everyone else who does need encryption.
I get this, but understand that lots of small organizations and private individuals aren't going to pony up the time/ money to bridge over to the fully encrypted web and will just become nodes on FaceBook or other large sites where hosting is "burden-free".
The open web is more or less a memory already and this is just another nail in the coffin.
I too mourn the failure of the open web to gain traction, but I don't think you've identified the causes correctly.
1) I disagree that the modern web has degraded this experience much, if at all. If anything, the tools today are much better, easier, and more mature. Perhaps there's a few extra steps now, but Apache today is much easier to use than Apache in 1996, including things like installing it from a package manager. If you don't consider things like NearlyFreeSpeech and DigitalOcean "walled gardens", these have gotten much better as well. A few years back, I spent 30 minutes installing Wordpress and my completely nontechnical father was able to build a website. So no, things have not gotten harder, they've gotten easier. HTTPS perhaps makes things minimally harder, but many hosts will set up HTTPS for you with a free support ticket these days.
2) Removing the burden of HTTPS, and indeed removing the burden of a great many other things, still wouldn't bring you close to the ease of entry of Facebook or other walled gardens. Even though entry into the open web has gotten easier, it there has been a migration away from the open web because the closed web is so much easier. This isn't a problem that will be solved by getting rid of HTTPS. It's a problem that will only be solved by hacking open source software that does what Facebook et al does.
1. The vast majority of web developers/IT people/etc. aren't really knowledgeable enough to make the call whether something actually needs to be encrypted. Very smart developers have told me they weren't worried about security because their application didn't hold any sensitive data. Sometimes this was because they thought emails and/or passwords weren't sensitive data. I've also had very smart people tell me they weren't worried about security because nobody had any incentive to hack their server. But there is always incentive for bad people to hack a server: even if they can't ransomware you, they can host botnets or child pornography. Having seen situations like this enough, I'm no longer even convinced that even I am correct when I think security isn't necessary. Maybe you're qualified to make that call, but even then, evaluating the system may be harder than just adding security.[1]
2. Just because your system doesn't need HTTPS now, doesn't mean it never will. YAGNI conveniently doesn't specify whether "A" stands for "Are" or "Aren't". In my experience, most systems involving HTTP do eventually have a requirement that passes sensitive data over HTTP, and it would be all-too-easy to forget that channel wasn't encrypted.
3. Even if you don't need encryption for yourself, do it for everyone else who does need encryption. Before HTTPS was required in every browser, users would happily submit their passwords over completely unencrypted channels. Now, browsers will give big warnings that hopefully prevent users from doing this. Those warnings probably aren't necessary if, for example, you're submitting an anonymous comment to a Disqus conversation. But it's important not to normalize clicking past those warnings for nontechnical users, because if they click past those warnings to post an anonymoust Disqus comment, they'll click past them to submit a password. And in a more political sense, normalizing encryption for stuff where it isn't important protects encryption for stuff where it is. "If you are encrypting you must be hiding something bad" is a dangerous narrative which is pervasive in politics, and default-on encryption is one of the best tools against that.
[1] As an example of this, it appears that there are a few attack vectors in your own posts, which you either didn't think of or don't care about, but which I would very much care about as a user of your library catalog.