Closed Bug 78176 Opened 23 years ago Closed 21 years ago

PAC: SOCKS return value is not version specific

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: benc, Assigned: darin.moz)

References

(
URL
)

Details

(Keywords: arch, helpwanted, relnote) 

The orginial PAC description says the following about returning a directive for 
using a SOCKS server:

http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html

"SOCKS host:port 
     The specified SOCKS server should be used. "

This was a feature available in Netscape Navigator, which supported only SOCKS 
V4.

The problem with this is that mozilla does not support SOCKS V4, and SOCKS V5 
support in the client will not be fully interoperable:

What should happen within a browser that supports only SOCKS V5? Should this 
fucntion be updated to explicitly return a SOCKS5 value, or is the modern 
interpretation assuming that the server supports both versions?

At the worst, this may simply be unspecified, and a standards debate can now 
ensue...

At the very least, this needs to be release noted.
Target Milestone: --- → mozilla1.0
qa to me.

I'm exchanging mail with a previous implementor of PAC in Communicator.
Hopefully they will be able to provide some sage advice.
QA Contact: tever → benc
-->PAC bugs to Jussi
Assignee: neeti → jpm
Keywords: arch
QA Contact: benc → pacqa
Serge, can you take a look at these PAC issues? Thanks - Jussi-Pekka
Assignee: jpm → serge
BenC: Any *sage* advice coming yet?
See my comments in bug 78119. This problem may resolve itself based on what
happens there.
benc: I don't see how bug 78119 changes anything on the PAC front.
PAC still needs a way to find out if a SOCKS proxy is v4 or v5 as the proxy will
not be listed in the pref.
If we support only one version of SOCKS (which we do now), FindProxyforURL =>
SOCKS means it must be a SOCKS V5 connection attempt.

We need to add a mechnamism like version checking before we can extend the
FindProxyforURL functions and result directives (like addinga SOCKS5 result).

In other words, there is no practical solution right now.

Once SOCKS V4 support is added, then we need to figure out what version SOCKS
connection to make. The current thinking is to implement a SOCKS version
selector (all connections to SOCKS servers will be EITHER V4 or V5), so again,
PAC will not be making a version decision, it will simply use whatever was set
manually.

in light of bug 89928, a SOCKS version selector might not be foward compatible
though.
Well SOCKS isn't forward compatibile with itself either. :)

The point of that RFE was to break away from most of the proxy cruft we have
built up. I should have added in that bug we need extensible connection types,
like a way of adding SOCKS V6 support (yes, NEC has given thought to SOCKS
futures...) and SSL encrypted proxy connections of all types (SOCKS in SSL, HTTP
proxy in SSL, etc).
Suggestion: change to use the keywords "SOCKS4" and "SOCKS5". Deprecate "SOCKS",
but default it to mean the same as SOCKS4 so PAC files from 4.x will work
correctly. (4.x only works with SOCKS 4, so any PAC file coming from a 4.x
environment will be pointing to a SOCKS 4 server.)
As a side note, nsProxyAutoConfig.js doesn't even appear to deal with plain
SOCKS return values at the moment.

I'm working on this.
argh, missed RELNOTE train:

what do we do here? go direct or go deaf?

RELNOTE:
"PAC files do not support SOCKS.

PAC files that return "SOCKS" directives will be ignored in this version".
Keywords: relnote
We go direct, I believe. This will be easier after bug 89500 is checked in, I
think, although its not dependant on it.

We need to decide what to use for socks 5. SOCKS5 host:port sounds good to me....
Forget everything else I ever proposed above, I like bbaetz, comments.

Hook up SOCKS => SOCKS v4 (it never worked before, so who cares about that?)
In the future, extend PAC support of SOCKS directives w/ SOCKS5 (or add
versioning to PAC and then do *anything* that would be consistent).

I'm marking this as "RESOLVED/LATER".
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → LATER
I disagree that this should be RESOLVED. I think it is important to enterprise
customers.  I believe serge is working on it. I think we need to at least add a
"SOCKS5" keyword, and I think adding "SOCKS4" is also important for usability.
"SOCKS" should default to SOCKS4 for the reason I mentioned above.
Keywords: nsenterprise
reopening. LATER is obsolete, and its really a trivial fix. The only reason that
it wasn't supported before was that we didn't have a socks4 proxy. Now we do.
Status: RESOLVED → REOPENED
Resolution: LATER → ---
Is this the bug # for SOCKS4 support in PAC?
No, that would be bug 65583.
Oh, sorry. Yes, this bug covers that.
Steve, there is no point in adding more words unless you update a PAC standard
so that it still works with existing PAC files.

