Headline
CVE-2018-21029: RFE: Certificate checking for Resolveds DNS over TLS feature · Issue #9397 · systemd/systemd
** DISPUTED ** systemd 239 through 245 accepts any certificate signed by a trusted certificate authority for DNS Over TLS. Server Name Indication (SNI) is not sent, and there is no hostname validation with the GnuTLS backend. NOTE: This has been disputed by the developer as not a vulnerability since hostname validation does not have anything to do with this issue (i.e. there is no hostname to be sent).
Certificate validation is still incomplete up to at least v243-425-g09ee387e08, even with the PR from @irtimmer in #12815. “certificate verification” in GnuTLS:
if (server->manager->dns_over_tls_mode == DNS_OVER_TLS_YES)
gnutls_session_set_verify_cert(gs, NULL, 0);
However, it only checks whether it uses a valid certificate chain. I did an experiment (redirect to any TCP/443 server with a valid certificate) and found that systemd-resolved would still accept certificates for other domains (iptables -t nat -A OUTPUT -p tcp --dport 853 -d 1.1.1.1 -j DNAT --to-destination $https_host:443).
To solve this, setting the IP address in place of the host (NULL above) would probably not work. You probably have to use gnutls_x509_trust_list_verify_crt2.
On the other hand, systemd-resolved built with OpenSSL should do proper certificate validation, but I have not verified this:
if (server->manager->dns_over_tls_mode == DNS_OVER_TLS_YES) {
X509_VERIFY_PARAM *v;
const unsigned char *ip;
SSL_set_verify(s, SSL_VERIFY_PEER, NULL);
v = SSL_get0_param(s);
ip = server->family == AF_INET ? (const unsigned char*) &server->address.in.s_addr : server->address.in6.s6_addr;
if (!X509_VERIFY_PARAM_set1_ip(v, ip, FAMILY_ADDRESS_SIZE(server->family)))
return -ECONNREFUSED;
}
At minimum it would be great to have a configurable host name used for validation purposes. This would be similar to how Android implemented DoT.
A secondary mechanism is public key pinning (SPKI) as described in RFC 7858 (Section 4.2). This should permit multiple potential keys. It will probably not be good for the majority of users. They would either have to regularly update their pinned keys, or use a resolver that uses long-lived certificates, or a resolver that reuses their private keys for new certificates.
Before adding too many new TLS or trust verification-related options, keep in mind that doing so can result in terrible user interfaces that will likely result in an insecure configuration. See for example Network Manager that has to configure wpa_supplicant behind the scenes. It might make sense just to add an optional DNSOverTLSHostname option that will be used in place of IP address for certificate validation.