curl-library
[ curl-Bugs-1099640 ] SOCKS5 user authentication
Date: Mon, 10 Jan 2005 11:06:34 -0800
Bugs item #1099640, was opened at 2005-01-10 19:06
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1099640&group_id=976
Category: libcurl
Group: wrong behaviour
Status: Open
Resolution: None
Priority: 5
Submitted By: Bruce Mitchener (brucem)
Assigned to: Daniel Stenberg (bagder)
Summary: SOCKS5 user authentication
Initial Comment:
I'm experiencing the same problem as described in bug
741841
(http://sourceforge.net/tracker/index.php?func=detail&aid=741841&group_id=976&atid=100976)
The code is currently checking the first byte and
making sure that it has a value of 5.
The previous bug cites section 6 (Replies) of RFC 1928
(http://www.faqs.org/rfcs/rfc1928.html) as saying that
it should contain the value of 5.
However, that is a generic reply, not one specific to
the username/password sub-negotiation which is
described in RFC 1929
(http://www.faqs.org/rfcs/rfc1929.html). This RFC
specifies the value of the VER field for the username
request, but does NOT specify the value for the
response. (Although since the response is still within
the sub-negotiation, it may be reasonable to assume
that it would remain '1'.)
In my SOCKS5 client code elsewhere, I've had to just
ignore the VER field on the username/password
authentication response as I've seen both 1 and 5 in
deployment, and it is important that our code work with
the real world, being liberal in what it accepts.
Now we're using libcurl for an updater application and
running into a problem where our application handles
all of our customers' SOCKS servers fine, but the
updater does not.
I think that libcurl should either handle the ambiguity
and require that the VER field be either 1 or 5, or
simply ignore the VER field altogether.
- Bruce
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1099640&group_id=976
Received on 2005-01-10