Skip to content

Unencrypted query is sent when forward-tls-upstream: yes is used without tls-cert-bundle #676

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
pemensik opened this issue May 12, 2022 · 7 comments
Closed

Unencrypted query is sent when forward-tls-upstream: yes is used without tls-cert-bundle #676

pemensik opened this issue May 12, 2022 · 7 comments

Comments

@pemensik
Copy link
Contributor

Describe the bug
I were playing with unbound and DNS over TLS. I wanted to check it does something, so I have configured unbound to provide TLS service. Then I made configuration for unbound-host to specify remotes.

To reproduce
Steps to reproduce the behavior:

  1. provide TLS service on local unbound.
  2. create local.conf with following contents:
server:
	# tls-cert-bundle: "/etc/unbound/unbound_server.pem"

forward-zone:
	name: "."
	forward-addr: 10.0.1.103@853
	forward-tls-upstream: yes
  1. unbound-host -C local.conf unbound.net
Host unbound.net not found: 2(SERVFAIL).
Host unbound.net not found: 2(SERVFAIL).
Host unbound.net not found: 2(SERVFAIL).
  1. check record pcap.

It seems this sends query just over TCP, but without proper TLS encapsulation. Queried name is visible in wireshark dump.

Expected behavior
It should always encrypt the query. It it is requested to do so but it cannot, it should emit error or at least warning. Nothing is emitted this way.

System:

  • Unbound version: 1.13.1
  • OS: Red Hat Enterprise Linux release 9.1 Beta (Plow)
  • unbound -V output:
Version 1.13.1

Configure line: --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-pythonmodule --with-pyunbound PYTHON=/usr/bin/python3 --enable-dnstap --with-libnghttp2 --with-libevent --with-pthreads --with-ssl --disable-rpath --disable-static --enable-relro-now --enable-pie --enable-subnet --enable-ipsecmod --with-conf-file=/etc/unbound/unbound.conf --with-pidfile=/run/unbound/unbound.pid --enable-sha2 --disable-gost --enable-ecdsa --with-rootkey-file=/var/lib/unbound/root.key --enable-linux-ip-local-port-range --disable-sha1
Linked libs: libevent 2.1.12-stable (it uses epoll), OpenSSL 3.0.1 14 Dec 2021
Linked modules: dns64 python ipsecmod subnetcache respip validator iterator

BSD licensed, see LICENSE in source package for details.
Report bugs to unbound-bugs@nlnetlabs.nl or https://github.com/NLnetLabs/unbound/issues

Additional information
It would be cool if I could build-in default value for tls-cert-bundle pointing to distribution specific trust anchor storage. I guess it would be great default value and would be useful not only for unbound, which has a common config path. But tools like unbound-host have no default path to put that in.

Would PR specifying default value for TLS bundle be acceptable?
@Philip-NLnetLabs
Copy link
Member

I have trouble reproducing this with unbound 1.5.1 (compiled on centos7). Can you give that try?

@pemensik
Copy link
Contributor Author

I am trying this on Fedora 35, compiled with commit 11d077c on master branch. Using this config to check:

server:
	#tls-system-cert: yes

forward-zone:
	name: "."
	#forward-host: "dns.google"
	forward-addr: 8.8.8.8@853
	forward-addr: 8.8.4.4@853
	forward-tls-upstream: yes

Then attempt to resolve over this channel it fails reliably

