NSS's libSSL contains the vestiges of an old SOCKS client implementation, one that was intertwined with the implementation of the SSL protocol. That SOCKS client is no longer supported, and will be excised from libSSL. But the demand for a SOCKS client continues. Now that NSPR has a layered I/O architecture that permits multiple protocol layers to be "pushed" onto a socket, it is appropriate for a new SOCKS layer to be created that can be pushed onto an NSPR socket independently of the SSL layer. Lord has suggested that this SOCKS client might belong to NSPR, rather than to NSS per se', although now that the two groups have merged, this is probably a moot point. Also, the old SOCKS client supported an older, obsolete, SOCKS configuration file format. Any new SOCKS implementation should support the new SOCKS configuration file format and functionality. Specificaly, the new format allows multiple socks proxies to exist and allows one to be selected based on the IP address of the server ultimately being contacted. This represents a change to the semantics of the SOCKS client. With the old format, the IP address and identity of the SOCKS proxy was not part of the SOCKS configuration file, and the application had to explicitly connect to the proxy it wanted. With the new configuration, the application should no longer explicitly connect to the socks proxy.

Mozilla's new networking library (Necko) already has a SOCKS client, contributed by Justin Bradford. (http://lxr.mozilla.org/seamonkey/source/netwerk/socket/base/) The SOCKS client is implemented as an NSPR I/O layer. Does that resolve this bug, or should the SOCKS SOCKS client be moved into NSS?

Interesting. Questions: 1. Can it be built apart from the rest of necko? 2. Can it be used apart from the rest of necko? 3. What values does it return for the getpeername method? The IP addr of the socks proxy? or the remote server? or ? The objective is to have SSL work over socks. For that to work, the SOCKS layer has to make the socks proxy be completely transparent to SSL, which means that getpeername has to return info about the final destination server, not the proxy.

More on this subject. For SSL to work over SOCKS, the SOCKS code must be in PSM (perhaps in addition to N6). So, it is necessary that PSM be able to build, link, and use the SOCKS code, without building all of N6.

Wan-Teh, You asked if Bradford's SOCKS client satisfies this bug. I think the question is: does it meet the requirements for SOCKS for mozilla and PSM? I think those requirements are: a) offers the full functionality of SOCKS that was offered in Communicator 4, with SSL and without SSL, with http proxies and without http proxies, configurable by either a socks.cnf file or proxy autoconfig. and b) speaks both version 4 and version 5 of the socks protocol, and c) supports multiple SOCKS proxies simultaneously through the use of the extended sockd configuration file format. I'm not sure if this is an NSS requirement or a PSM requirement. If there is a demand to be able to use NSS for SSL with SOCKS in client programs other than the browser, then I think this is an NSS requirement. If the only demand is for the browser, then I think this might be merely a PSM requirement. Now, I will describe the SOCKS client functionality in Navigator 3 and Communicator 4. The Comm 4 SOCKS client speaks SOCKS protocol version 4. The browser can only be configured to use a single SOCKS proxy. The domain name or IP address and port number of the SOCKS proxy is configured in the browser's proxy preferences panel. When the browser is configured to use a SOCKS proxy, it attempts to read a SOCKS configuration file. In Nav 3, the file was c:\windows\socks.cnf on windows. In Communicator 4, the pathname of the file was controlled by a preference in prefs.js, for which there was no GUI. The default value was socks.cnf in the user's profile directory. The user could override it with a preference line like one of the following: user_pref("browser.socksfile_location", "C:\\windows\\socks.cnf"); or user_pref("browser.socksfile_location", "/usr/netscape/socks.cnf"); If the SOCKS configuration file is present, it is read and from it a table is built that is used to determine whether or not to use the socks proxy for any particular target server, based on the IP address and TCP port number of the target server. For a long time, the server help.netscape.com contained a document that explained all about that configuration file, but it no longer does. I have attached a copy of that document's text to this bug report. If a proxy autoconfig javascript file is used, it controls whether or not the socks client is used, and which socks proxy is used with the socks client, but the socks config file, if present, can still override this and force a direct connection to the server (not via the socks proxy). If a socks proxy is configured, and neither a proxy autoconfig file nor a socks configuration file is present, then the socks proxy is used for all connections. A very very large and influential customer of Netscape's was unhappy about the fact that Communicator's socks client could only be configured to use a single SOCKS proxy. They wanted the socks client to use the more powerful (and new) sockd configuration file syntax, which selects the socks proxy (IP address and port) based on the IP address and port of the target server. That formerly internal Request for Enhancement was the basis of this bug report. There was also an internal RFE asking that "proxy autoconfig" be able to work with both SOCKS and ordinary http proxies simultaneously. In my next addition to this RFE, I will discuss what I found when I read Bradford's SOCKS client source.

