←back to thread

246 points nh2 | 1 comments | | HN request time: 0.203s | source
Show context
ndsipa_pomu ◴[] No.41912342[source]
I prefer to assign an external name to an internal device and grab a free SSL cert from LetsEncrypt, but using DNS challenge instead as internal IP addresses aren't reachable by their servers.
replies(9): >>41912368 #>>41912827 #>>41913126 #>>41913387 #>>41913720 #>>41913826 #>>41916306 #>>41917079 #>>41917804 #
candiddevmike ◴[] No.41913126[source]
Obligatory if DNS validation is good enough, DANE should've been too. Yes, MITM things could potentially ensue on untrusted networks without DNSSEC, but that's perfect being the enemy of good territory IMO.

This would allow folks to have .internal with auto-discovered, decentralized, trusted PKI. It would also enable something like a DNSSEC on/off toggle switch for IoT devices to allow owners to MITM them and provide local functionality for their cloud services.

replies(3): >>41913298 #>>41914996 #>>41916478 #
8organicbits ◴[] No.41914996[source]
This would be cool, but I think we're still a far way off from that being an option. DANE requires DNSSEC validation by the recursive resolver and a secure connection from the user's device to that resolver. DoH appears to be the leading approach for securing the connection between the user's device and the resolver, and modern browser support is pretty good, but the defaults in use today are not secure:

> It disables DoH when [...] a network tells Firefox not to use secure DNS. [1]

If we enabled DANE right now, then a malicious network could tell the browser to turn off DoH and to use a malicious DNS resolver. The malicious resolver could set the AD flag, so it would look like DNSSEC had been validated. They'd then be able to intercept traffic for all domains with DANE-validated TLS certificates. In contrast, it's difficult for an attacker to fraudulently obtain a TLS certificate from a public CA.

Even if we limit DANE to .internal domains, imagine connecting to a malicious network and loading webmail.internal. A malicious network would have no problem generating a DANE-validated TLS certificate to impersonate that domain.

[1] https://support.mozilla.org/en-US/kb/dns-over-https#w_defaul...

replies(1): >>41915676 #
candiddevmike ◴[] No.41915676[source]
I'll concede that DNSSEC is not in a good spot these days, but I don't know if that's really due to its design or lack of adoption (it's in similar territory as IPv6 TBH). DoH is (IMO) a poor workaround instead of "fixing" DNSSEC, but it's unfortunately the best way to get secure resolution today.

Putting aside the DNSSEC issues, IMO, DNS should be authoritative for everything. It's perfectly decentralized, and by purchasing a domain you prove ownership of it and shouldn't then need to work within more centralized services like Lets Encrypt/ACME to get a certificate (which seems to becoming more and more required for a web presence). A domain name and a routable IP should be all you need to host services/prove to users that domain.com is yours, and it's something I think we've lost sight of.

Yes, DANE can create security issues, your webmail example is a perfectly valid one. In those situations, you either accept the risk or use a different domain. Not allowing the behavior because of footguns never ends well with technology, and if you're smart enough to use .internal you should understand the risks of doing so.

Basically, we should let adults be adults on the internet and stop creating more centralization in the name of security, IMO.

replies(2): >>41916497 #>>41917214 #
1. 8organicbits ◴[] No.41917214[source]
DANE without DNSSEC isn't a good idea. DoH secures the connection between the user's device and their recursive resolver, but it cannot secure the connection between the recursive resolver and the authoritative name servers. If you're using DANE you need a stronger guarantee that the records are valid.