apt-get DNS Bypasses apt.conf Proxy Settings

Development
1

[moved post to correct sequence]

2

Finally getting back to testing here. I plan on reading through the Qubes-Whonix testing thread tomorrow, so my comment may have been addressed already.

  1. Downloaded and cloned lastest whonix-gw-14 template manually on Qubes 3.2.
  2. Attached template to existing sys-whonix-13 proxyVM.
  3. Ran apt-get update.
  • Initial traffic is DROPPED by sys-whonix-13. LOG reveals destination IP: sys-whonix-13 & port: 53
  • Eventually times out. apt-get then sends traffic to tinyproxy on 10.*.255.254:8082 and completes successfully

Not sure why apt-get is requesting a standard DNS lookup when apt.conf.d/01qubes-proxy is configured to use tinyproxy.

(same is true for apt, per OP, as well as apt-get)

Forgot to mention: Port 53 dropped because Workstation Transparent DNS disabled on my Gateway. Do you have that set also @kuruu?

1 Like
3

Btw mixing 13 and 14 will be unsupported.

entr0py:> Finally getting back to testing here. I plan on reading
through the Qubes-Whonix testing
thread
tomorrow, so my comment may have been addressed already.>

  1. Downloaded and cloned lastest whonix-gw-14 template manually on Qubes 3.2.
  2. Attached template to existing sys-whonix-13 proxyVM.
  3. Ran apt-get update.
  • Initial traffic is DROPPED by sys-whonix-13. LOG reveals destination IP: sys-whonix-13 & port: 53
  • Eventually times out. apt-get then sends traffic to tinyproxy on 10.*.255.254:8082 and completes successfully

Not sure why apt-get is requesting a standard DNS lookup when apt.conf.d/01qubes-proxy is configured to use tinyproxy.

Do you have the dom0 settings?

4

I suspect this is not a Qubes or Whonix issue. It appears to be an apt-get DNS leak (by design?).

apt-get performs DNS lookup [using system resolver] for every repository entry (including http, onion, and even numeric IPs) [regardless of whether or not a proxy is configured for that particular host].

This may be expected behavior because Acquire::http::Proxy can be configured per host. Also, http may be proxied while other apt-transports are not. In these cases, it would be desirable to have local DNS resolution. It seems the only way to block DNS requests for our use case would be to establish complex rules.

This was not an issue in the past because uwt tunneled all apt-get traffic over SocksPort. Even now, users with Transparent DNS enabled will not notice - but seems rather sloppy behavior for core Whonix components to be polluting Transparent Ports.

1 Like
5

tinyproxy recently (Feb 2018) added SOCKS support (add SOCKS upstream proxy support (socks4/socks5) by rofl0r · Pull Request #64 · tinyproxy/tinyproxy · GitHub). Wonder if it’s possible to keep apt-get’s old uwt wrapper and just direct it to qubes-update-proxy?

(github question: how can I tell which version of tinyproxy contains that merge? it went into master but I don’t see any associated label, tag, release.) edit: nvm, there hasn’t been a release since Jan 2016.

1 Like
6

I am failing to understand this still but this may be important.

entr0py:

I suspect this is not a Qubes or Whonix issue. It appears to be an apt-get DNS leak (by design?).

apt-get performs DNS lookup for every repository entry (including http, onion, and even numeric IPs).

Of course apt-get performs DNS lookup. apt-get knows nothing about Tor,
Whonix, etc. We just need to make sure the DNS lookup is done by
Whonix-Gateway through Tor. apt-get does DNS lookup like any application.

This may be expected behavior because Acquire::http::Proxy can be configured per host. Also, http may be proxied while other apt-transports are not. In these cases, it would be desirable to have local DNS resolution.

It seems the only way to block DNS requests for our use case would be to establish complex rules.

There is no DNS connectivity in Qubes-Whonix templates by default. So
all DNS requests are filtered anyhow. More so in Qubes R4 since
Qubes-Whonix TemplateVM’s NetVM is set to none.

Do you mean there is a non-Whonix / non-Qubes specific apt-get bug that
it ignores proxy settings and makes system default DNS (“clearnet”)
requests?

7

rewrite:

This. apt-get leaks and whonix cleans up the mess as expected. Still trying to decide whether it’s a bug or expected behavior in apt-get. We would prefer this logic:

  1. check if proxy is configured for host
  2. use proxy to resolve dns

apt-get:

  1. resolve dns first
  2. check if proxy is configured

apt-get’s implementation may be correct since dns resolution may be required to check blocked hosts, configured proxies, etc.

So that solves the issue for templates. Running apt-get in appVMs will leak DNS queries through WORKSTATION_TRANSPARENT_DNS. Not ideal but not a big issue.

Reinforces what we’ve known all along: Never trust application proxy settings! I’ve been testing vscode with stream isolation using its command line proxy settings. Has behaved well for a long time. Fetches extensions through the proxy but then, when extension needs downloads - it ignores proxy settings. Every program should use uwt.

1 Like
8

entr0py:

rewrite:

I see.

This. apt-get leaks and whonix cleans up the mess as expected.

Phew. At least no Whonix leak bug found.

Still trying to decide whether it’s a bug or expected behavior in apt-get. We would prefer this logic:

  1. check if proxy is configured for host
  2. use proxy to resolve dns

apt-get:

  1. resolve dns first
  2. check if proxy is configured

Very much agreed!

apt-get’s implementation may be correct since dns resolution may be required to check blocked hosts, configured proxies, etc.

I guess that would be a big surprise, violating principle of least
surprise. Should at very least be clearly documented. I guess if so,
would be considered an apt-get bug.

So that solves the issue for templates. Running apt-get in appVMs will leak DNS queries through WORKSTATION_TRANSPARENT_DNS.

Shouldn’t. [*] Does it?

  • In Whonix TemplateBasedVMs, uwt is being used.

  • Only Whonix TemplateVMs use proxy settings (so Qubes UpdatesProxy
    mechanism gets used), but also in Whonix TemplateVMs NetVM is set to
    none by default.

Not ideal but not a big issue.

If so: Really wouldn’t be ideal.

Reinforces what we’ve known all along: Never trust application proxy settings!

Agreed.

I’ve been testing vscode with stream isolation using its command line proxy settings.

Nice!

Every program should use uwt.

[*] Since uwt is based on torsocks, it’s not bulletproof either. Not
even close.

9

@Patrick I will follow up with debian/apt (re: bug vs expected). There is nothing to do for Whonix / Qubes. (Haven’t tested yet, but if TemplateBasedVMs are using uwt, I don’t anticipate any issues - haven’t had any to date in W13).

Actually… this is a non-issue for Qubes 4 but it still affects Qubes 3.2 & non-Qubes-Whonix(?). (Only noticeable for users with WORKSTATION_TRANSPARENT_DNS=0.)

Will update after hearing from upstream.

2 Likes