Now, having read the source to the new SOCKS client implementation in the directory named above, and in http://lxr.mozilla.org/seamonkey/source/netwerk/base/src/nsProtocolProxyService. cpp#246 I have the following observations: 1. The code is written in C++ using the mozilla browser's XPCOM mechanisms. I don't know if it can be built or used apart from the rest of the mozilla browser. This API is completely different from that used by the rest of NSS. I don't know if PSM could use this or not. 2. I found no code there that parses any SOCKS configuration files, either old or new style, and no code that uses the IP address of the target server to determine which (if any) of the SOCKS proxies to use to reach the target server. It appears that this SOCKS layer is configured with a string containing the domain name of the socks proxy to be used for this connection, and that proxy is used unconditionally for the socket on which this layer has been pushed. So, apparently, the decision of which socks proxy (if any) to use must rest upon the application, or upon code outside of this layer. It appears that Mozilla has the same SOCKS proxy configuration GUI as Communnicator had, which permits only a single SOCKS proxy to be specified by name (or address) and port number.

This bug focuses on the code aspects, but I think that we should define both the minimal features for "SOCKS support", as well all the desired features. The features probably also need to be classified in some way so that they can be implemented and tested in parts. I think the minimal support would be SOCKS V5 support of a single SOCKS host:port. No SOCKS V4 support, which, according to the NEC site, is not a subset of SOCKS V5. This should be added immediately to the next release of mozilla and NS6, and tested with a specific list of protocols, like HTTP, HTTPS, FTP, and everything in mailnews. (Someone can make a case for gopher here if they want...) The other features are going to make the network admins of enterprise customers very happy, but it would be good to get an idea of how to prioritize them. Also, I'm not clear on the SSL & SOCKS part, is this a feature that uses SOCKS for SSL connections (HTTPS, SNEWS, etc) or SSL'd SOCKS (client-SOCKS server connection in SSL to encrypt the session on a untrusted local network?)

What is needed is for https to work over a SOCKS connection for certain. We don't encrypt all traffic for non-SOCKS users over the untrusted internet, so why just for SOCKS. Besides they can always get IPsec. For me the desired operation for the SOCKS implementation should be transparent, and protocol independant. Unlike an http proxy, SOCKS can accomodate any TCP connection (ala SocksCap also from NEC). My personal preference is to include SOCKS V4 as well (because that's all we've got) but maybe I'm too backward thinking.

If you want to make a SOCKS V4 contribution, bug 65583 is ready to be assigned to you. As for HTTPS requests over SOCKS, my general impression is that this works. If it does not, please file a bug.

Sorry, I was merely suggesting that your first option (for HTTPS, SNEWS, POP3, etc. over SOCKS) was the correct answer. I think a TCP protocol independant implementation, like SocksCap, would benefit many SOCKS (dis)abled users. Although seeing as I only have SOCKS 4, https DOESN'T work. For me anyways.

For what its worth, using the 2001062104 nightly build for Win32, and a SOCKS V5 server (Aventail) HTTPS does not work. If I disable socks, I can connect to internal HTTPS web sites, with socks enabled (bouncing off of the proxy server) I can not. We would also be very interested in a clean SOCKS V5 implementation!

See bug 89500. When that is fixed, all protocols in mozilla should be able to easily support socks. Its tied into necko though, so wouldn't be suitable for NSS directly, I think.

What about this bug?

Nelson was proposing a specific aspects of how SOCKS should work. Perhaps he's still reading bugmail...

Let's face it. There have been no volunteers for this bug for 5.5 years. NSS mgmt doesn't desire this enough to schedule it. SOCKS is really now perceived to be out of scope for NSS. (Somewhat ironic, since SSL 1 was a SOCKS 4 client) WONTFIX.