Comment by lxgr

Comment by lxgr 2 days ago

Or is operating a local-only mailserver not connected to the larger internet? I guess that's a lazy or stupid thing too, these days...

I'm a fan of having TLS on by default for everything on the Internet, but I'm seriously annoyed by the collateral damage to local self-hosted services the implementation of that has caused.

It shouldn't be this hard to e.g. host web server on my local network that browsers grace with "trusted website APIs", but it really is. Why on earth do I need to set up Letsencrypt (and by extension at least DNS) on a local website if I want to be able to use a game pad on it, for example!? https://developer.mozilla.org/en-US/docs/Web/Security/Secure...

We absolutely need a localhost and local domain exemption for both TLS/X.509 certificate validation and web APIs. For example, TOFU seems like a much better model for that use case than trying to bend the "public Internet" model until it fits. SSH has had considerable success in that model, for example.

stephenmac98 2 days ago

You have to consider the rarity of your use case vs the use case they're defending against.

How often do you think someone tries to connect their gamepad to a local server? Not never, but the total amount of users doing it is probably high tens or low hundreds at most

Compare that to how often gamepad users try to connect to a malicious website - probably hundreds or ever thousands of times a day.

Loosening certificate validation further expose the many less than competent users to risk, and the potential impact both on the customer base and on the product's reputation are significantly higher than the risks of making it cost a couple bucks a year to allow your gamepad to connect to a local server.

For something like a computer, there is a legitimate argument for allowing the user to bypass SSL/TLS restrictions (after some resistance) because laptops are used for development.

I can almost guarantee that the gamepad developers had an options for certificate validation bypass in it's developer options, but they're not gonna expose that needlessly when it offers no benefit, but exposes their customers to additional risk. Your gamepad is likely not a development device after all

Reply View 8 replies

lxgr 2 days ago

Any malicious website can access my gamepad, since it can trivially get a Letsencrypt certificate – the only requirement for getting "secure origin" API access.
What exactly is this restriction preventing me from, then? (And what does a malicious website do with my gamepad data anyway?)
> Not never, but the total amount of users doing it is probably high tens or low hundreds at most
Yes, I'm fully aware that local hosting is rare in the grand scheme of things, but I think you're vastly underestimating the potential. It's currently not even possible to do much better even as a commercial NAS provider, and these are somewhat popular.
A big part of that also seems like a chicken and egg problem: Fewer and fewer users do it because it's getting harder and harder, thanks to browser standards and OS defaults being largely driven by stakeholders that have no interest in it becoming easier.
Yes, none of this is an evil conspiracy; it's just a question of incentives and priorities in the end. I just find it so sad how willingly even a "hacker" audience here embraces the move towards more and more centralization, on more than one dimension. (Peer-to-peer vs. client-to-server, "trusted CA only" vs. trust on first use, cloud vs. self-hosting etc.)

Reply View | 7 replies
- stephenmac98 2 days ago
  
  Allowing self-signed certificates creates a higher risk for MITM attacks. Sure you can trivially get a letsencrypt certificate once you register a DNS entry, but you can't trivially get a letsencrypt certificate which validates google.com
  If you control the local network it's trivial to redirect traffic intended for elsewhere, like "google.com", and trivial to have the server it redirects to present a certificate with "google.com" in it's subject or SAN.
  What would happen on a laptop is you would be hit with a certificate validation error because it was self signed, and on the laptop you have the ability to bypass it, but that ability to bypass is very dangerous. Most users will not properly check a certificate before clicking to trust it.
  As far as what could be done, "this is a low value device to an attacker" is not a security measure, but beyond that I'm sure that people have bought games on a gamepad, and anything which involves financial transactions has the potential for malicious behavior with severe consequences
  
  Reply View | 6 replies
  
  lxgr 2 days ago
  
  Then only allow self-signed certificates for literal IPs or those on .local (and other private/reserved TLDs).
  Right now, .local is completely impossible to encrypt, as well as impossible to use “secure origin” APIs on, which is a shame.
  
  Reply View | 5 replies

diogocp 2 days ago

> We absolutely need a localhost and local domain exemption for both TLS/X.509 certificate validation and web APIs.

localhost is already considered a secure origin.

Local networks are horribly insecure; easily the most likely place for a MITM attack.

Reply View 1 reply

lxgr 2 days ago

Ah, that’s good – it’s been a while since I last had to work around that.
And I generally agree on local networks being insecure. So how about making them more secure instead of marginalizing them even more?
TOFU for TLS certs on .local (for Zeroconf, and maybe something else/new for local DNS) would be a huge step forward from unencrypted and unauthenticated HTTP. Such sites could even still be displayed with a broken padlock or whatever HTTP gets these days to not create any false expectations by users.

Reply View | 0 replies