If nobody is using SOCKS in their PAC files (I don't think there is an actual
report of this), then I suppose we can hack away.

If people are using this, they have PAC files that have resultant SOCKS
directives. It isn't clear to me how you could add new SOCKS directives without
possibly confusing older clients.
Good point: changing SOCKS to SOCKS4 would break existing 4.x installations. I'm
not sure what adding a SOCKS5 keyword would do to them.

Is PAC a standard, or a Netscape thing? Do we need to worry about other kinds of
clients?
IE uses it as well (and so does ns4) We could easily add socks4 as a synonym for
socks, though. socsk5 compatability isn't an issue because no other pac client
supports it, AFAIK
Most customers (like the Sun comments in 53080) want one PAC file for their
whole network, and presumably all clients.

I suggest we do not extend the contents of PAC for now, especially since we
still have not implemented everything up to 4xp.

I spoke with Brendan about various PAC arch issues, and without putting words
into his mouth, he thought that we should live with the existing structure and
then define a whole new "PAC v2" rather than do our version of the "embrace and
extend".

If someone in eClient marketing wants to see if I'm wrong, it would be a good idea.
Blocks: 79893
Well, we need something. Plugins have a routine which they can call to find out
the proxy settings for a given url, and they return it in the same format PAC
does. If the user has a socks5 proxy, what should that function return?

I really think that defining PACv2 is overkill. SOCKS5 won't do anything on
browsers < ns6.0, so its not like a company with socks5 only proxies can use
other browsers anyway.
I think we should let this lie for this release.

Nobody is saying "we need SOCKS v4 and SOCKS v5 in the same PAC", or "we need
SOCKS V5 in PAC."

We can do the design work for the next milestone. 
But we have to tell plugins something. And if we don't tell them the correct
answer, then the quesiton is which lie to use.

If we do use the correct answer, then whatever string we pick has to be what PAC
will use.
If our goals are to a) get SOCKS version information somehow and b) not break
other browsers PAC code, regardless of their ability to connect to a SOCKS5
proxy, then there's another alternative.

We let PAC writers create another function that looks like this:

function GetSOCKSVersion(proxy) {  
   return "SOCKS5";  // or "SOCKS4", or even just a numerical version...
}
Then when we see "SOCKS" in the PAC return string, just call into the other
function to select version.  If GetSOCKSVersion is undefined, assume SOCKS4.  If
we pass them the name/address of the proxy (as returned by FindProxyForURL),
they can support multiple SOCKS versions on different proxies from the same PAC.

This will be transparent to browsers that don't explicitly support it, and still
let us get the info we need.  It feels like an enormous hack, though.
Blocks: 98821
So, can we come to a conclusion? brendan - benc said that you had thoughts on 
this. See my 2001-08-22 10:49 comment.
How about adding a socks version option in a dialogue so user can select which
socks version they have? Programs like ICQ and napster uses that (they don't use
the PAC, of course). The default value can be socks 4. This is a hack but will
let clients behind a socks 4 firewall connect, at the very least. You don't want
to change the PAC much, as sites generally allow users to choose either IE or
netscape.
marking nsenterprise-; will be reevaluated for nsenterprise in future release.
Keywords: nsenterprise-
any decision on this? I'll add it to the patch in bug 105335 if SOCKS5/SOCKS4 is
decided. Or is this really PAC v2?
Support for a PAC file that can do both versions is probably a PAC2 item, so for
now, I don't care how we solve this (SOCKS V4 only, now that that works... -OR-
support the selector switch), just as long as we document it.
No longer blocks: 98821
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
*** Bug 130799 has been marked as a duplicate of this bug. ***
So, um:

Can we make a decision on this before 1.0?

I still say that adding a type of "SOCKS5" would do. Its not like thats going to
conflict with anything, and whilst that directive wouldn't work in ns4, socks v5
doesn't work in ns4 anyway, so no valid configuration would be broken.
You are proposing:

SOCKS directive => SOCKS 4
SOCKS5 directive (new type) => SOCKS 5

If so that makes sense, all old PAC will work, new PACs that use SOCKS5 could be
created too.
Correct
to default owner
Assignee: serge → new-network-bugs
Status: REOPENED → NEW
okay. the proposal makes sense to me.

+helpwanted (now that we know the desired behavior).
Keywords: helpwanted
qa to me.

