3 ms·

> Debian does not trust the network. Who ever said they do? Why are you side tracking the discussion? > The browser can not guarantee that connection is priv

> Debian does not trust the network. Who ever said they do? Why are you side tracking the discussion? > 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. [1] https://news.ycombinator.com/item?id=31517326 https://news.ycombinator.com/item?id=31517326

danShumway 4y ago
This is going in circles. 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.
- deleted 4y ago
  [deleted]
- DANK_YACHT 4y ago
  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.

danShumway 4y ago

This is going in circles. 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.

deleted 4y ago
[deleted]
DANK_YACHT 4y ago
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.