Bug: Possible remote DNS resolution for local proxy hostnames
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-07-03 15:16:50+00:00
Resolved: 2021-11-30 05:29:01+00:00

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

Thunderbird version 78.11.0 on 64-bit Linux.

1) Enable manual proxy settings in Preferences, set the proxies to be hostnames, e.g. "localhost" (or your local computer's actual name). No proxy exceptions. Proxy DNS while using SOCKS5 enabled, DNS over HTTPS disabled.
Having an actual proxy running may or may not be necessary (I have local HTTP and SOCKS proxies, though).

2) Enable logging, at least for hostname resolution. I used:
export NSPR_LOG_MODULES=NNTP:5,POP3:5,SMTP:5,all:5,nsHostResolver:5,nsSocketTransport:5,sync
export NSPR_LOG_FILE=~/tmp/TbirdLog.txt
export MOZ_LOG_FILE=$NSPR_LOG_FILE
export MOZ_LOG=$NSPR_LOG_MODULES

3) Restart Thunderbird with logging enabled.
4) Inspect the log file for occurrences of the word "doing". If the word doesn't appear, try with a real running proxy and do a mail check, application version check or other activities that actually go out to the network and should use the proxy you've set.


Actual results:

In the log file I see lines saying e.g.
[(null) 3821: Socket Thread]: D/nsSocketTransport nsSocketTransport 0x7f02fcc31800 origin aus.thunderbird.net doing dns for 127.0.0.1
[(null) 3821: Socket Thread]: D/nsSocketTransport nsSocketTransport 0x7f02fbaf7c00 origin aus5.mozilla.org doing dns for 127.0.0.1
[(null) 3821: Socket Thread]: D/nsSocketTransport nsSocketTransport 0x7f02fc55a400 origin ocsp.digicert.com doing dns for 127.0.0.1
[(null) 3821: Socket Thread]: D/nsSocketTransport nsSocketTransport 0x7f02fbe5dc00 origin services.addons.thunderbird.net doing dns for localhost
[(null) 3821: Socket Thread]: D/nsSocketTransport nsSocketTransport 0x7f02fc2f0400 origin status.geotrust.com doing dns for localhost
[(null) 3821: Socket Thread]: D/nsSocketTransport nsSocketTransport 0x7f02fc2e8000 origin incoming-telemetry.thunderbird.net doing dns for localhost
[(null) 3821: Socket Thread]: D/nsSocketTransport nsSocketTransport 0x7f02fc2eac00 origin incoming-telemetry.thunderbird.net doing dns for localhost

So, it seems that Thunderbird is doing remote DNs calls for proxy hostnames (even if they're IP addresses). At least the logging says so.
Thunderbird DOES eventually get it right (both for "localhost" and for the computer's actual name), the proxy works, there is absolutely no problem with connecting of any kind. Perhaps it's just the logging.
This defect is a bit similar to https://bugzilla.mozilla.org/show_bug.cgi?id=1518208, but the mode in that bug is 3 while in my case it's 0.


Expected results:

If the log lines tell the truth, I wouldn't ever expect that a hostname of a proxy is resolved remotely. If the remote resolvers get hijacked in any way (DNS poisoning, redirecting, hacking into), they may redirect the user to an attacker-selected proxy and potentially enable eavesdropping (or at least spying the list of hosts the user is connecting to).
Not to mention that if the proxy hostname is indeed resolved remotely, it's most of the time a useless network call.
Most proxies are local to the user's network, so I guess they should be resolved by standard means (OS calls). Even if the user is using an external proxy somewhere on the Internet, the worst case would be that the DNS query for the proxy leaks, but not to the actual target servers (mail, news, ...), because they should be served by the proxy itself. If the user thinks/knows the proxy won't handle DNS, he/she can always enable DNS over HTTPS (which also probably shouldn't be used to resolve proxy hostnames, if it is). 
But, perhaps, it's just the logs that are wrong.