All users were logged out of Bugzilla on October 13th, 2018

SOCKS V5 Implementation

VERIFIED FIXED in M17

Status

()

P3
normal
VERIFIED FIXED
19 years ago
18 years ago

People

(Reporter: b.benowitz, Assigned: ruslan)

Tracking

Trunk
All
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta2-], URL)

Attachments

(5 attachments)

(Reporter)

Description

19 years ago
Unable to load pages behind SOCKS Server. No meaningful messages displayed.
(Reporter)

Comment 1

19 years ago
Created attachment 2104 [details]
Error messages in apprunner window

Updated

19 years ago
Assignee: gagan → rpotts
Target Milestone: M15

Comment 2

19 years ago
Socks support isn't in yet. Marking for later and assigning to rick.

Comment 3

19 years ago
Bulk move of all Networking-Core (to be deleted component) bugs to new
Networking component.
(Assignee)

Comment 4

19 years ago
-> marketing
Assignee: rpotts → warren

Comment 5

19 years ago
> -> marketing

I'm not in any great hurry to appear foolish, but what do you mean by that?

Comment 6

19 years ago
Netscape doesn't intend to implement socks for this product, although we welcome 
a submission to mozilla.org.
Assignee: warren → nobody
Keywords: helpwanted
Target Milestone: M15 → M30

Comment 7

19 years ago
I hated to see Socks Proxy Server support pushed off.  I wanted to stick in some 
information incase anyone was looking later.....

Main Socks page
http://www.socks.nec.com/

If you want socks support in Mozilla and you are on Windows one can use this:
http://www.socks.nec.com/socks5.html

SOCKS v5 is an IETF standard (RFC 1928)

Updated

19 years ago
Blocks: 35843

Comment 8

19 years ago
I'll implement SOCKS support.
See my post in netscape.public.mozilla.netlib for details.
Just be sure to do it so that it works both with and without PSM,
that is so that both http and https URLs work with it.

Comment 10

19 years ago
I have a working NSPR IO layer implementing SOCKS proxying.
Once I've cleaned it up, I'll submit it and start working on
the transports and protocols so that they will make use of it.
Since it's an NSPR IO layer, it should work fine with the SSL layer,
but it will require some minor changes to nsSocketTransport.
I can test SSL and SOCKS layers together before the protocol changes,
however, to make sure everything is interacting correctly.

Comment 11

19 years ago
Created attachment 10008 [details]
SOCKS support for HTTP and FTP, with UI configuration

Comment 12

19 years ago
The above patch should bring mozilla up to netscape 4.x's socks support,
except for SSL over SOCKS. It should work, but it's not for me. I'll continue
working on it, and adding SOCKS support to the other protocols.
(Assignee)

Comment 13

19 years ago
Ok. Justin Bradford <justinb@gene.com> has implemented SOCKS support. To get it 
in we'll need to move the tag on NSPR to get the latest changes for non-blocking 
connect and make a few API changes. Otherwise it's working great. Changes are 
not drastic, but still fair in size. Nominating for nsbeta2, chaning the target 
milestone and awaiting the decision from PDT.
Assignee: nobody → ruslan
Keywords: helpwanted → nsbeta2
Hardware: PC → All
Target Milestone: M30 → M17
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED

Updated

19 years ago
Whiteboard: [nsbeta2-]

Comment 14

19 years ago
[nsbeta2-] not required for seamonkey beta2 but you can always check in mozilla 
community contributions with approval from brendan or waterson. cc'ing Wan-Teh 
for comments about needing a new rev of NSPR

Comment 15

19 years ago
The current implementation of SOCKS support does
blocking connect and hence does not need a new rev
of NSPR.

Comment 16

19 years ago
Created attachment 10240 [details]
patch to make ssl work over socks -- this has some replacement patches/files for the previous patch
(Assignee)

Comment 17

19 years ago
Brendan? Can we check this in?

Comment 18

19 years ago
Created attachment 10348 [details] [diff] [review]
A new and improved version of the socks patch.

Comment 19

19 years ago
Created attachment 10351 [details]
the one new file to add to the tree for socks

Comment 20

