3 ms·

You are making excellent points for using globally resolvable DNS + Letsencrypt. :) None of these problems exist with that solution. Unless you enable AXFR, you

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.
- janosdebugs 3y ago
  The problem is that even if we assume this (or anything similar) is a good thing, we can't simply wish it into existence. The world is going into a different direction, everything is ever-more connected and apart from a very small minority, most local network admins are fine with Letsencrypt certificates or rolling their own CA. If someone would want to put in the advocacy and development work, this would need to be written up in a formal fashion, probably in a scientific journal and/or an RFC published. Then there would need to be an implementation for at least one of the major OSes so security researchers can get their hands dirty with it and iron out the bugs. Once all this is done, you still need to convince Microsoft, Apple and Google to ship it in their OS because this is not a browser-only solution and needs OS support. And at this point the thing is probably pretty dead because their big customers are happy to run their own CA infrastructure, which leaves only a tiny minority of sysadmins for small systems that could ask for it. Not enough for these big companies to care because these small customers moving to Linux won't affect their bottom line. I would rather spend my time to advocate for simpler CA management or other verification methods with LE. Honestly, I think the FQDN and Letsencrypt solution is fine. I've been using FQDNs for server names for a good 15 years now and I never had a problem with it. The people who didn't, however, had a bunch of pain to deal with, from having to merge networks to weird trust issues. I still remember the headless running around when .dev became a TLD and suddenly there was a conflict with oh so many folks' internal hostnames. Nothing about DNS says it has to be on the Internet. If you really want, you can even run a split DNS to make it only available in your own network, you just need to make the Letsencrypt verification work over the Internet.

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.

janosdebugs 3y ago
The problem is that even if we assume this (or anything similar) is a good thing, we can't simply wish it into existence. The world is going into a different direction, everything is ever-more connected and apart from a very small minority, most local network admins are fine with Letsencrypt certificates or rolling their own CA. If someone would want to put in the advocacy and development work, this would need to be written up in a formal fashion, probably in a scientific journal and/or an RFC published. Then there would need to be an implementation for at least one of the major OSes so security researchers can get their hands dirty with it and iron out the bugs. Once all this is done, you still need to convince Microsoft, Apple and Google to ship it in their OS because this is not a browser-only solution and needs OS support. And at this point the thing is probably pretty dead because their big customers are happy to run their own CA infrastructure, which leaves only a tiny minority of sysadmins for small systems that could ask for it. Not enough for these big companies to care because these small customers moving to Linux won't affect their bottom line. I would rather spend my time to advocate for simpler CA management or other verification methods with LE. Honestly, I think the FQDN and Letsencrypt solution is fine. I've been using FQDNs for server names for a good 15 years now and I never had a problem with it. The people who didn't, however, had a bunch of pain to deal with, from having to merge networks to weird trust issues. I still remember the headless running around when .dev became a TLD and suddenly there was a conflict with oh so many folks' internal hostnames. Nothing about DNS says it has to be on the Internet. If you really want, you can even run a split DNS to make it only available in your own network, you just need to make the Letsencrypt verification work over the Internet.