systemd 239 through 243 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. Reference: https://github.com/systemd/systemd/issues/9397
Created systemd tracking bugs for this issue: Affects: fedora-all [bug 1771726]
Since version 239, systemd supports DNSOverTLS, however from v239 to v242 only `opportunistic` mode is implemented and the man page resolved.conf explicitly explain the limitation of the implementation, by saying `Note as the resolver is not capable of authenticating the server, it is vulnerable for "man-in-the-middle" attacks.` [1]. Moreover, according to RFC 7858, section 4.1 [2], the opportunistic privacy profile could be implemented in such a way to let the client validate the server or not. The latter option is used by systemd. [1] https://www.freedesktop.org/software/systemd/man/resolved.conf.html#DNSOverTLS= [2] https://tools.ietf.org/html/rfc7858#section-4.1
In systemd v243 the "strict" profile has been implemented, where no DNS queries can be done in clear text by the resolver. In this version, the server certificate is incorrectly checked, because any certificate signed by a trusted certificate authority is accepted by systemd-resolved.
Upstream patch: https://github.com/systemd/systemd/commit/b7a4129ca946ed49e161a03283faf5bbab96d110
A remote attacker may use this flaw to eavesdrop or modify DNS queries performed by systemd-resolved to a DNS server over TLS. DNS Over TLS should ensure that the DNS replies are confidential and they are coming from the expected server. However, in systemd v243 function dnstls_stream_connect_tls() in src/resolve/resolved-dnstls-gnutls.c does not correctly validate the server certificate and it accepts any certificate signed by a trusted Certificate Authority, even if not valid for the resolver hostname or IP address. The attacker could exploit this by performing a man-in-the-middle attack.
The version of systemd as shipped in RHEL 8 is compiled with gnutls support and it supports DNSOverTLS option in the resolved.conf file. However, the only accepted values are `no` and `opportunistic`, so it can only provide privacy at best, as the opportunistic mode could fall back to clear text DNS queries/replies in case of issues with the secure communication. Moreover, as explained in comment 2, in opportunistic mode the client is not required to validate the resolver, which is not done at all and is documented as well.
Statement: Versions of systemd as shipped with Red Hat Enterprise Linux 7 are not affected by this issue as they did not include support for DNSOverTLS option. Versions of systemd as shipped with Red Hat Enterprise Linux 8 are not affected by this issue as they did not support the `yes` value of the DNSOverTLS option. OpenShift Container Platform 4.1 ships a version of systemd from Red Hat Enterprise Linux 8 and is thus also not affected by this issue.
(In reply to Riccardo Schirone from comment #2) > Since version 239, systemd supports DNSOverTLS, however from v239 to v242 > only `opportunistic` mode is implemented and the man page resolved.conf > explicitly explain the limitation of the implementation, by saying `Note as > the resolver is not capable of authenticating the server, it is vulnerable > for "man-in-the-middle" attacks.` [1]. Moreover, according to RFC 7858, > section 4.1 [2], the opportunistic privacy profile could be implemented in > such a way to let the client validate the server or not. The latter option > is used by systemd. (In reply to Riccardo Schirone from comment #3) > In systemd v243 the "strict" profile has been implemented, where no DNS > queries can be done in clear text by the resolver. In this version, the > server certificate is incorrectly checked, because any certificate signed by > a trusted certificate authority is accepted by systemd-resolved. That description is accurate.