SOCKS: Username/Password Authentication (V5)

NEW
Unassigned

Status

()

Core
Networking
P3
minor
15 years ago
12 days ago

People

(Reporter: Ivan Dolezal, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [necko-backlog][proxy])

Attachments

(3 attachments, 5 obsolete attachments)

(Reporter)

Description

15 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.8+) Gecko/20020130
BuildID:    200213003

Mozilla provides its users with SOCKSV5 proxy connectivity, but doesn't
implement one of the crucial parts of V5 over V4 that is Username/Password
Authentication. Any other product that implements v5 and I can think of (AOL
Mirabilis ICQ, AOL Instant Messenger, mIRC, latest Windows Commander, Effata),
does implement U/P auth. V5 without U/P is pretty much useless.
I don't think it is necessary to implement other one-time password mechanisms,
but this is a strong advocacy for plain U/P. Not because it is a good
authentication method (the password is sent in plaintext), but because it is
truly used :-/

Reproducible: Always
Steps to Reproduce:
1. ask your SOCKSv5 administrator for an address of your Socks5 server
2. he gives you also username and password
3. there is no way to explain to Mozilla, that you need to use RFC 1929
authentication to get out of the hell of security


Actual Results:  No FTP and other protocols except HTTP (that is open).

Expected Results:  Ask for username and password to use SOCKSv5 proxy with RFC
1929 username/password authentication ... as seen on
http://www.rfc-editor.org/rfc/rfc1929.txt

Comment 1

15 years ago
According to the first additional comment in bug 133939, Mozilla does support 
user/pass authentication in SOCKS 5.

Taking that into effect and the fact that your build is already two versions 
old, I am changing this to WORKSFORME for now... if you want to pursue this and 
you have the same problem in 1.0RC1, feel free to reopen the bug and provide 
some more info.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME

Comment 2

15 years ago
Changed severity too, since this is more of a bug rather than a request for 
enhancement.
Severity: enhancement → minor

Comment 3

15 years ago
-> qa
REOPEN:
I don't think this really works. To my knowledge it didn't in 4xp, and it
doesn't here.

That comment was talking about auth mechanisms in general, nobody has gotten any
auth to work w/ SOCKS, as far as I can tell.
Status: RESOLVED → UNCONFIRMED
QA Contact: benc → socksqa
Resolution: WORKSFORME → ---
Summary: Username/Password Authentication for SOCKS V5 → SOCKS: Username/Password Authentication (V5)
Target Milestone: --- → Future

Comment 4

15 years ago
What is the status of this bug?

pi

Comment 5

15 years ago
Let's rest this bug in peace until someone can give a clear way to see the problem.

pi
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago15 years ago
Resolution: --- → WORKSFORME

Comment 6

14 years ago
REOPEN:
I've got an internal socks5 + auth server working. I've tested it w/ AIM and a
couple other SOCKS v5 + auth clients.

