> Anyway, how do you donwnload those PGP keys in your opinion?
You are completely missing the point. Debian does key verification. It does not naively trust that nobody has MITMed the connection. It's not just sending you code and keys and then shrugging and saying, "well, the network should have made sure they were good, so we're just going to run the package."
Debian is not an argument for disregarding MITM attacks. Debian cares about MITM attacks. Debian is also not an argument for ridiculous claims like "it's the network's job to protect me." Debian does not trust the network.
----
> Which is not even true, the connection is private, it is simply privately private and not "trusted" by any know CA. But, again, the scary warning page will scare people away, while the connection is working as intended.
The browser can not guarantee that connection is private. The reason why a browser shows a warning for a self-signed certificate is because there is no guarantee that the certificate itself is not a MITM attack.
This is entirely sensible and it would be grossly irresponsible for the browser not to show a warning. The way you get around that warning is you manually verify the certificate in a way the browser can see, and once you've done that, the warning goes away.
Note that Debian does the exact same thing, if you download a package that isn't linked to a key that your package manager knows to trust, it gives you a warning. Because of course it does, it would be ridiculous for it not to.
----
> Talking about trusting trust... your solution is more delegation to unknown entities.
What are you talking about? If you are using a managed host then you are already trusting that website to send files and host files. It's ridiculous to act like them also holding a certificate somehow makes you more dependent on them. Having a web host manage your SSL adds no additional dependencies or vulnerabilities to a managed site.
It's like using a managed host to serve HTML files and then getting upset that they also serve CSS files. It doesn't make any sense, you are trusting that website to send files. Not everything is a conspiracy to take away control. It's still "your website" to the extent that you trust "your website" to be hosted on somebody else's computer.
And yes, I am proposing delegation, because if you don't know how to do security then the responsible thing to do is to delegate to someone who does know how to do security.
On the other hand, if you are self-hosting off a Raspberry Pi in your living room, then no, I completely disagree that LetsEncrypt is too complicated for you to set up, or that it adds any substantial increase in complexity or difficulty to that self-hosted website, and I consider it to be pure FUD to try and claim otherwise. If you know how to set up DNS for a self-hosted website, then you are capable of setting up LetsEncrypt.
Now, if your website is only accessible within your NAT, then do whatever the heck you want, I couldn't care less. Send your data over unencrypted Bluetooth for all I care. But it's still not fantastic security and also why the heck are you coming onto public forums and arguing about what public websites do? If you're on a public network, you have to care about MITM attacks.
----
> Its original meaning is "plants that cure everything".
Spinach and carrots do not cure everything. They aren't even a nutritionally complete meal on their own, let alone cure every disease.
----
> Yeah, I imagine you lock yourself in your house and set the alarm every time you exit from a room and then disable it every time you enter, after unlocking the door.
Hey, at least I didn't remove the locks from my car doors because I was scared that the Toyota was going to use them to take control of my car.
The argument here is not that anything that increases security is good, the argument here is that when you have an effectively zero-cost security improvement for most people, and that security improvement protects people against real attacks that have been regularly exploited by both criminals and governments -- maybe it makes sense to turn those security measures on.
Metadata privacy as well as general browsing privacy is increasingly being shown to matter more and more online, not less and less. When we're in a situation where increasingly it's becoming easier and easier to use metadata in nefarious ways, it actually makes a lot of sense to just universally protect metadata and browsing privacy.
On that note:
> if my website is my personal blog
Imagine being so confident that your blog will never give important enough advice or say anything controversial or impactful enough to warrant encrypting it. Imagine being so confident that your blog will always be so mainstream that readers will never have a reason to hide that they're looking at it.
And then imagine thinking that a blog that innocuous and uncontroversial would ever need to care about how it's hosted or who's doing the hosting. If you're so convinced that nobody will ever care enough about what you write to warrant encryption, then stick your blog on Github pages and save yourself the extra electricty costs, because nobody is going to care about censoring something that isn't important enough to warrant encrypting.
----
> Use the easier solution available given the circumstances is simply sign of intellect.
There is no good reason not to have encryption on a publicly facing website: it costs nothing, it has substantial upsides, and the only reason not to do it is stubbornness.
The only arguments I've heard against encryption are centralization and complexity, neither of which are good arguments against encryption. Relying on a network for security makes your website less portable and increases your reliance on 3rd-party infrastructure far more than HTTPS does. Out-of-band verification is far more complicated and computationally expensive than in-band message verification, both in computing terms and for your users. Neither are good arguments.
It's just stubbornness, paranoia that LetsEncrypt secretly has some plan to control the world, outdated attitudes about the computational costs of TLS. I'm not going to pretend it's a respectable security position, the entire security industry has rejected arguments against HTTPS.
If you're that concerned about Internet centralization or about companies taking away control of "your website", then honestly, go complain about DNS in general; current DNS systems have way more impact on centralization than encryption does. Being anti-HTTPS is such an arbitrary, misguided hill to die on.
----
> It's the network job to ensure security from MITM, not the website owners'.
This is a bad security policy and should be discouraged.
If you can guarantee security within a network, great. But effective security is not about playing a blame game, if you are on a public network transmitting data then it is your job to care about MITM attacks. Security at the network level rather than at the message level has been consistently shown to be bad policy pretty much across the board. It's why we've started to move towards E2EE in many situations.