-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi,
first: Maybe I should migrate this discussion to the bug tracker? But I'm
always somewhat hesitant to open new bugs, because I always assume, I'm
just too stupid to properly configure everything :-)
On Fri, 22 Jan 2021, Werner Koch wrote:
On Fri, 22 Jan 2021 13:24, Erich Eckner said:
Box 1: tor (but no DNS endpoint exposed), named listening on 127.0.0.1:53
(used by /etc/resolv.conf)
In Tor mode we use 8.8.8.8 as DNS Server unless you use
--nameserver ipaddr
In ``Tor mode'' Dirmngr uses a public resolver via Tor to resolve
DNS names. If the default public resolver, which is 8.8.8.8,
shall not be used a different one can be given us‐ ing this option.
Note that a numerical IP address must be given (IPv6 or IPv4) and
that no error checking is done for ipaddr.
this is all implemented using a full DNS resolver library inside dirmngr
(which you can also truns into a --recursive-resolver). If you don't
want this, or DNS over Tor and if you are not on Windows you may use
--standard-resolver.
standard-resolver works (in DNS) on box 1, all other options (even
"nameserver 127.0.0.1") give:
4 - 17:25:37 dirmngr[3382567.6]: DBG: dns:
resolve_dns_name(openpgpkey.eckner.net): Permission denied
4 - 17:25:37 dirmngr[3382567.6]: DBG: dns:
getsrv(_openpgpkey._tcp.eckner.net): Permission denied
However, with "standard-resolver" dns works, but the actual fetch fails:
4 - 17:28:28 dirmngr[3383211.6]: DBG: dns:
resolve_dns_name(openpgpkey.eckner.net): Success
4 - 17:28:28 dirmngr[3383211.6]: can't connect to 'openpgpkey.eckner.net':
Permission denied
4 - 17:28:28 dirmngr[3383211.6]: error connecting to
'https://openpgpkey.eckner.net/.well-known/openpgpkey/eckner.net/hu/81t9qcnyscdr3uatodn7eejogt6tpa8q?l=erich':
Permission denied
4 - 17:28:28 dirmngr[3383211.6]: command 'WKD_GET' failed: Permission denied
This means, the connection through tor fails, right? This is strange,
because a plain
curl -x socks5h://127.0.0.1:9050
'https://openpgpkey.eckner.net/.well-known/openpgpkey/eckner.net/hu/81t9qcnyscdr3uatodn7eejogt6tpa8q?l=erich'
and also with -4 or -6 works just fine. Looking at tor's log, I see:
Tor[2692608]: Your application (using socks5 to port 443) is giving Tor
only an IP address. Applications that do DNS resolves themselves may leak
information. Consider using Socks4A (e.g. via privoxy or socat) instead.
For more information, please see
https://wiki.torproject.org/TheOnionRouter/TorFAQ#SOCKSAndDNS. Rejecting.
[1 similar message(s) suppressed in last 5 seconds]
This is probably due to "SafeSocks 1" in my torrc. So gnupg resolves the
ip and tries to connect to that directly through tor, but tor refuses to
do that.
It would be really nice, if the name resolution could be handed over to
the socks layer, but at least, I now understand, why it fails (and that I
probably have no other choice as to disable SafeSocks in tor or not-use
tor for gpg).
Box 2: named listening on 127.0.0.1:53 (used by /etc/resolv.conf), dnsdist
listening on $all_public_ips:53 (used by external clients, relaying to
named and iodine as needed), iodine listening on 127.0.0.1:5353
Does gnupg interpret any of these as tor dns endpoints? How does gnupg
determine, how to query dns?
In non-Tor mode /etc/resolv.conf etc is parsed. --debug dns should show
errors or fallbacks for unknown statements.
I was more wondering, why gpg decides to go into "tor mode" on box #2,
when there is actually no tor installed or running. I'm totally happy to
force non-tor mode via config file, but I'm also open to help find the
root for gpg's misjudgement of tor-availability.
The additional "debug dns" line didn't change anything noticeably for me,
I already have "debug ipc,network,dns", so probably it's redundant?
I see. I would need to check how to enable all DNS debugging. You have
"verbose" also in your dirmngr.conf?
yes, my current content is:
log-file socket:///home/erich/.gnupg/dirmngr.log
verbose
debug ipc,network,dns
Note, that I *do* see some dns lines (the ones which I posted earlier).
I'd prefer to use tor for retrieving keys (if possible). Is there a
possibility to turn off dns resolution via tor, but still do all the rest
through tor?
I don't think so. It is quite some time since I last worked on the Tor
features. (dirmngr/dns-stuff.c, dirmngr/dns.c are the main files)
Well, from what you wrote before, I understood, that using --nameserver
alongside --use-tor, it would query dns directly and do everything else
through tor. Maybe, I got something wrong. But this doesn't matter,
because I was thinking in the complete wrong direction: If I cannot solve
the dns resolution problem through tor, I also cannot use tor (with my
current tor config) for direct key retrieval.
disable-ipv4 / disable-ipv6 does not make any difference (without also
adding "no-use-tor", of course)
Sometimes it makes a difference in particular on my Windows VM.
I agree: Switching between ip versions is always worth a trial
(especially, since my ipv6 @home is actually a 6in4 routed through ukraine
- - and thus also probably russia and the KGB ;-p)
version:1.8.7:10807:1.39-unknown:12700:
Build against an older libgpg-error (aka gpgrt) version but that does
not matter.
* GpgRT 1.41-unknown (0000000)
That is the actual version used.
I don't see any libdns there. Box #1 only differs in the cpu flags line:
No library but the (modified) implementation by William Ahern.
CPU flags are not relevant here; they are runtime tested.
Shalom-Salam,
Werner
--
* Free Assange and protect free journalism!
* Germany: Sign the Treaty on the Prohibition of Nuclear Weapons!
regards,
Erich
P.S.: I liked the old signature better. (Nothing against political
statements, but it was more witty)
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmALBfMACgkQCu7JB1Xa
e1ok2w/9FsoldOMnbIoyR8vvwe0YknX2js//R/UDGuWM3POg67ua/hAtSBniXEPv
Lm16zhkICUOsw2Ij8IvpMfOPE5TFfgKfP89V+6Obd9SesaoezhNKXKcO58kWdHal
lt3xFlitTxC7AQT+IHeDr4hvtju5Mv/075bpDeF2LvWRyt9HJ/u+zvqFUnudsunE
PKzy03bn4jgtGUWxIkWOgTkBC2SvveOyDemLJRTMUq4gLMX6P+nLV0H8sjc9+uKs
/VjWDiybvZzSgIg6yZ7MHwEgdAq38rbL3rdWOWTdIMVf6KfitV0WMHsp4X2mcbFb
jUdAAseak5cSNgK/3P3g/pFROYval1nmaIpQNYByYgfk/Cfb57TLWHLcB28PTpWa
8lUVw9KB2xk41jBnjHIfQf56hiKmwTS5x17EK3meOWgoDZdutadFpUJuyyHX6VIc
ZR5HKNeOLTrKKNhglttvtQNCnQHMRRPPOUqDWwvfLGqxgAh/yVcZHta8rj7/cHY/
pUZ4Vmk6BzOrq9LjLZA8oahdMuHRiAGVv0EFt4U77KjvrIVqITQXsEFItua4v9O0
Ya8BnGswY+HgXZLHuntqnsS/PBnqRApaJJ4h4RGqP5UTQFoeY2G0wZ34NLul65AN
DPiWQc0CEGlOmtnZ6a2Vn2NNMRBfsCG1qeP1SdU5qq4l4kabO/Y=
=manV
-----END PGP SIGNATURE-----
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