Can I change the relnote to so say that "SOCKS == SOCKS V4"?
QA Contact: pacqa → benc
pac has new ownership...
QA Contact: benc → pacqa
neeti originally targeted this, so I think ownership should revert to her, not
new-network-bugs... 

please retarget and or manually set ownership.
Assignee: new-network-bugs → neeti
Another option for SOCKS besides version is whether to resolve the destination
host on the client or to let the proxy server do it. The actual implementation
of this is covered by bug 134105. This is possible with SOCKS 5 and with an
extension to SOCKS 4 (ie 4a).

Initially, I'll just make this setting app-wide, but it seems plausible that
someone might have a complex network setup where they will want more control. I
just thought I'd leave this note so that any changes to the PAC format being
considered can take this into account, as well.

btw, my plan for handling this internally was to have an "extra" field of flags,
which would have proxy type specific meanings. Perhaps the PAC file could simply
do the same. For example:

if (...) return "SOCKS foo.com:1080 0"; // resolve names on client
if (...) return "SOCKS bar.com:1080 1"; // resolve names on server
return "DIRECT";

As long as the port was specified, it would not break our current implementation. 
removed jhooker from cc: list
I really don't think we should make a change unless we know that file format
would work transparently in all environments. 

It is better, in my mind, to cram these desires into well-thought out ideas for
a future PAC format.

We should stay focused on the question raised in this bug, which I think we have
answered.
moving neeti's futured bugs for triaging.
Assignee: neeti → new-network-bugs
future
Target Milestone: mozilla1.0.1 → Future
Can I pretty-please have a way to do SOCKS5?

SOCKS4 has never been relevant to me, and I need firewall support.


SOCKS5 works, but not via autoproxy - you have to use manual cofig instead.
Theres a adio button in the prefs pane for that
Yes; I need it from autoproxy (which is what this bug is, yes?)  Since the
guts are there for manual proxy, it seems like it should not be hard, and the
prior bug discussion of using "SOCKS5" instead of "SOCKS" as the pac return type
makes perfect sense to me...

I think the SOCKS directive will do what you want already: select SOCKS 5. SOCKS
4 was implemented in mozilla after SOCKS 5 and autoproxy, and I don't think any
of the autoproxy behavior was ever changed to support it.
If my PAC file returns "SOCKS", the only legal socks-oid value, the connection
attempted is SOCKSv4, not v5.  The code examination I did bore that out, as did
this bug, I thought.

If someone knows how to make PAC files request SOCKSv5, I'd like to know how.

Steve: I think that SOCKS 4 was hooked into the SOCKS directive at some point
for 4xp reasons.


I'm needing this feature and i have some spare time to begin to implement it.
What is decided about the new SOCKS5 keyword? I propose the following extension
to the SOCKS keyword:

SOCKS host:port [v4|v5]

this way if the version is not supplied the default Mozilla version is used, in
order to get backward compatibility and we can extent it easier for "future?"
socks versions (v6?). Maybe pac files writed using this extension will break
another browsers, but if you are using a SOCKS5 server, the other browsers will
not work anyway.

Another posible extension to the PAC spec, is to define a function to retrieve
browser capabilities, like a function called getProxyTypeCapabilities, this way
scripts can check is this function is defined, if true test if SOCKS5 is supported
I'd prefer to keep the directive format to "TYPE host|IP:port".

Although Darin added "SOCKS4" and "SOCKS5" to the IDL, I don't think anyone has
found out what they do.

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/base/public/nsIProxyAutoConfig.idl

66                  * proxy-type  = "PROXY" | "SOCKS" | "SOCKS4" | "SOCKS5"

This bug actually should be verified as having a certain behavior, and then a
new bug should be opened on what you are proposing. 
http://lxr.mozilla.org/mozilla/source/netwerk/base/src/nsProtocolProxyService.cpp#417

If I'm reading this right...

SOCKS will use SOCKS4, which is a good, conservative reading of the PAC spec.
Assignee: new-network-bugs → darin
Keywords: verifyme
QA Contact: pacqa → benc
RESOLVED/fixed.

Darin, can you verify my interpretation of the code?
Status: NEW → RESOLVED
Closed: 23 years ago → 21 years ago
Resolution: --- → FIXED
Yes, SOCKS uses SOCKS4.  I thought this bug also encompassed the need to be able
to somehow specify SOCKS5.

To date I have not been able to use SOCKS proxying because SOCKSv5 has always
been the only proxy I have available where I need proxying.  Surely a whole lot
of people have moved from v4 to v5?...and surely configurability is better?...
mass remove verifyme requests greater than 4 months old
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.