© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
9199653
demo site
(Get the code!)
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.
enhancement 1) Introduce a new option (e.g. --no-dns-lookup) so users can explicitly make it clear that cURL is not to perform external lookups. This would serve as a DNS leak fail-safe for users who use --resolve or socks4a. It would most often help prevent users from self-inflicted harm (they use socks4 and neglect to pass in a --resolve, a mistake easily made in the TclCurl API because it's not always obvious which options are sticky when the handle is reused).
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).