19 years ago
Ruslan committed all (but one) of the new files, so the new patch is 
against that. The second attachment is actually a tar file with the
one remaining file: extensions/psm-glue/src/MANIFEST

The mac build files have not yet been updated, but I'll do that once
I get approval to commit this patch.
No longer blocks: 35843
Justin, looks great -- a=brendan@mozilla.org if you attend to these nits:

- Can't tell due to diff -wu, but I hope all tabs have been expanded,
  and indentation looks uniform and even and stuff.

- Does CMT_ProxyStepUp need to modify its final argument, which is a
  copy created using nsCAutoString by nsPSMSocketInfo::ProxyStepUp?
  I couldn't tell from reading 
http://lxr.mozilla.org/mozilla/source/security/psm/lib/client/cmtssl.c#414

  Maybe the final paramter to CMT_ProxyStepUp should be const char*?
  I'm also wondering why mHostName is an nsString, instead of an
  nsCString, but that's not your doing.  Might be worth filing a bug.

  Should CMT_ProxyStepUp error return values propagate back via bad
  nsresults through securityInfo->ProxyStepUp() to its caller?

- Is it really necessary to hold onto the PSM service via gPSMService?
  I see only one use of that variable, in nsSSLIOLayerConnect (whose
  name follows the class naming convention, not the static PR_CALLBACK
  naming convention [such as there is]).  If you're using this service
  only at connect-time, why not use NS_WITH_SERVICE to make a local,
  auto-pointer-held reference?

  It's bad to hold onto services forever, especially in embedding cases
  where things may need to unload and return all memory to the app.

- else after return in nsFtpConnectionThread::CreateTransport -- a
  non-sequitur that's not repeated at the bottom of that method, where
  there's a nice final return that several cases "fall into" without
  unnecessary else's.

- Argh, nsIHTTPChannel.idl uses InterCaps, not interCaps, in attribute
  names -- what's up with that?  The xpidl compiler will capitalize an
  attribute name before prepending Get or Set in the C++ binding, and
  the JS binding wants interCaps (JS and Java style, and Mozilla XPIDL
  house style for that matter).

/be
I should have written a=brendan@mozilla.org, check in bug please attend to these 
nits either first, or in a quick followup checkin.

/be

Comment 23

19 years ago
1. I've checked tabs and indentation and everything looks fine.

2. That non-const argument is passed down into the PSM code and used in the 
message encoder. I just looked over the code and it would appear that making it 
const would not affect anything. However, I didn't write any of the involved 
code (I'm  simply calling an existing function) and I've never looked beyond 
CMT_ProxyStepUp prior to 10 minutes ago. A practically identical path is taken 
by the normal SSL connection call, which also has non-const arguments...

2b. I return from PSMSocketInfo::ProxyStepUp the return code from 
CMT_ProxyStepUp, so the error should already be propagated to the 
SocketTransport, which is its caller.

3. Usage/storage of PSM service by SSL layer: The PSM service basically 
represents a daemon, and I suspect multiple services imply multiple daemons. So, 
while, I agree that it shouldn't be a static sitting around there, I'm not sure 
what effect it would have on the behavior (possibly causing start-psm to 
load/unload frequently when accessing a site via SSL; possibly spawning many psm 
daemons; etc). I believe the case is now, when SSL is used, psm runs and doesn't 
quit until the browser does. That's not good, but I don't know how to fix 
it right now.

I should also point out that I haven't written or even touched most of the parts 
you're referring to here. My changes to the SSL stuff were very basic. The 
AddToSocket which does exactly the same thing as NewSocket (excepting the 
allocation of a socket) and enabling the existing SSL proxy mechanisms. I can't 
address #2 or #3 without studying the PSM module more, and I think they're 
unrelated to this patch (as they're existing issues). I'll file bugs for both 
address them later.

4. I've removed the unnecessary else from the FTP's CreateTransport

5. I've changed all of the attributes in nsIHTTPChannel.idl to interCaps style, 
including the one attribute I am adding.

Should I go ahead with the commit?
(Assignee)

Comment 24

19 years ago
Sorry - was on vacation. Is it not landed yet?

Comment 25

19 years ago
I committed the code last night. Is anyone having trouble on non-Linux 
platforms?

Comment 26

19 years ago
I've tested a Win32 nightly build with my SOCKS code. It appears to be working 
fine, except for SSL connections (which work fine on Linux). Can anyone else 
confirm this?
(Assignee)

Comment 27

19 years ago
I guess this is done, right Justin?
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Reporter)

Comment 28

19 years ago
As the originator of this problem, I had a chance to test the 7/6/2000 Nightly build on Linux and I
still find 2 problems:
1) When you originally set the SOCKS HOST name and port in preferences and then click OK, 
 the main window starts loading fine. But the tinderbox window continues to say Loading... for
 ever. Performance suffers as well. If you exit Mozilla and restart, everything is fine.

