0
On my network I've configured a DNS domain search in resolv.conf
so that if you call getaddrinfo
on simple hostnames it will return results for their FQDN.
$ host wiki
wiki.example.com has address 10.0.0.2
$ dig +short wiki
$ dig +short wiki.example.com
10.0.0.2
(The DNS server will not respond to unqualified names, it's all being done in libc
.)
I've configured a TLS certificate on the webserver listening at https://wiki.example.com
, the TLS certificate is issued by a public CA for the CN wiki.example.com
.
Prior to configuring HTTPS, unqualified names could be used in the browser. So entering wiki/
into chromium (e.g.) would work. Now that TLS is configured however, browsers will complain about a common name mismatch on the certificate because they did a DNS lookup on / connected to wiki
but the TLS certificate presented is for wiki.example.com
.
This is unfortunate, as it's one of those security vs. usability trade-offs that doesn't really need to exist. Passing AI_CANONNAME
to getaddrinfo
will do a reverse DNS lookup on the address that wiki
resolves to and that will (at least in some cases) return wiki.example.com
. There may be mechanisms beyond getaddrinfo
that could expose the domain search in a more robust way.
My question is whether there's a way to setup the OS / browsers such that they're aware of the domain search? Ideally, if chromium saw that an unqualified hostname was entered, it would append the domain before proceeding with any further logic. Then the TLS certificate would match and all would be well.
I can think of a few sub-optimal ways to achieve what I want:
- Detect if the
Host
header on HTTP connections has an unqualified name and serve an HTTP redirect to the FQDN over HTTPS. - Issue the unqualified name as a SAN on the TLS certificate.
- Use browser bookmarks and stop using unqualified names.
- A "jump page" (i.e., a page full of links, hosted at a memorable location) which uses FQDNs.
The first has several problems. First is that it only works if the initial connection was HTTP, which is going the way of the dinosaur thanks to things like HSTS. Second is that it requires intimate control of the server, which is not always possible (for example, low-power IoT devices with web interfaces).
The second is not possible if certificates are issued from public CAs (which is a requirement to pass the Significant Other / house guest test).
The third is not useful due to also failing the Significant Other / house guest test.
The fourth may work, depending on how easy to convey the address of the jump page is. This is on the same order of magnitude of difficulty as conveying the WiFi name and password.
It’s not the job of the browser to handle DNS at all. If you want, you can use the domain search DNS option, and you have. That’s the consequences of not using FQDNs. It’s a serious security concern and the browser shouldn’t be changing that. – Appleoddity – 2019-09-15T01:48:39.043
@Appleoddity I'm not sure if I agree with your opinion that having the browser append the search domain is a serious security concern. How is it any worse than what the local DNS resolver is already doing? The same thing is happening, but it's happening in a more user-transparent way if the browser does it. – Huckle – 2019-09-15T03:30:43.403