According to the SOCKS4a spec:

  https://www.openssh.com/txt/socks4.protocol
  https://www.openssh.com/txt/socks4a.protocol

With SOCKS4 cURL *must* do DNS resolution and pass the selected IP to
the SOCKS server.  OTOH, SOCKS4a gives cURL the option to resolve.  If
cURL fails at DNS resolution, it's expected to send the hostname and
0.0.0.x.  So generally cURL should succeed at DNS resolution and thus
have the IP of the target server.  Yet it's not sharing that info with
the user.

SOCKS4a was a bad test case because we can't know whether or not cURL
did the DNS resolution.  A better test case is with SOCKS4 as follows:

curl --ssl --socks4 127.0.0.1:9050 -L --head -w '(effective URL =>
"%{url_effective} @ %{remote_ip}")' "$target_url"

We are assured per the SOCKS4 protocol that cURL *must* do DNS
resolution, so cURL must know the remote IP address.  Yet it still
neglects to correctly set the %{remote_ip} value.  This is certainly a
bug.

Secondary bug--

the manpage states: "remote_ip The remote IP address of the most
recently done connection - can be either IPv4 or IPv6 (Added in 7.29.0)"

The man page is ambiguous. The /rule of least astonishment/ would have
the user naturally expecting "remote IP" to be the target IP whenever
cURL knows it.  Since the behavior is non-intuitive, the man page should
state in detail what the user should expect to receive for the
%{remote_ip} value.

-- 
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

Reply via email to