2) Secure Pages don't seem to load. However, I'm not sure that those fixes were committed, yet.

Comment 29

19 years ago
I haven't experienced your first problem, but I'll try to replicate it.

As for the SSL problems, the code was committed, and it does work on Linux.
I'm not gotten it to work on win32, but I'm not sure if I have the PSM module
installed/configured. I'll look into this more.

Comment 30

18 years ago
It doesn't seem to work at all here.  After setting the socks host and port to 
the same values which IE uses successfully, mozilla is unable to load any 
site.  For example, if I try to load mozilla's homepage the taskbar will show 
"Resolving host www.mozilla.org", but it never gets any further.

The OS is NT4, SP6.

Comment 31

18 years ago
What version of SOCKS does your firewall support?
Mozilla only supports version 5 right now.

Comment 32

18 years ago
That would explain it... I'm pretty sure that ours is only SOCKS4.  I'll try to
verify this, just to be sure.

Thanx!

Comment 33

18 years ago
I created a patch that adds Socks4 support to Justin's Socks5 layer.  It detects
the server protocol version by trying Socks4 first, then Socks5.  This test is
rather expensive if the server is Socks5 (extra TCP connection setup/close). 
This raises some issues... should a cache of Socks server versions be
maintained?  It would be relatively simple to cache only the most recent server,
but a proxy autoconfig script could return different Socks servers for different
destination addresses during the same session, so this might not be ideal.  But
it might be adequate.  A full-blown cache would be more work, but doable. 
Perhaps there is already some infrastructure for this sort of thing?

Or would it be better to expose this in the configuration UI?

Any suggestions?

Comment 34

18 years ago
Might want to make this a separate bug.

There should be selector UI that supports this, but even more so, we might want
to just completely re-do the UI. The old UI doesn't work well for SOCKS in
general because there is a lack of clarity for order of precedence.

My feeling is that we should just EOL SOCKS V4. It's not specified in an RFC,
and there doesn't seem to be much in the way of handshaking or backwards
compatability.

A -quick- look at the SOCKS V5 RFC seems to show that the client initiates the
call for a version...

http://www.faqs.org/rfcs/rfc1928.html

 The VER field is set to X'05' for this version of the protocol.  The
   NMETHODS field contains the number of method identifier octets that
   appear in the METHODS field.

Comment 35

18 years ago
I've re-read the RFC's and NEC's specs. My reading is that there is no effective
handshake for versions. My gut says we should add a "SOCKS V4" and SOCKS V5"
selector in manual prefs. If you don't, then your version failover (which isn't
a real handshake) might fill up a SOCKS server with error messages.
 

Comment 36

18 years ago
VERIFYING BUG:
Used a packet trace...
http://www.packetgram.com/pktg/proxy/socksclientversion.html

General information on how when SOCKS is used for connections
http://www.packetgram.com/pktg/docs/nscp/ns6/ns6proxy.html#socks

clarified Summary for accuracy.
put a URL into URL field.
keyed for release note

Want any of the following? 

A fix for the prefs (say "SOCKS V5", not "SOCKS"), see bug 50679

create a new bug.

SSL and SOCKS (either combination)
SOCKS V4
SOCKS server version handshaking

Status: RESOLVED → VERIFIED
Keywords: relnote
Summary: Can't browse behind a SOCKS firewall → SOCKS V5 Implementation

Comment 37

18 years ago
-relnote - other SOCKS bugs are tagged w/ relnote keyword.
Keywords: relnote
You need to log in before you can comment on or make changes to this bug.