because the heavy cryptographic computation this way is done on the client, saving computer cycles on the packages mirrors that more often than not are kept alive by volunteers using their own money and time.
> If your website is accessible to normal browsers on the public Internet, than you're not on a network where that's not possible.
*If you are running a network where that's not possible,*
again, thanks for confirming it.
anyway, I could not care about MITM attacks if my website is my personal blog, running on a PI in my living room.
It's the network job to ensure security from MITM, not the website owners'.
> Most free hosts I've looked at recently from Github pages to Netlify have automatic background SSL management for free with zero configuration from the user
And now you have to trust them too, it's not "your personal website" anymore.
Talking about trusting trust... your solution is more delegation to unknown entities.
Doesn't sound so convincing to me.
> No, HTTPS encrypts data according to the certificate authority
No, HTTPS works with self signed certs too, it's browsers that don't want you to and show a scary popup like this
> Rejecting basically free cryptography that substantially improves security
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.
I'm sure you do it, it's free, it improves security!
> People being so concerned about centralization that they start sending messages in plain-text and start arguing with people online that sending messages in plain-text is somehow better for decentralization is at best misguided.
I know how you feel in your paranoia fueled World and I feel for you, but I tell you, dear friend, that you're wrong.
Nobody said what you're saying they did.
Use the easier solution available given the circumstances is simply sign of intellect.
You're not stupid, I'm sure of it, so why you acting like you were?
> 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.
funnily enough, Letsencrypt knows it and in fact they use HTTP [1]
This is the most common challenge type today. Let’s Encrypt gives a token to your ACME client, and your ACME client puts a file on your web server at http://<YOUR_DOMAIN>/.well-known/acme-challenge/<TOKEN>. That file contains the token, plus a thumbprint of your account key. Once your ACME client tells Let’s Encrypt that the file is ready, Let’s Encrypt tries retrieving it (potentially multiple times from multiple vantage points). If our validation checks get the right responses from your web server, the validation is considered successful and you can go on to issue your certificate. If the validation checks fail, you’ll have to try again with a new certificate.
Our implementation of the HTTP-01 challenge follows redirects, up to 10 redirects deep. It only accepts redirects to “http:” or “https:”, and only to ports 80 or 443. It does not accept redirects to IP addresses. **When redirected to an HTTPS URL, it does not validate certificates** (since this challenge is intended to bootstrap valid certificates, it may encounter self-signed or expired certificates along the way).
2. LetsEncrypt has restrictions on HTTP-01 validation (no wildcards) that are designed to mitigate the fallout from exploits of this vulnerability.
3. There are proposals active to try and allow website operators to disable HTTP-01 validation entirely using DNS. It's not infeasible to me that HTTP-01 could end up being retired eventually, at least for websites that have public DNS records.
And most importantly:
4. This is treated as a vulnerability
LetsEncrypt is not saying, "MITM attacks don't matter and HTTP is good enough". They're working on a fundamentally difficult problem (how to do identity verification for the first time when all communication methods are subject to attack), and they are rolling out the best solutions they can come up with at this time; solutions that are tangibly better than the status quo of HTTP.
That is very, very different than saying, "oh, HTTP is fine for this, we can ignore working mitigations that would be easy to deploy." If there was an easy way to completely mitigate HTTP-01 attacks, LetsEncrypt would be doing it.
> 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.
I can check the certificate, if I have a copy from a trusted source.
The point of the scary warning (that I cannot disable) is that nowadays tech thinks of people like children to be protected from themselves, instead of educate them to understand the risks.
> There is no good reason not to have encryption on a publicly facing website
There are, actually.
None of them are good reasons for you.
An example from another post of mine [1]
Imagine you built an app for weather reporting, the app downloads static json from a server using the hardcoded ip address
What is the added value of putting HTTPS in front of the stupid web server serving stupid static Json?
What would anyone gain by MITM it, admitting someone can or want to do it?
There are many other ways to break an app like that...
If you can put yourself in the middle, you can simply break the trust chain and you broke the app, even on HTTPS.
there's no need to replace the content.
Assuming there's value in doing it.
> neither of which are good arguments against encryption
Who ever said no to encryption or HTTPS BTW?
the original post talked about HTTPS everywhere, that's what are we talking about, is it so hard to stay on topic?
Anyway, I can send encrypted data over HTTP if I wanted to.
> It's just stubbornness, paranoia that LetsEncrypt secretly has some plan to control the world
None of that corresponds to nothing that's been said here, not by me anyway.
It's just that HTTPS doesn't protect anybody from a stubborn malevolent actor with enough resources and motivation.
It should be said, instead of pretending that HTTPS is completely fine.
HTTPS is fine like OpenSSL "audited by million of developers' eyes in the World thanks to open source" was fine.
> This is a bad security policy and should be discouraged.
The fact that it's their job, doesn't mean encouraging it as a policy.
It's just a fact.
If you don't agree, ok, but if you agree why twist my words?
> if you are on a public network transmitting data then it is your job to care about MITM attacks.
I'm not transmitting, I'm delivering. Which is different.
Deliver happens on demand.
Transmitting is more similar to what a broadcaster does.
And even though broadcast radio and TV frequencies have been open and public for decades, they rarely have been hijacked.
Main reasons are: lack of resources and because it's prohibited by laws that are actually enforced.
> It's why we've started to move towards E2EE in many situations.
Which is, in fact, better than HTTPS as it is today in my opinion.
Every example you're bringing up for ignoring HTTPS in the real world is by services that have alternative methods for protecting against MITM attacks -- methods that are built directly into clients that don't require external validation. You are trying to use that as justification for why you don't need to care about MITM attacks; but setups like Debian, LetsEncrypt, etc... are fundamentally different from the types of situations you're talking about where you want to ignore HTTPS. You are arguing that you should be able to ignore security measures, and that users shouldn't be warned that you are doing so.
----
Fortunately, I did some thinking about this, and I do feel I've been approaching this discussion in the wrong way. And I think I've managed to come up with a solution that can make both of us happy:
- You don't need to worry about MITM attacks, you can leave that all up to the network, it'll handle keeping the users secure. That's it's job, not yours. Basically, you can do whatever you want, and the network will protect its users.
- The way the network will protect its users in this particular instance will be by putting big scary warnings in front of sites that it can't guarantee are delivering their content securely.
So everybody wins. I think this is probably the best solution; you get to deliver your content however you want, and the network takes whatever measures it deems necessary to keep its users secure.
Also, adding on to this Debian has built-in MITM protection. But in order to trust that MITM protection, you need to trust your Debian install, which you may have downloaded from the internet. You can only trust your Debian install if you can trust your download, and you can only trust your download if you used HTTPS (or some other MITM-proof scheme).
But I agree this conversation is going nowhere. TBH, I think the person you're replying to just isn't very smart. They can follow a single logical step, e.g. "I use this thing [Debian] and it doesn't use HTTPS." But they're incapable of making the N logical steps required to get from their example to the root of trust. In the example above, the root of trust is the download source of Debian.
so YES, they are still doing it.
thanks for confirming.
Anyway, how do you donwnload those PGP keys in your opinion?
http://subkeys.pgp.net/keys/ http://pgp.mit.edu/ http://keyserver.ubuntu.org
Why they do it?
because the heavy cryptographic computation this way is done on the client, saving computer cycles on the packages mirrors that more often than not are kept alive by volunteers using their own money and time.
> If your website is accessible to normal browsers on the public Internet, than you're not on a network where that's not possible.
*If you are running a network where that's not possible,*
again, thanks for confirming it.
anyway, I could not care about MITM attacks if my website is my personal blog, running on a PI in my living room.
It's the network job to ensure security from MITM, not the website owners'.
> Most free hosts I've looked at recently from Github pages to Netlify have automatic background SSL management for free with zero configuration from the user
And now you have to trust them too, it's not "your personal website" anymore.
Talking about trusting trust... your solution is more delegation to unknown entities.
Doesn't sound so convincing to me.
> No, HTTPS encrypts data according to the certificate authority
No, HTTPS works with self signed certs too, it's browsers that don't want you to and show a scary popup like this
https://help.univention.com/uploads/default/original/2X/5/5e...
Which is not even true, the connection is private, it is simply privately private and not "trusted" by any know CA.
which could not be a problem if I trust the website and who runs it.
But, again, the scary warning page will scare people away, while the connection is working as intended.
> I was kind of leaving privacy off the table
You are confusing privacy with secrecy.
HTTPS is not private, the connections being made are still visible.
> you don't understand what "panacea" means
I'm Italian with Greek roots, we literally invented the word.
Its original meaning is "plants that cure everything".
That's why my remarks.
It's still a plant name! (https://www.google.com/search?q=p%C3%A0nace)
> Rejecting basically free cryptography that substantially improves security
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.
I'm sure you do it, it's free, it improves security!
> People being so concerned about centralization that they start sending messages in plain-text and start arguing with people online that sending messages in plain-text is somehow better for decentralization is at best misguided.
I know how you feel in your paranoia fueled World and I feel for you, but I tell you, dear friend, that you're wrong.
Nobody said what you're saying they did.
Use the easier solution available given the circumstances is simply sign of intellect.
You're not stupid, I'm sure of it, so why you acting like you were?