I should note here that NIM (Netscape's IM module) also seems to not work
correctly, even though SOCKS V5 + auth is supported in the config dialog.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---

Updated

14 years ago
Blocks: 200882

Comment 7

14 years ago
I can confirm this with my freshly downloaded  Mozilla:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401

Using other SOCKSv5 clients connecting to a SOCKS server, it prompts, or at
least barfs when not provided.  Mozilla will just return a blank page (or the
first time, a "No Data" message).

Comment 8

14 years ago
NEW, nsbeta1. End users need error messages.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: nsbeta1

Comment 9

14 years ago
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-

Comment 10

14 years ago
Confirm again. Freshly downloaded Mozilla still exhibits problem.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507
*** Bug 216316 has been marked as a duplicate of this bug. ***

Comment 12

14 years ago
-> defaults.
Keywords: nsbeta1-

Updated

14 years ago
Blocks: 225485

Comment 13

14 years ago
*** Bug 225485 has been marked as a duplicate of this bug. ***

Comment 14

14 years ago
Workaround for Linux and Win32.  Both these solutions work very well.

Windows users can download SocksCap form http://www.socks.nec.com which is a GUI
based SOCKS5 wrapper that allows for SOCKS5 username/password authentication.

Linux users can download the SOCKS Reference implementation from the same
source.  This contains a command line wrapper called "runsocks".  Set the
following variables to make it work:

SOCKS5_SERVER=your.socks.server
SOCKS5_USER=username
SOCKS5_PASSWD=password

And then launch Mozilla with $ runsocks mozilla  


Comment 15

14 years ago
-> defaults again.
Assignee: neeti → darin

Comment 16

13 years ago
Worse, once you have pointed to a socks server that does not work, you cannot
switch socks servers, see bug 233811.

Comment 17

13 years ago
(In reply to comment #14)
> Workaround for Linux and Win32.  Both these solutions work very well.
> 
> Windows users can download SocksCap form http://www.socks.nec.com which is a GUI
> based SOCKS5 wrapper that allows for SOCKS5 username/password authentication.
> 
> Linux users can download the SOCKS Reference implementation from the same
> source.  This contains a command line wrapper called "runsocks".  Set the
> following variables to make it work:
> 
> SOCKS5_SERVER=your.socks.server
> SOCKS5_USER=username
> SOCKS5_PASSWD=password

This is a pretty ordinary workaround.  I've been working on bug #134105 and did
a fix for this bug while I was at it.  The issue is UI support (or lack
thereof.)  It's easy enough to fix nsSOCKSIOLayer.cpp to be able to send
passwords, but due to SOCKS being transparent, prompting for them is not that
simple.

I've contemplated leaving this as a config setting, but having passwords
unencrypted in config is a bad idea.

If anyone can help me out with UI and/or PSM, that'd be great.

Comment 18

13 years ago
you can use the nsIWindowWatcher service's getNewAuthPrompter() method to get a
nsIAuthPrompt instance that you can use to prompt the user for a username and
password.  you could then keep a global hash table in memory that remembers the
username and password for the session.  when you use nsIAuthPrompt to interact
with the user, the browser's password manager feature will automatically kick in
and give the user the ability to have the browser remember their password in the
password manager database (which may be encrypted using PSM depending on how the
browser is configured). 

Comment 19

13 years ago
the only issue with my proposed solution is that using nsIWindowWatcher from
within necko is not really a good idea because necko should not depend on the
component that the window watcher implementation lives in.  unfortunately,
though, i can't really think of a good alternative.  we'd have to create one or
just use nsIWindowWatcher directly for now :-(
it is unfortunate that the SOCKS code does not have a channel available off
which it could get the auth prompt...

Comment 21

13 years ago
we could use the same trick that we use for SSL.  the socket transport code
actually queries the securityInfo returned from the SSL socket provider to an
interface that allows it to set a nsIInterfaceRequestor that provides an
implementation for nsIAuthPrompt.  perhaps we should generalize this interface.

see nsISSLSocketControl
that sounds like a much better suggestion than requiring nsIWindowWatcher;
especially as it also allows other nsIAuthPrompt impls than windowwatcher's.

Comment 23

13 years ago
*** Bug 257522 has been marked as a duplicate of this bug. ***

Updated

13 years ago
QA Contact: socksqa → benc

Updated

13 years ago
Blocks: 257522
Depends on: 274042

Comment 24

13 years ago
Why is it taking so long to fix this simple problem?

Comment 25

12 years ago
*** Bug 285562 has been marked as a duplicate of this bug. ***

Comment 26

12 years ago
Removing SSL bug dependency.

There is a proposed standard for SOCKS5-SSL support, but so far it hasn't 
gotten far; and even if it did, merely having SSL won't do any authentication; 
authentication is handled seperately.

Over the weekend, I wrote a fix for this bug to do RFC1929 and CHAP 
authentication.  I'm just doing final builds today, I'll post it tomorrow.

What I need (always needed!) is somebody who knows UI better than me to use the 
password dialog and remember passwords in a sane fashion...
No longer depends on: 274042
(In reply to comment #26)
> There is a proposed standard for SOCKS5-SSL support, but so far it hasn't 
> gotten far; and even if it did, merely having SSL won't do any authentication; 
> authentication is handled seperately.

Indeed, but see bug 274042 comment 1 for the rationale... Both of these bugs
will need a way to set/get an interface requestor.

Although, the securityCallbacks attribute exists...

Comment 28

12 years ago
I wonder if this bug has been solved in the version 1.5 beta ?

(In reply to comment #0)
> From Bugzilla Helper:
> User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.8+) Gecko/20020130
> BuildID:    200213003
> 
> Mozilla provides its users with SOCKSV5 proxy connectivity, but doesn't
> implement one of the crucial parts of V5 over V4 that is Username/Password
> Authentication. Any other product that implements v5 and I can think of (AOL
> Mirabilis ICQ, AOL Instant Messenger, mIRC, latest Windows Commander, Effata),
> does implement U/P auth. V5 without U/P is pretty much useless.
> I don't think it is necessary to implement other one-time password mechanisms,
> but this is a strong advocacy for plain U/P. Not because it is a good
> authentication method (the password is sent in plaintext), but because it is
> truly used :-/
> 
> Reproducible: Always
> Steps to Reproduce:
> 1. ask your SOCKSv5 administrator for an address of your Socks5 server
> 2. he gives you also username and password
> 3. there is no way to explain to Mozilla, that you need to use RFC 1929
> authentication to get out of the hell of security
> 
> 
> Actual Results:  No FTP and other protocols except HTTP (that is open).
> 
> Expected Results:  Ask for username and password to use SOCKSv5 proxy with RFC
> 1929 username/password authentication ... as seen on
> http://www.rfc-editor.org/rfc/rfc1929.txt
(In reply to comment #28)
> I wonder if this bug has been solved in the version 1.5 beta ?

No, because if it was, then this bug would be marked FIXED.

Updated

11 years ago
Assignee: darin → nobody
QA Contact: benc → networking
Target Milestone: Future → ---

Updated

9 years ago
Duplicate of this bug: 225485
Duplicate of this bug: 457685

Comment 32

9 years ago
This bug was opened over 6 years ago, yet I see no attempt to resolve it.

Please read the details in bug 457685 which offers justification on why the USERNAME/PASSWORD authentication SHOULD be added.

It also mentions the need for error messages.

I also noticed that the suggested workaround is no longer reliable because there is no official site for Sockscap or a decent alternative.

I read in the threads problems surrounding the ability for necko to prompt a window. First of all, I am sure there is a way it can be done, especially after 6 years. Other than that, why not store the login details in the config, sure it'd have to be plain text, but it's better than nothing. Sometimes security should be left up to the user.

Comment 33

9 years ago
SocksCap has stopped being actively maintained as far as I can tell.  FreeCap (http://www.freecap.ru/eng) is another alternative for Windows users.  There's several others out there but this one is the only free solution I know of.

Comment 34

9 years ago
This patch adds support for u/p authentication, im not sure how the username/password should be obtained though... so right now it doesn't actually work.

--- nsSOCKSIOLayer.cpp	2008-10-15 21:00:15.000000000 -0400
+++ nsSOCKSIOLayer-withauth.cpp	2008-10-15 23:00:16.000000000 -0400
@@ -172,22 +172,28 @@
     NS_ENSURE_TRUE(addr, NS_ERROR_NOT_INITIALIZED);
     NS_ENSURE_TRUE(extAddr, NS_ERROR_NOT_INITIALIZED);
 
-    unsigned char request[22];
+    unsigned char request[1+1+255+1+255];//VER+ULEN+UNAME+PLEN+PASSWD
     int request_len = 0;
     unsigned char response[22];
     int response_len = 0;
 
+    // where do i get the username/password from :( ???????
+    //, nsACString username, nsACString password
+
+    unsigned int offset = 0;
+
     request[0] = 0x05; // SOCKS version 5
-    request[1] = 0x01; // number of auth procotols we recognize
+    request[1] = 0x02; // number of auth procotols we recognize
     // auth protocols
     request[2] = 0x00; // no authentication required
+    request[3] = 0x02; // username/password
+
     // compliant implementations MUST implement GSSAPI
     // and SHOULD implement username/password and MAY
     // implement CHAP
     // TODO: we don't implement these
     //request[3] = 0x01; // GSSAPI
-    //request[4] = 0x02; // username/password
     //request[5] = 0x03; // CHAP
 
     request_len = 2 + request[1];
     int write_len = PR_Send(fd, request, request_len, 0, timeout);
@@ -201,7 +207,7 @@
     response_len = 2;
     response_len = PR_Recv(fd, response, response_len, 0, timeout);
 
-    if (response_len <= 0) {
+    if (response_len != 2) {//the only response that is acceptable is a two octal response, a single octal response is no good
 
         LOGERROR(("PR_Recv() failed. response_len = %d.", response_len));
         return NS_ERROR_FAILURE;
@@ -223,14 +229,59 @@
             return NS_ERROR_FAILURE;
         case 0x02:
             // username/password
-            // TODO: implement
-            LOGERROR(("Server want to use username/password to authenticate, but we don't support it."));
-            return NS_ERROR_FAILURE;
+            if(username.Length() > 255 || password.Length() > 255)
+            {
+                LOGERROR(("Username or Password too long, must be 255 characters or less."));
+                return NS_ERROR_FAILURE;
+            }
+
+            offset = 0;
+
+            request[offset] = 0x01; //subnegotiation version defined in RFC1929
+            offset += 1;
+
+            request[offset] = username.Length();
+            offset += 1;
+
+            memcpy( request + offset , PromiseFlatString( username ).get() , username.Length() );
+            offset += username.Length();
+
+            request[offset] = password.Length();     
+            offset += 1;
+
+            memcpy( request + offset , PromiseFlatString( password ).get() , password.Length() );
+            offset += password.Length();
+
+            request_len = offset;
+
+            write_len = PR_Send(fd, request, request_len, 0, timeout);
+
+            if ( write_len != request_len) {
+
+                LOGERROR(("PR_Send() failed. Wrote: %d bytes; Expected: %d.", write_len, request_len));
+                return NS_ERROR_FAILURE;
+            }
+
+            response_len = 2;
+            response_len = PR_Recv(fd, response, response_len, 0, timeout);
+            
+            if (response_len != 2) {
+
+                LOGERROR(("PR_Recv() failed. response_len = %d.", response_len));
+                return NS_ERROR_FAILURE;
+            }
+
+            if( response[1] != 0 )
+                return NS_ERROR_FAILURE;
+            break;
         case 0x03:
             // CHAP
             // TODO: implement?
             LOGERROR(("Server want to use CHAP to authenticate, but we don't support it."));
             return NS_ERROR_FAILURE;
+        case 0xFF:
+            LOGERROR(("Server does not support available authentication methods."));
+            return NS_ERROR_FAILURE;
         default:
             // unrecognized auth method
             LOGERROR(("Uncrecognized authentication method received: %x", response[1]));

Comment 35

9 years ago
For now, can't you just add some settings into about:config, pull it from there...

Something better can be done later.

Comment 36

9 years ago
HM2K: I have no idea how to access the about:config preferences, that seems like it is the best way to do it however

Comment 37

9 years ago
Created attachment 343493 [details] [diff] [review]
Patch to give ConnectSOCKS5 function support for u/p authentication

This patch adds username/password authentication support to the ConnectSOCKS5.  The username/password are stored as preferences.  In the event that either the username or password are not set the ability to do username/password authentication is not sent to the server.

Updated

9 years ago
Attachment #343493 - Flags: superreview?(cbiesinger)
Attachment #343493 - Flags: review?(cbiesinger)
OK, you really can't store the password in plaintext in a preference, I'm sorry.

The right way to do this is to get access to the notificationCallbacks and get an nsIAuthPrompt from there.

This is unfortunately a bit annoying since the APIs for this were designed for PSM only. See:
http://mxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsSocketTransport2.cpp#1040

Ideally, you'd add a new interface just for setting notification callbacks, and use that to set the notification callbacks for all socket types. Then the SOCKS code can get an nsIAuthPrompt that way.

Do you want to do that?

(Also note that there's the patch in bug 459524, which probably conflicts with the one here)


Some brief comments on the patch itself:
- Please declare variables close to where you first use them
- Use PRBool/PR_TRUE/PR_FALSE in Mozilla code, instead of the C++ type
- "result" is generally called "rv"
- Use spaces after commas (e.g. in your LOGDEBUG calls) but not before them
- No spaces on the inside of parentheses, e.g. use strlen(foo) instead of strlen( foo )
- Using GetCharPref like you do is a memory leak (prefer nsXPIDLCString)
Attachment #343493 - Flags: superreview?(cbiesinger)
Attachment #343493 - Flags: review?(cbiesinger)
Attachment #343493 - Flags: review-
The other option is to get an nsIAuthPrompt via NS_DEFAULTAUTHPROMPT_CONTRACTID, but that is a less ideal solution.

Comment 40

9 years ago
You really CAN store the password in plaintext in a preference and I don't see why not.

Nobody is forcing you to use it, you use it at your own digression. It'll get sent in plain text anyway, and besides there is usually more layers of security at the other end, including IP restrictions.

Further more, if they want more security they can use the GSSAPI method.

Further more again, at least this method would stop you fumbling around an issue that has been here for over 6 years. More advanced password handling could come at a later date.

Updated

8 years ago
Duplicate of this bug: 502415

Comment 42

7 years ago
any news up on this?

Updated

7 years ago
Duplicate of this bug: 405808

Comment 44

5 years ago
please fix this issue, it's very important

Comment 45

5 years ago
10 years anniversary and still "NEW" -- congratulations!

How can it possibly be difficult to implement RFC1929?

About RFC1929 being plaintext authentication, some web proxys that require authentication use the "Basic" scheme, which sends passwords in the clear as well. Simple authentication schemes are there to prevent abuse, not to protect accounts.

Comment 46

5 years ago
This bug is accepting contributions, so if you believe the change is straightforward feel free to make a proposal.

I coded this up a long time ago, and found the difficulty was not implementing RFC1929 but hooking in an acceptable UX.  SOCKS is supposedly "transparent" to the higher level socket operations.  Spinning up UI to prompt for username/password is anything but.  The difficulty here will be restructuring code to make SOCKS less "transparent" to the higher layers.

Comment 47

5 years ago
I was just venting my frustration, please forgive my arrogance... I did not mean to insult anyone.

So, the problem is that the connection part of the code is unable to obtain credentials from the config? Configured u/p would be enough for most people.

Comment 48

5 years ago
As per my suggestion back in 2008:

https://bugzilla.mozilla.org/show_bug.cgi?id=122752#c35

I see no reason why this can't go ahead and read from the about:config.

Comment 49

5 years ago
Obvious solution is to use user:password@host scheme for proxy host.

I have implemented this feature, patch is here: http://ololo.cc/files/socks5_auth.diff

It uses both offered schemes: url-based authentication and settings-based (network.socks.username and network.socks.password values, not tested yet).

Comment 50

5 years ago
Patch for FF17: http://ololo.cc/files/socks5_auth_ff17.diff
Created attachment 684989 [details] [diff] [review]
Patch

Thanks for the patch, Grigory. Our process requires patches to be attached to bugs so they can be reviewed using the integrated Bugzilla tools, so I've gone ahead and done that.
Attachment #684989 - Flags: review?(mcmanus)
Attachment #684989 - Flags: review?(mcmanus) → review?(cbiesinger)
Comment on attachment 684989 [details] [diff] [review]
Patch

I don't think this patch is acceptable while attachment 343493 [details] [diff] [review] is not.

Comment 53

5 years ago
This bug is open for over 10 years and it's _really_ annoying. The patch is a working solution. Why don't accept it until someone writes a better patch? (in the year 2022 or so...)

@plaintext in a preference: The password is send in plaintext over the network.

Comment 54

5 years ago
Secure authentication requires GSSAPI or SOCKS over SSL, which is beyond my knowledge of FF architecture. Moreover, I have never met such servers in real life. Plain username/password authentication usually is the only option.

As said by author himself, attachment 343493 [details] [diff] [review] is simply not working: it does not obtains authentication data, it cannot authenticate at all. Besides, it was been written very long time ago, it cannot be applied to current version of FF.

Comment 55

5 years ago
karl155, I absolutely agree with your frustration. The SOCKS protocol is a mess and a perfect example of how not to design a protocol. Absolutely no-one uses GSSAPI, it was ridiculous to require it in the RFC (instead of recommending it) and it is ridiculous to refuse a working implementation for not supporting this requirement or having a clear text password in preferences that is transmitted in the clear anyway. But I highly doubt the purists will share this view. And I can understand this as well, someone will point fingers at them and claim that Firefox handles a password insecurely. On the other hand, Thunderbird supports POP3 plaintext authentication without link encryption too... this no-no has a lobby. :-)

Adding SSL/TLS support for SOCKS connections is useless too, no server I know supports it. SOCKS was never meant to be used outside LAN environments.

Comment 56

5 years ago
In fairness to the designers of the protocol, it was not clear in March 1996 that the world would adopt SSL over alternatives including GSSAPI, and unfortunately the standard has not been maintained.  There was an SSL proposal, but it died before being finalized.  A SOCKS 5.1 protocol would probably have a very different emphasis.

With respect to these patches though, this is the third time this bug has had a patch storing credentials in a pref, and I don't get the sense that it's going to be accepted where the previous ones have not.  Note that the solution to obtaining and/or storing passwords is naturally applicable to cleartext as well as other authentication types (eg. CHAP), and TB's cleartext authentication at least attempts to obfuscate passwords stored locally.  The local storage issue isn't going away.

This bug is still looking for a contributor with the experience and/or motivation to tie together UI and SOCKS changes, possibly involving a fair bit of refactoring, and the SOCKS changes are the easier portion.

Comment 57

5 years ago
As I see in current bug, there was only one patch proposal. And the main problem in that proposal was the fact, that proposed patch was NOT working: that patch only implements SOCKS authentication, but without credentials obtainment.

My proposal is a) working, b) obtains credentials from the proxy URL string. I believe, that such implementation is far better than not to support SOCKS authentication at all.

I don't think too, that credentials in preferences is good solution, I have implemented that only as a placeholder for future improvements, that part could be simply removed from proposal. But credentials in URL is a common practice.

Maybe somewhere in a next decades someone would refactor current architecture, but this bug is annoying for the past decade. And there is a solution to deal with it right here right now.

Comment 58

5 years ago
I agree to Grigory, if I save a bookmark in the form http://user:password@domain.com/ it is stored in plaintext too (just tested it). I see absolutely no difference here.

Grigory's patch solves a problem that is more fore than 10 years unsolved and has exactly the same security level as bookmarks. If you say that his patch is unsafe because it stores credentials in an URL, then you must disable bookmarking too. I am sure nobody wants that.
So please accept Grigory's patch.
Comment on attachment 684989 [details] [diff] [review]
Patch

I really think that any patch for this bug requires UI of some sort. Otherwise, this is way too undiscoverable for any users.
Attachment #684989 - Flags: review?(cbiesinger) → review-

Comment 60

5 years ago
Oh come on. It really looks like you are trying to block this feature out. I have seen numerous bug entries where the UI was done later on in a separate bug.

Comment 61

4 years ago
biesi, the backend can be created independently from the UI. That said...

The Tor project also needs this feature, but they need to set the username/password *per connection*, using an API.

I have independently implemented that, without knowing of the patch here. I'll attach that patch.
Given that this bug is currently unassigned, I'll also take it.
Assignee: nobody → ben.bucksch

Comment 62

4 years ago
Created attachment 697715 [details] [diff] [review]
Alternate Patch, allowing set auth per connection per API - v8

Patch is against current Firefox trunk
Attachment #697715 - Flags: review?(cbiesinger)

Comment 63

4 years ago
https://trac.torproject.org/projects/tor/ticket/6733

Comment 64

4 years ago
Description of patch:
The goal is to allow code that has an nsIChannel for a connection to set the username and password for the proxy.
I extend nsIProxyInfo with username and hostname, then let nsISocketProvider.newSocket()/addToSocket() accept nsIProxyInfo instead of individual proxy parameters as they currently do. This allows to pass the username from nsSocketTransport2.cpp to nsISOCKSIOLayer.cpp, which implements SOCKS and can send the username to the proxy.
nsHttpChannel implements nsIProxiesChannel, which allows access to the nsIProxyInfo.

Luckily, nsISocketTransportService.createTransport() already accepts nsIProxyInfo. createTransport is called directly by the protocol implementations including http.

You should also be able to:
var channel = httpChannel.QueryInterface(Ci.nsIProxiedChannel);
var proxy = httpChannel.proxyInfo;
proxy.username = "abc";
proxy.password = "def";

I hope that an "on-modify-request" observer is not too late and the proxy connections is already open. I haven't been able to test that, due to lack of SOCKS servers that actually work and that accept a username. If it's too late, we'll have to find an earlier point that gives us an nsIChannel and the connection isn't open yet. Advise appreciated.

For more info, please cross-read the comments in the above Tor bug, before you make a final judgement. The goal for Tor is to separate/silo the requests to different groups of sites, so that the user can't be profiled (which can be dangerous for dissidents).

Comment 65

4 years ago
There are also prefs "network.proxy.socks_username" and "network.proxy.socks_password" to set static values for all connections - like the older patches do.
Created attachment 8496337 [details] [diff] [review]
0001-Bug-122752-Allow-setting-username-and-password-for-S.patch

Here's a modified and updated version of :BenB's patch.
Attachment #8496337 - Flags: review?(jduell.mcbugs)
Created attachment 8496443 [details] [diff] [review]
0001-Bug-122752-Allow-setting-username-and-password-for-S.patch

Minor fix to patch
Attachment #8496337 - Attachment is obsolete: true
Attachment #8496337 - Flags: review?(jduell.mcbugs)
Attachment #8496337 - Flags: review?(jduell.mcbugs)
Attachment #8496337 - Flags: review?(jduell.mcbugs)
Attachment #8496443 - Flags: review?(jduell.mcbugs)
Comment on attachment 8496443 [details] [diff] [review]
0001-Bug-122752-Allow-setting-username-and-password-for-S.patch

Review of attachment 8496443 [details] [diff] [review]:
-----------------------------------------------------------------

i've only glanced at this.. but honestly this touches a lot of fairly important code in order to tweak a very little used feature. Can you think of any way to make this less invasive to existing code paths?
Comment on attachment 8496443 [details] [diff] [review]
0001-Bug-122752-Allow-setting-username-and-password-for-S.patch

Review of attachment 8496443 [details] [diff] [review]:
-----------------------------------------------------------------

Michal said he'd look at this.  

Patrick's point in comment 68 is a good one.  If we could make this smaller/simpler, that would be great.
Attachment #8496443 - Flags: review?(jduell.mcbugs) → review?(michal.novotny)
Comment on attachment 8496443 [details] [diff] [review]
0001-Bug-122752-Allow-setting-username-and-password-for-S.patch

Review of attachment 8496443 [details] [diff] [review]:
-----------------------------------------------------------------

I don't think that all the logic of passing username and password down to socks IO layer is correct. After reading https://trac.torproject.org/projects/tor/ticket/6733 I still don't understand why is this feature needed. I think this needs to be more explained.

Anyway, having a global username and password for socks in preferences is bad. E.g. this won't work when you migrate computer between several networks where the socks is configured via proxy autoconfiguration. We IMO need some auth manager for socks similar to what we have for http webs/proxies. We should keep username/password for every socks proxy. When we don't have user/pass for the given proxy and the proxy requires authentication we need to ask user for it.

::: netwerk/socket/nsSOCKSIOLayer.cpp
@@ +536,5 @@
>  
>      // Send an initial SOCKS 5 greeting
>      LOGDEBUG(("socks5: sending auth methods"));
>      WriteUint8(0x05); // version -- 5
> +    WriteUint8(0x01); // # of auth methods -- 1

We should offer both methods and let server to decide which one we must use.

@@ +589,5 @@
> +    LOGDEBUG(("socks5: sending username and password"));
> +    // RFC 1929 Username/password auth for SOCKS 5
> +    WriteUint8(0x01); // version 1 (not 5)
> +    WriteUint8(mProxyUsername.Length()); // username length
> +    WriteString(mProxyUsername); // username

Username and password can be 255 characters, so it is not guaranteed that they always fit into mData. Either mData must be resized or preferably Write methods must reallocate the buffer if the data won't fit into the buffer.
Attachment #8496443 - Flags: review?(michal.novotny) → review-
(In reply to Michal Novotny (:michal) from comment #70)
> Comment on attachment 8496443 [details] [diff] [review]
> 0001-Bug-122752-Allow-setting-username-and-password-for-S.patch
> 
> Review of attachment 8496443 [details] [diff] [review]:
> -----------------------------------------------------------------

Thanks for the review.

> I don't think that all the logic of passing username and password down to
> socks IO layer is correct. After reading
> https://trac.torproject.org/projects/tor/ticket/6733 I still don't
> understand why is this feature needed. I think this needs to be more
> explained.

Sorry I didn't make this clear. The Tor Browser connects to the Tor network by sending its requests through a SOCKS connection to a Tor process. Tor listens for SOCKS connections and creates a separate Tor circuit for each SOCKS username+password combination. We want to enhance the security of the Tor Browser by running streams for each URL-bar domain through a separate circuit in the Tor network. Therefore we need to introduce a method for dynamically associating a SOCKS username+password with each network request.

> Anyway, having a global username and password for socks in preferences is
> bad. E.g. this won't work when you migrate computer between several networks
> where the socks is configured via proxy autoconfiguration. We IMO need some
> auth manager for socks similar to what we have for http webs/proxies. We
> should keep username/password for every socks proxy. When we don't have
> user/pass for the given proxy and the proxy requires authentication we need
> to ask user for it.

The global username+password in preferences is not actually needed for the Tor Browser feature described above. I will remove this part of the patch.

> ::: netwerk/socket/nsSOCKSIOLayer.cpp
> @@ +536,5 @@
> >  
> >      // Send an initial SOCKS 5 greeting
> >      LOGDEBUG(("socks5: sending auth methods"));
> >      WriteUint8(0x05); // version -- 5
> > +    WriteUint8(0x01); // # of auth methods -- 1
> 
> We should offer both methods and let server to decide which one we must use.
> 
> @@ +589,5 @@
> > +    LOGDEBUG(("socks5: sending username and password"));
> > +    // RFC 1929 Username/password auth for SOCKS 5
> > +    WriteUint8(0x01); // version 1 (not 5)
> > +    WriteUint8(mProxyUsername.Length()); // username length
> > +    WriteString(mProxyUsername); // username
> 
> Username and password can be 255 characters, so it is not guaranteed that
> they always fit into mData. Either mData must be resized or preferably Write
> methods must reallocate the buffer if the data won't fit into the buffer.

Thanks for these helpful points -- I will work on addressing them.
(In reply to Michal Novotny (:michal) from comment #70)

> ::: netwerk/socket/nsSOCKSIOLayer.cpp
> @@ +536,5 @@
> >  
> >      // Send an initial SOCKS 5 greeting
> >      LOGDEBUG(("socks5: sending auth methods"));
> >      WriteUint8(0x05); // version -- 5
> > +    WriteUint8(0x01); // # of auth methods -- 1
> 
> We should offer both methods and let server to decide which one we must use.

On further thought, it seems to me that it's better not to fall back to an unauthenticated connection if we are expecting to supply a username and password. So I would suggest that the client (Firefox) should only offer one method, either authenticated (with u+p) or unauthenticated (without) but not both.

> @@ +589,5 @@
> > +    LOGDEBUG(("socks5: sending username and password"));
> > +    // RFC 1929 Username/password auth for SOCKS 5
> > +    WriteUint8(0x01); // version 1 (not 5)
> > +    WriteUint8(mProxyUsername.Length()); // username length
> > +    WriteString(mProxyUsername); // username
> 
> Username and password can be 255 characters, so it is not guaranteed that
> they always fit into mData. Either mData must be resized or preferably Write
> methods must reallocate the buffer if the data won't fit into the buffer.

I've increased the size of mData to 513 bytes, which should be enough for a request as given by https://tools.ietf.org/html/rfc1929
Created attachment 8505061 [details] [diff] [review]
0001-Bug-122752-Allow-setting-username-and-password-for-S.patch
Attachment #8496443 - Attachment is obsolete: true
Attachment #8505061 - Flags: review?(michal.novotny)

Comment 74

3 years ago
12 years later and this still hasn't seen the light of day, despite patches being available in this bug report. Realistically speaking, what are the chances of seeing it in FF soon?

Comment 75

3 years ago
I suppose there is no chances at all. If you really interested in secure proxy — use VPN. SOCKS is unsecure, even a SOCKS5. And this issue - one more nail in the coffin.

Comment 76

3 years ago
I'm not interested in a secure/encrypted proxy, I have VPN for that and I'm well aware SOCKS does not encrypt anything. I'm just interested in being able to USE the Socks5a proxy I have which requires authentication! There's a pertinent reason to use it (it's a per application, get's around geo restrictions when I travel without a system wide vpn, etc).

It's quite disappointing that after 12 years this is still not implemented in any browser.

Comment 77

3 years ago
I'm too very frustrated about this issue. But, extrapolating current progress: that is close to zero chance that this issue will be ever resolved.

So, in objective reality, you have at lease following choices to resolve your tasks:
* apply attached patches and recompile firefox for yourself;
* use some [policy] routing scheme with VPN.

Personally, I use the last one.

Comment 78

3 years ago
@Arthur and others who work/worked on patches: would you mind posting your compiled binaries of firefox with your patches applied?

Given that you have fairly up-to-date patches, I assume you also have binaries. It would be very much appreciated if you shared them whenever you update your patch -- no website is required, you can just use Dropbox/OneDrive/etc with a public link posted here.

@Grigory: I'm pretty frustrated too (it would be inexcusable if it wasn't free). I use a system wide proxy with an application filter, but that fails on DNS requests and has other issues.

I can't say it's pathetic, but reading this thread it does make one wonder ...
Created attachment 8525888 [details] [diff] [review]
0001-Bug-122752-Allow-setting-username-and-password-for-S.patch

I've updated the attachment, making it simpler. Also built and tested: https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=3770975d81ce
Attachment #8505061 - Attachment is obsolete: true
Attachment #8505061 - Flags: review?(michal.novotny)
Attachment #8525888 - Flags: review?(michal.novotny)
Comment on attachment 8525888 [details] [diff] [review]
0001-Bug-122752-Allow-setting-username-and-password-for-S.patch

Review of attachment 8525888 [details] [diff] [review]:
-----------------------------------------------------------------

(In reply to Arthur Edelstein from comment #71)
> The global username+password in preferences is not actually needed for the
> Tor Browser feature described above. I will remove this part of the patch.

But without some username/password management is this code usable only for the tor browser. And this is not the goal of this bug. The patch IMO cannot be accepted without this functionality.


> > We should offer both methods and let server to decide which one we must use.
> 
> On further thought, it seems to me that it's better not to fall back to an
> unauthenticated connection if we are expecting to supply a username and
> password. So I would suggest that the client (Firefox) should only offer one
> method, either authenticated (with u+p) or unauthenticated (without) but not
> both.

Again, you're trying to address only a specific case needed by the tor browser. Normally, we don't know whether the proxy requires authentication when we use it for the first time. So we must offer both methods and prompt the user for the credentials if needed.
Attachment #8525888 - Flags: review?(michal.novotny) → review-

Comment 81

2 years ago
Honestly, guys, the more I read the updates in this almost 13 (THIRTEEN) bloody years old feature, seeing you going back and forth among yourselves over what use case is best (ANY is better than No u/p auth!), especially with working patches already available, the more I feel that someone should convince you to just implement the existing patch already, and allow user feedback to dictate what you should do, rather than keep making endless assumptions about what users want and/or what's better for them...

It's been 13 years already. Christ, SOCKS may become obsolote, or I may be dead, or telepathic headsets may become available by the time you think you have right! Seriously, I think this reached a bizarre point, someone should give it a kick ...

So why not push it in nightly, allow for some feedback, then in beta, allow for more user feedback, then in stable, allow for a lot more user feedback, then polish and be done with it ... ?

Users will virtually never compile to try and provide feedback, but will gladly try binaries if they are available.
Created attachment 8545398 [details] [diff] [review]
0001-Bug-122752-Allow-setting-username-and-password-for-S.patch

(Posting a new version of the patch with a minor bug fix, for the record. Review not needed at this point.)
Attachment #8525888 - Attachment is obsolete: true
Whiteboard: [tor]
Flags: needinfo?(sworkman)
Attachment #697715 - Flags: review?(cbiesinger)
Depends on: 1200802

Comment 83

2 years ago
I won't work on this anymore. Feel free to adopt my patch, IF you can get it into the tree.
Assignee: ben.bucksch → nobody

Comment 84

2 years ago
Just a comment re GSSAPI.  We implemented it in WinGate SOCKS server about 5 years back.  Also the OpenText SOCKS client supports it (which we used for testing).  So presumably there are other SOCKS servers that support it as well.

Comment 85

a year ago
It's been nearly 14 years now. Please fix/implement this.

Comment 86

a year ago
Welcome in 2016! ;]

I wonder what forces are blocking this  primary and easy to implement (I think so) feature?
Duplicate of this bug: 200882
Whiteboard: [tor] → [tor][necko-backlog]

Comment 88

a year ago
This bug just keeps on giving since I reported it 13 years ago (duplicate). Sometimes it goes dormant for a few months/years, then it strings back to life and makes my day. Thanks for the years of entertainment!

Comment 89

a year ago
Well, Bug 1200802 (https://bugzilla.mozilla.org/show_bug.cgi?id=1200802) is resolved in Firefox 45, released today; so perhaps you won't have to wait 14 years for a fix finally!

(Can't wait to stop using Maxathon Browser myself, its really terrible)

Comment 90

a year ago
I just tried Firefox 45.  It does not support authentication for SOCKS5 - there is no option to enter username/password, nor does any dialog box pop up to prompt you for the username/password - or am I missing something?

Where do you enter the SOCKS5 username/password on FF 45?
Flags: needinfo?(sworkman)

Comment 91

a year ago
(In reply to alpha3 from comment #90)
> I just tried Firefox 45.  It does not support authentication for SOCKS5 -
> there is no option to enter username/password, nor does any dialog box pop
> up to prompt you for the username/password - or am I missing something?
> 
> Where do you enter the SOCKS5 username/password on FF 45?

You don't. There's no user interface to enter that information. However, I'll be adding support for this into the FoxyProxy extension soon.

Comment 92

11 months ago
(In reply to Eric H. Jung from comment #91)

Hi Eric, 

OK great - any idea when the next version of FoxyProxy will be out?

Cheers
alpha3

Updated

9 months ago
Priority: -- → P3
Whiteboard: [tor][necko-backlog] → [tor][necko-backlog][proxy]
Comment on attachment 8545398 [details] [diff] [review]
0001-Bug-122752-Allow-setting-username-and-password-for-S.patch

Making this patch obsolete, as nearly all of it landed in bug 1200802.
Attachment #8545398 - Attachment is obsolete: true
Whiteboard: [tor][necko-backlog][proxy] → [necko-backlog][proxy]

Comment 94

4 months ago
anyone can shed some light on this? as of this time, there seems to be no clear way to securely connect to proxy in firefox either via http or socks and i believe it's been 15 years since the bug was opened
you can connect to a proxy via HTTPS by returning the HTTPS method from a pac script. firefox will validate the proxy cert and name.

Comment 96

4 months ago
i could also do ssh tunnel to server  with port forwarding, but that's kind of hack same as cert and pac script. users shouldn't self-sign or go through tedious path of obtaining a cert.
about:config solution from bug 1200802 seemed like a nice and clean way, but it got butchered.

i'm sorry if that sounds annoying but i only know basic C and figuring out firefox source code in order to implement secure proxy auth will take me same time it took to not fix this bug, so i pray you guys will fix it some time soon

meanwhile my user:passwords travel across hostile networks in clear text, the kgb is knocking at my door, the end is near

Comment 97

3 months ago
Authentication with SOCKS is now natively supported in the FoxyProxy addon. Be sure you are using FoxyProxy Standard 4.6.1 or FoxyProxy Basic 3.6.1 (or higher). They are submitted to AMO and awaiting approval, so they won't be available possibly for another 24 hours or so.

(In reply to Patrick McManus [:mcmanus] from comment #95)
> you can connect to a proxy via HTTPS by returning the HTTPS method from a
> pac script. firefox will validate the proxy cert and name.

This is now supported natively in the FoxyProxy addon. No PAC required. See screenshot here: http://i.imgur.com/TGIEk8c.jpg

If the proxy server's certificate is not valid, you are prompted to accept the certificate into the Fx store.

Comment 98

3 months ago
Thank you Eric and all at FoxyProxy.

I just installed this plugin last night and all is working great.

After 15 years (-10 days) we finally have working Socks5 Authentication in a mainstream browser.

Comment 99

a month ago
(In reply to Ronan Crowley from comment #98)
> Thank you Eric and all at FoxyProxy.
> 
> I just installed this plugin last night and all is working great.
> 
> After 15 years (-10 days) we finally have working Socks5 Authentication in a
> mainstream browser.

Sad to say it, but unless we can get FoxyProxy ported to the new WebExtensions system before November 2017, you'll lose this functionality. Even then, it's not clear to me that SOCKS5 authentication is supported in the new system (bug #1295807. See also bug #1319641)

Comment 100

a month ago
(In reply to Eric H. Jung from comment #99)
> (In reply to Ronan Crowley from comment #98)
> > Thank you Eric and all at FoxyProxy.
> > 
> > I just installed this plugin last night and all is working great.
> > 
> > After 15 years (-10 days) we finally have working Socks5 Authentication in a
> > mainstream browser.
> 
> Sad to say it, but unless we can get FoxyProxy ported to the new
> WebExtensions system before November 2017, you'll lose this functionality.
> Even then, it's not clear to me that SOCKS5 authentication is supported in
> the new system (bug #1295807. See also bug #1319641)

That would be terrible. Been using this daily with Socks5 proxy since I read you're comment announcing it here :(
You need to log in before you can comment on or make changes to this bug.