4 ms·

Several problems with this proposal: 1. Who defines what the local network is and why should this environment be trusted more? The IP address doesn't guarantee

• xg15 3y ago
  1 + 3: DHCP, wifi identification or what you can reach with a broadcast would be examples. If that's too insecure, out-of-band identification would also be possible, i.e. a QR code that contains a SSID, a hostname/IP address where the CA cert can be downloaded and a hash of the cert. I don't see why it's important how the packet is actually routed as long as you have established a root of trust. 2: Yeah. So? The worst that can happen to a device that doesn't have support is that it sees an invalid certificate. I don't think widespread support would be necessary. The only software where support would be essential would be browsers. 4: Neither is a local root CA today. The entire point of the proposal is that it doesn't require any third parties. To make up for this, the CA is only valid for local domains, so you can't generate rogue certificates for google.com anyway. 5: That's a good point, but strictly speaking, the problem already exists today: what happens if you're connected to two networks which route the same IP address range? Or which reuse the same hostnames? One option would be to add some sort of network identifier to the hostnames to make them unique. This might make the domains unwieldy to use though. 6: The same thing that "guarantees" that the client uses the network's CA for validation: The client itself, that hopefully correctly implements the spec. You have the same problem with the "split DNS + LE with DNS validation" approach: If a client has 1.1.1.1 hardwired for DNS resolution and you only serve A/AAAA records inside the network, the client won't see your server. That's why even DoH will fall back to the network's DNS servers if it can't resolve a domain over the DoH server. > This is not a viable proposal for more than a handful of cases, but makes it a lot less secure for everyone else. Local-only hosts may be less secure than internet hosts, granted - but how would this reduce the security of everyone else?
  • xnyan 3y ago
    >out-of-band identification would also be possible, i.e. a QR code Any out-of-band method of enabling what you are talking about is necessarily going to prompt the user with the same kind of serious-looking security prompt they would see when adding a self-signed cert to the OS certificate store.
  • janosdebugs 3y ago
    You are making excellent points for using globally resolvable DNS + Letsencrypt. :) None of these problems exist with that solution. Unless you enable AXFR, your hostnames won't be easily visible to the outside world and wildcard certificates are a thing too. Specifically: 1,3,4,6: You want a seamless experience for the user and are assuming that the user is capable of making the decision to trust a network operator. This is not a decision an average user can make. Say, I set up a rogue AP for your university network which uses this special TLD. You connect to my AP, log in to your uni account on the special TLD, and now I have your credentials because you went through my reverse proxy. Very easy to pull off, almost impossible to reconstruct after the fact. QR codes, etc don't offer any protection here. 5. AFAIK the problem doesn't exist as far as domain names are concerned, search domains work across multiple networks. mDNS can also work across multiple networks to resolve host names. For IP addresses this is a problem, which the abundance of possible locally admininstered addresses with IPv6 will hopefully solve (ULA address ranges). If you want to have full control over your local network environment, that's another thing, but you can't then expect everyone else's devices to automatically trust your environment. You'll have to jump through the hoops of making that environment trusted on the endpoint devices too. Any attempts of making peer to peer trust a thing have failed miserably over the last decades and nobody really seems to put any effort into writing, implementing and proving these standards anymore. It's too easily abused and determining trust is beyond the capabilities of the layperson, heck it often trips up experts too.
    • xg15 3y ago
      Yeah, you have a point. The fundamental problem is always: How can I keep an adversary from cloning/proxying a legitimate site then trickung users into visiting it. It's a hard problem even if there is a centralized authority and pretty much still open for decentralized systems. I still think however that there are some properties of local networks that make this less risky: - an attacker needs to be physically close to their victims in some way (or at least get devices into physical proximity): The rogue access point has to be located somewhere, someone has to tape over the QR codes, someone has to plug into the local network or connect to WLAN to send spoofed ARP/DHCP/DNS replies, etc. Compare that to phishing/typosquatting attacks on the internet where an attacker can be anywhere on the globe and can make their site look legitimate with a simple LE cert. - an attacker is more at risk of being exposed. i.e. if someone keeps spoofing the university network, people might start to try and locate the wifi signal and knock on doors. That's a lot more risk than phishing/typosquatting for a lot less reward: Even if the attack works perfectly, you can only impersonate the local-only domains, not internet domains. (In fact, we don't currently live in an HTTPS-only world, so there would actually be some value for an attacker to spoof some campus wifi right now. I haven't heard of any incidents in that regard, so that leads me to believe that the risks are to high compared to the rewards) - there are lots of situations where spoofing the CA information would require you to do a full supply-chain attack, such if I connect directly to a device using a cable or NFC connection; QR code stickers put directly on the device; if I manually add the device of another person to a wifi network I know, etc. (Those are slightly different use cases than "art installation" etc. I'd say they are still valuable though, e.g. for frictionless setup of local-only IoT devices) > If you want to have full control over your local network environment, that's another thing, but you can't then expect everyone else's devices to automatically trust your environment But that's the point, I don't want them to fully trust my environment. It's perfectly reasonable that there is no way to override the CA of say, google.com without an extremely scary security warning. However, I'd like a way to offer some sort of website from a local network without causing a huge hassle for everyone who wants to use it or having to pretend I it's an internet domain.