4 ms·

>I DO NOT want to put my family's or my personal-project data on the internet! DNS-01 challenges addresses this, the webserver never needs to be exposed to the

• xg15 3y ago
  > How would the alternative work? It's not an easy problem to solve, but I think it would be possible to extend PKI to make it work for local networks without internet access. An approach could work as follows: Dedicate a special TLD for "local-only domains". Such domains are only expected to be valid inside a specific LAN, analogous to 192.168.* IP addresses. (In fact, several TLDs with that kind of intended use already exist [1]) Specify some way how a local network can announce a CA specifically for that network (maybe through a DHCP extension, a special "well-known" hostname or IP address or a field in a wifi beacon message) When a user navigates to a local-only domain, the site's cert is validated using the network's CA. The CA is only valid for local-only domains and only while connected to that specific network. This would allow using PKI and encrypted connections inside a LAN, would not require internet access or 3rd party services and would also not compromise the security of domains on the internet. [1] https://unix.stackexchange.com/questions/92441/whats-the-difference-between-local-home-and-lan#92517 https://unix.stackexchange.com/questions/92441/whats-the-dif...
  • janosdebugs 3y ago
    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 that the packets won't be going round the globe 3 times. 2. You are proposing a whole new, as of yet unresearched verification mechanism to TLS, which won't be supported by a whole lot of devices for a long time. I just had to downgrade a server of mine to TLS 1.2 because a high profile software couldn't deal with 1.3. 3. DHCP is inherently insecure and setting up a rogue AP is also not too difficult outside of an enterprise environment where certificate rollout is already not a problem. Ideal for hijacking an intranet connection covertly. 4. The proposed CA would not have the benefit of public transparency logs, so it would not meet the minimum requirements currently set forth by the browsers to trust a CA. 5. What happens if you are connected to more than one network at a time? Which one gets authority over the special TLD? 6. Who guarantees that the connected client uses the mandated DNS servers to resolve the special domain? This is not a viable proposal for more than a handful of cases, but makes it a lot less secure for everyone else.
    • 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.