3 ms·
> Niche stuff where you had one or two vendors in the whole arena Seeing that tells me it is not just some sort of public website, and not something you just w
by kop316 6y ago
> Niche stuff where you had one or two vendors in the whole arena
Seeing that tells me it is not just some sort of public website, and not something you just want any random person to access. Think like PLCs controlling public infrastructure (this is a real scenario in places) If it is on the public internet, I imagine the first thing you go is login to it. If it is HTTP, those credentials are going over the internet in the clear.
- at_a_remove 6y agoNo, the first thing you do is not log in to it. That's the one size fits all mindset that is part of the problem. It says "Everything is running on these two webservers, therefore we just have to cover those two use cases. Everything is super-critical top secret, so of course we will want to do it." The first thing you do is see if the book exists. Logins go to a different system, for something else. If you stop thinking of the Internet as a place where people put in login information and credit card details to get products shipped to them, it becomes a great deal wider and more complex. Sometimes websites are just ... present to provide information. It might be backed up by a database but that is it.
- jasode 6y ago>Sometimes websites are just ... present to provide information. The wikipedia.org website just provides information instead of data input of private sensitive information such as credit-cards. But this doesn't mean high-value targets like Wikipedia should serve plain http.
- at_a_remove 6y agoFortunately, I am not saying that Wikipedia should serve plain HTTP. "That which is not mandatory is forbidden" is what I am trying to avoid; I am moving toward options and choices. HTTP should be an option for people depending on what their needs are and how comfortable they feel with various threat models.
- jasode 6y ago>; I am moving toward options and choices. HTTP should be an option for people depending on what their needs are and how comfortable they feel with various threat models. That's fine and I agree with "http" sometimes being a valid choice. I disagree with how you argued it using phrases like "sometimes a website just provides information instead of credit-cards". The "provides information" is a flawed mental model to base a decision tree on and just confuses people about why https is also important for non-credit-card data. Your later qualifications specifying "threat models" is much better argued. Yes, my internal git web server doesn't need https and I don't want the hassle of getting LetsEncrypt certificate for it. And a toy website on my Raspberry Pi on my local private firewalled NAT'd LAN doesn't need https either. It's not about "public information"; it's about "threats".