$ ./unbound-host -C google.conf google.com
[1653486690] libunbound[94606:0] error: read (in tcp r): Connection reset by peer for 8.8.8.8 port 853
[1653486690] libunbound[94606:0] error: read (in tcp r): Connection reset by peer for 8.8.4.4 port 853
[1653486690] libunbound[94606:0] error: read (in tcp r): Connection reset by peer for 8.8.4.4 port 853
[1653486690] libunbound[94606:0] error: read (in tcp r): Connection reset by peer for 8.8.8.8 port 853
[1653486690] libunbound[94606:0] error: read (in tcp r): Connection reset by peer for 8.8.4.4 port 853
[1653486690] libunbound[94606:0] error: read (in tcp r): Connection reset by peer for 8.8.8.8 port 853
[1653486690] libunbound[94606:0] error: read (in tcp r): Connection reset by peer for 8.8.4.4 port 853
[1653486690] libunbound[94606:0] error: read (in tcp r): Connection reset by peer for 8.8.8.8 port 853
[1653486691] libunbound[94606:0] error: read (in tcp r): Connection reset by peer for 8.8.4.4 port 853
[1653486691] libunbound[94606:0] error: read (in tcp r): Connection reset by peer for 8.8.8.8 port 853
Host google.com not found: 2(SERVFAIL).
[1653486691] libunbound[94606:0] error: read (in tcp r): Connection reset by peer for 8.8.8.8 port 853
[1653486691] libunbound[94606:0] error: read (in tcp r): Connection reset by peer for 8.8.4.4 port 853
[1653486691] libunbound[94606:0] error: read (in tcp r): Connection reset by peer for 8.8.8.8 port 853
[1653486691] libunbound[94606:0] error: read (in tcp r): Connection reset by peer for 8.8.4.4 port 853
[1653486691] libunbound[94606:0] error: read (in tcp r): Connection reset by peer for 8.8.4.4 port 853
[1653486691] libunbound[94606:0] error: read (in tcp r): Connection reset by peer for 8.8.8.8 port 853
Host google.com not found: 2(SERVFAIL).
[1653486691] libunbound[94606:0] error: read (in tcp r): Connection reset by peer for 8.8.4.4 port 853
[1653486691] libunbound[94606:0] error: read (in tcp r): Connection reset by peer for 8.8.8.8 port 853
[1653486691] libunbound[94606:0] error: read (in tcp r): Connection reset by peer for 8.8.8.8 port 853
[1653486691] libunbound[94606:0] error: read (in tcp r): Connection reset by peer for 8.8.8.8 port 853
[1653486691] libunbound[94606:0] error: read (in tcp r): Connection reset by peer for 8.8.4.4 port 853
[1653486691] libunbound[94606:0] error: read (in tcp r): Connection reset by peer for 8.8.4.4 port 853
Host google.com not found: 2(SERVFAIL).

As soon as I uncomment system cert statement it starts resolving.

$ ./unbound-host -C google.conf google.com
google.com has address 142.251.37.110
google.com has IPv6 address 2a00:1450:4014:80f::200e
google.com mail is handled by 10 smtp.google.com.

@pemensik
Copy link
Contributor Author

I got also the same results on RHEL8 and RHEL7. The latter I tried Red Hat Enterprise Linux Server release 7.9 (Maipo)

@pemensik
Copy link
Contributor Author

pemensik commented May 25, 2022 •
edited
Loading

Steps required on CentOS Linux 7 (Core):

  • yum-builddep unbound
  • git clone https://github.com/NLnetLabs/unbound.git && cd unbound
  • ./configure && make -j
  • create google.conf with above content, no cert is provided
  • ./unbound-host -C google.conf google.com

@pemensik
Copy link
Contributor Author

The same result happen, when I use:

forward-zone:
        name: "."
        forward-addr: "8.8.8.8#dns.google"
        forward-addr: "8.8.4.4#dns.google"
        forward-tls-upstream: yes

@Philip-NLnetLabs
Copy link
Member

Ah. I tried your config with unbound where it works (for me). It does fail with unbound-host. I'll take a look why unbound-host is different from unbound in this respect.

Philip-NLnetLabs added a commit that referenced this issue Mar 23, 2023
@Philip-NLnetLabs
Fix issue #676: Unencrypted query is sent when forward-tls-upstream: …
b70a3c9 
…yes is

used without tls-cert-bundle

Model the behavior of unbound in unbound-host: always create a SSL context
Philip-NLnetLabs added a commit that referenced this issue Mar 24, 2023
@Philip-NLnetLabs
Fix issue #676: Unencrypted query is sent when forward-tls-upstream: …
7e6a7f3 
…yes is

used without tls-cert-bundle

Model the behavior of unbound in unbound-host: always create a SSL context
Philip-NLnetLabs added a commit that referenced this issue Mar 24, 2023
@Philip-NLnetLabs
Changelog for issue #676
312035f
@Philip-NLnetLabs
Copy link
Member

Fixed in master

@MegaManSec MegaManSec mentioned this issue Aug 25, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@pemensik @Philip-NLnetLabs