-
Notifications
You must be signed in to change notification settings - Fork 59
DNS Settings
Mosh for Chrome supports the use of Google Public DNS-over-HTTPS to resolve hostnames to IP addresses. Checking this box circumvents the system resolver (and thus the resolver specified by your local network) in favor of this secure method of looking up domain names in the DNS. This also permits SSHFP records to be looked up and validated with DNSSEC, which is something not available through the resolver API for Chrome apps.
Google Public DNS-over-HTTPS is an alternative way to access the well-known Google Public DNS (aka 8.8.8.8). It provides several advantages over using the system resolver:
- Security: No one between you and Google Public DNS can tamper with the question or the answer of a DNS query.
- Authenticity: If the domain name you're looking up is signed with DNSSEC, the result is validated by Google Public DNS.
- SSHFP: Domain names signed with DNSSEC can also publish host key fingerprints as SSHFP records, further enhancing security.
- Privacy: No one on the network can see what names you're looking up.
This feature isn't for everyone, which is why it is not on by default. Caveats include:
- It circumvents the local network name server. While this is a feature to some, it breaks looking up internal names that are not visible publicly. This is common on corporate networks.
- Google can see what names you're looking up. This is a trade-off, as otherwise your network resolver can see this (usually your ISP). Furthermore, anyone on the network can easily sniff your DNS queries when you're not using DNS-over-HTTPS. See the Google Public DNS Privacy Policy.
When this box is checked, if the domain name of the machine to which you're connecting includes an SSHFP record, and if that record can be authenticated with DNSSEC, then the SSH host key fingerprint(s) in that SSHFP record will be trusted and used to validate the host key fingerprint transmitted during the SSH session setup. This means you will not be prompted to inspect and validate the fingerprint of the host key.
The primary benefit of SSHFP records is that you can enjoy validation of the host key without having to inspect the host key fingerprint manually. Users are notoriously bad about not validating host key fingerprints, and just saying "yes" and getting on with life. This leaves open the possibility of a man-in-the-middle attack.
SSHFP records also significantly simplify rotating host keys. The administrator simply needs to update the SSHFP record in DNS, and validating clients will pick up on that without ever bothering the user.
While SSHFP validation is quite safe and reliable (and arguably considerably more so than the usual "let the user check it" approach), it is possible that the SSHFP record in DNS for a domain name may not be correct, or that a nefarious actor in the DNS delegation chain for the domain name may be issuing verifiable but forged information. Therefore, this option is not on by default.
If you prefer a belt-and-suspenders approach, you can leave this checkbox unchecked and continue to do manual validation of the host key fingerprint. You'll still enjoy a message on the screen indicating whether or not the SSHFP record was validated, but Mosh for Chrome will not assume to trust it without your consent. As always, once you say "yes" to the fingerprint, it is stored so that you do not have to be prompted again.
Getting your domain setup with DNSSEC is getting easier by the day. Google Domains, Google Cloud DNS, and CloudFlare all offer fully-managed DNSSEC at no additional cost, and all support the SSHFP record type.
If you run BIND, DigitalOcean has a decent article on how to get it going, and you can easily "salt to taste" for most Linux setups whether or not you use DigitalOcean. However, a word of caution: Running DNSSEC on your own requires care and feeding, lest your zone commit "DNSSEC Suicide" due to signatures expiring before being regenerated. Unless you are prepared to manage that risk (think monitoring, automation, playbooks, etc.), it is recommended to use one of the aforementioned DNS hosting providers that support DNSSEC.
Once your domain is setup with DNSSEC, learn how to generate SSHFP records by reading this post on StackExchange.
Google Public DNS is the first large public DNS resolver to offer an HTTPS recursive DNS query protocol. The code has been written in a modular way, so it is easy to add more implementations as other public resolvers and name server implementations start offering similar functionality. Pull requests are welcome.
DNSSEC implies trust in all actors in the DNS delegation chain, all the way up to the root. In other words, if you lookup example.com with DNSSEC, you are trusting example.com, .com, and the root nameservers. The root nameservers are managed by ICANN, and many top-level domains (TLDs) such as .com, are regulated by ICANN. Note, though, that not all TLDs are governed equally (think ccTLDs like .us, .uk, .cn, .sy). And there maybe be a 4th or 5th party involved, such as when using a DNS hosting provider or using a domain delegated to you by a cloud service underneath that service's domain. A chain of trust, like any other chain, is only as good as its weakest link.
That said, there are plenty of actors that can ruin your day with bogus certificates for SSL/TLS (i.e. HTTPS). DNSSEC leans toward fewer actors as opposed to a large number of root CAs. There are pluses and minuses between these approaches.
In the interests of full disclosure, I (@rpwoodbu) was a member of the Google DNS team, which includes Google Public DNS and Google Cloud DNS.