The socks.c code shows that cURL does not even attempt DNS resolution on
SOCKS4a. Strictly speaking, the SOCKS4a spec expects apps to /attempt/
DNS resolution before contacting the socks server. I won't complain on
this point though because the status quo is favorable to Tor users (as
it protects them from DNS leaks).
The fallout is that the SOCKS server does not give feedback to the app
on the IP it settles on in the socks4a scenario. This means cURL has no
possible way of knowing which IP to express in the %{remote_ip} output.
After seeing the code I'm calling out these bugs:
bug 1) SOCKS4a: Considering that Curl_resolve() is unconditionally
bypassed, when a user supplies both --resolve and also demands socks4a
cURL will neglect to honor the --resolve option even though the two
options are theoretically compatible. This is a minor bug because
socks4 can be used instead as a workaround. But certainly the man page
should at a minimum disclose the artificial incompatibility between
socks4a and --resolve.
bug 2) SOCKS4a docs: cURL has some discretion whether to attempt DNS
resolution or not. Yet the docs do not clarify. Users should get
reassurance in the man page that using socks4a unconditionally refrains
from internal DNS resolution.
bug 3) SOCKS4: Since cURL *must* do DNS resolution, cURL must also know
what the target IP is. Thus cURL should properly return the
%{remote_ip} value.
bug 4) The docs for %{remote_ip} should tell users what to expect for
that value. The man page is vague enough to be useless.
Workaround: if proxy users need to know which IP cURL connected to, they
must do their own DNS resolution manually outside of cURL (e.g. using
dig), supply the IP & hostname via --resolve, and use SOCKS4 or SOCKS5
(not SOCKS4a).
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to curl in Ubuntu.
https://bugs.launchpad.net/bugs/1931815
Title:
the %{remote_ip} output format is broken on proxied connections
Status in curl package in Ubuntu:
New
Bug description:
This is how a Tor user would use cURL to grab a header, and also
expect to be told which IP address was contacted:
curl --ssl --socks4a 127.0.0.1:9050 -L --head -w '(effective URL =>
"%{url_effective} @ %{remote_ip}")' "$target_url"
It's broken because the "remote_ip" is actually just printed as the
127.0.0.1 (likely that of the proxy server not the remote target
host).
tested on curl ver 7.52.1
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1931815/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
