122752 - SOCKS: Username/Password Authentication (V5)

Status: NEW

(Core :: Networking: Proxy, defect, P3)

Description

[Ivan Dolezal]

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

[Philip White]

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.

Comment 2

[Philip White]

Changed severity too, since this is more of a bug rather than a request for 
enhancement.

Comment 3

[benc]

-> 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.

Comment 4

[Boris 'pi' Piwinger]

What is the status of this bug?

pi

Comment 5

[Boris 'pi' Piwinger]

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

pi

Comment 6

[benc]

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.

Comment 7

[Patrick Tou]

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

[benc]

NEW, nsbeta1. End users need error messages.

Comment 9

[Samir Gehani]

adt: nsbeta1-

Comment 10

[Patrick Tou]

Confirm again. Freshly downloaded Mozilla still exhibits problem.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507

Comment 11

[Matthias Versen [:Matti]]

*** Bug 216316 has been marked as a duplicate of this bug. ***

Comment 12

[benc]

-> defaults.

Comment 13

[Scott MacGregor]

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

Comment 14

[Chris Horry]

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

[benc]

-> defaults again.

Comment 16

[benc]

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

Comment 17

[Malcolm Smith]

(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

[Darin Fisher]

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

[Darin Fisher]

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 :-(

Comment 20

[Christian :Biesinger (don't email me, ping me on IRC)]

it is unfortunate that the SOCKS code does not have a channel available off
which it could get the auth prompt...

Comment 21

[Darin Fisher]

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

Comment 22

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 23

[Jo Hermans]

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

Comment 24

[Tim Weeks]

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

Comment 25

[Jian ZHOU]

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

Comment 26

[Malcolm Smith]

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...

Comment 27

[Christian :Biesinger (don't email me, ping me on IRC)]

(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

[Jian ZHOU]

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

Comment 29

[Christian :Biesinger (don't email me, ping me on IRC)]

(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.

Comment 32

[HM2K]

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

[Chris Horry]

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

[Patrick Strateman]

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

[HM2K]

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

Something better can be done later.

Comment 36

[Patrick Strateman]

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

[Patrick Strateman]

Attachment: 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.

Comment 38

[Christian :Biesinger (don't email me, ping me on IRC)]

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)

Comment 39

[Christian :Biesinger (don't email me, ping me on IRC)]

The other option is to get an nsIAuthPrompt via NS_DEFAULTAUTHPROMPT_CONTRACTID, but that is a less ideal solution.

Comment 40

[HM2K]

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.

Comment 42

[Sk]

any news up on this?

Comment 44

[Vitaliy]

please fix this issue, it's very important

Comment 45

[Chris B.]

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

[Malcolm Smith]

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

[Chris B.]

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

[HM2K]

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

[Grigory Ivanov]

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

[Grigory Ivanov]

Patch for FF17: http://ololo.cc/files/socks5_auth_ff17.diff

Comment 51

[Josh Matthews [:jdm]]

Attachment: 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.

Comment 52

[Masatoshi Kimura [:emk]]

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

[karl155]

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

[Grigory Ivanov]

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

[Chris B.]

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

[Malcolm Smith]

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

[Grigory Ivanov]

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

[karl155]

I agree to Grigory, if I save a bookmark in the form http://user:[e-mail]/ 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 59

[Christian :Biesinger (don't email me, ping me on IRC)]

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.

Comment 60

[karl155]

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

[Ben Bucksch (:BenB)]

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.

Comment 62

[Ben Bucksch (:BenB)]

Attachment: Alternate Patch, allowing set auth per connection per API - v8

Patch is against current Firefox trunk

Comment 63

[Ben Bucksch (:BenB)]

https://trac.torproject.org/projects/tor/ticket/6733

Comment 64

[Ben Bucksch (:BenB)]

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

[Ben Bucksch (:BenB)]

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.

Comment 66

[Arthur Edelstein [:arthur]]

Attachment: 0001-Bug-122752-Allow-setting-username-and-password-for-S.patch

Here's a modified and updated version of :BenB's patch.

Comment 67

[Arthur Edelstein [:arthur]]

Attachment: 0001-Bug-122752-Allow-setting-username-and-password-for-S.patch

Minor fix to patch

Comment 68

[Patrick McManus [:mcmanus]]

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 69

[Jason Duell]

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.

Comment 70

[Michal Novotny [:michal]]

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.

Comment 71

[Arthur Edelstein [:arthur]]

(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.

Comment 72

[Arthur Edelstein [:arthur]]

(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

Comment 73

[Arthur Edelstein [:arthur]]

Attachment: 0001-Bug-122752-Allow-setting-username-and-password-for-S.patch

Comment 74

[Mast]

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

[Grigory Ivanov]

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

[Mast]

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

[Grigory Ivanov]

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

[Mast]

@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 ...

Comment 79

[Arthur Edelstein [:arthur]]

Attachment: 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

Comment 80

[Michal Novotny [:michal]]

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.

Comment 81

[Mast]

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.

Comment 82

[Arthur Edelstein [:arthur]]

Attachment: 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.)

Comment 83

[Ben Bucksch (:BenB)]

I won't work on this anymore. Feel free to adopt my patch, IF you can get it into the tree.

Comment 84

[Adrien de Croy]

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

[Frank Müller]

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

Comment 86

[Anna]

Welcome in 2016! ;]

I wonder what forces are blocking this  primary and easy to implement (I think so) feature?

Comment 88

[Laurent Birtz]

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

[Ronan Crowley]

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

[alpha3]

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?

Comment 91

[Eric Jung [:ericjung]]

(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

[alpha3]

(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

Comment 93

[Arthur Edelstein [:arthur]]

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.

Comment 94

[shagydog]

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

Comment 95

[Patrick McManus [:mcmanus]]

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

[shagydog]

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

[Eric Jung [:ericjung]]

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

[Ronan Crowley]

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

[Eric Jung [:ericjung]]

(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

[Kai]

(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 :(

Comment 101

[toastal]

> Due to Firefox limitations, username/password authentication is not available with SOCKS proxy servers

FoxyProxy just rolled out their new WebExtension version. It does not support Socks5 with authentication. I'm not really sure what I can do to work around this now.

Comment 102

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 103

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 104

[Damon]

Firefox 57 is out, FoxyProxy cannot support authentication with current API in Firefox unless they implement a 3rd party program which operates out of Firefox and acts as a middle man for proxy authentication.

It's been 16 years, isn't it time we give this a little bit more importance? Anything would work, a setting in `about:config` maybe, would be easiest to implement I think.

Comment 105

[Ben Bucksch (:BenB)]

Given that most of the patch here landed in bug 1200802, all the hard work is done. All that's needed is something that reads a pref and uses it. My patch here had it (search for mSOCKSProxyUsername in attachment 697715 [details] [diff] [review]), but that part was subsequently removed. It would have to be re-added in a slightly different way, but this shouldn't be hard. Anybody, feel free to step ahead.

Comment 106

[Eric Jung [:ericjung]]

> Firefox 57 is out, FoxyProxy cannot support authentication with current API in Firefox

The only recent version which did support it is 6.0. It does support it as of 6.1 and above. The socks auth code is exposed by the WebExtensions proxyAPI.

Comment 107

[Damon]

Kudos Eric! Thanks for adding in the authentication option back into FoxyProxy! How did I miss the "PAC file specification" section on the WebExtensions proxy API? https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/proxy

Now we at least have a way to authenticate with SOCKS using WebExtensions...

Comment 108

[arjunvkp]

How is it that firefox (and chrome) is still missing out on this?
Considering the general consensus to push for privacy features, this one seems to be the worst of all tasks left in to-do!

Comment 109

[enm]

Please add this as a built-in feature. It really shouldn't require installing an extension. :-(

Comment 110

[rag.web]

A wireguard question brought me here.

Maxthon browser has this option working... I connect to my WindScribe VPN account that also provides socks5 with user/password.
This gives me additional IP to separate some "Other" traffic. I use a portable version for like 4 years now.

Comment 111

[WfJjrdAr]

To make sure that the problem of using SOCKS v5 with authorization in Mozilla Firefox still exists, I tried to connect to one by specifying it in the settings (https://drive.google.com/file/d/1hQ4ovVFNoveXRGqXwy8ZxStGpYlXQeX8/view). Then I tried to open google.com, expecting to see a dialog box asking me to enter my proxy username and password. However, I just saw the error page:

Unable to connect
An error occurred during a connection to www.google.com.
• The site could be temporarily unavailable or too busy. Try again in a few moments.
• If you are unable to load any pages, check your computer's network connection.
• If your computer or network is protected by a firewall or proxy, make sure that Firefox is permitted to access the Web.

Mozilla Firefox 98.0 (64-bit)

Comment 112

[artenax]

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

Opera 12 supports SOCKS authorization. But login and password are set in opera:config

Comment 113

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S4. However, the bug has 7 duplicates, 42 votes and 60 CCs.
:kershaw, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 114

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 115

[ahmet.deliktas]

I had to reinstall my dante proxy server and enabled auth for it. Now i discover that firefox doesn't support auth ... There is no auth popup after applying ip and port on socks5.
I don't see how this is a big issue and honestly should have a higher priority.
Also it's a 21 years old bug yikes.

Comment 116

[ahmet.deliktas]

firefox-110.0.1 64-bit on linux

Comment 117

[Eric Jung]

@ahmet you can use the FoxyProxy browser extension to get SOCKS5 support with authentication.

Comment 118

[ahmet.deliktas]

(In reply to Eric Jung from comment #117)

@ahmet you can use the FoxyProxy browser extension to get SOCKS5 support with authentication.

Thanks for the reply. I know that, but i don't see how/why this auth option isn't part of the default firefox proxy settings menu.
There are also some patches attached, which i haven't read yet and are probably outdated by now.
When im modding/patching something the next time in firefox i'll take a in-depth look at this and reply again.

Comment 119

[5n00p4eg]

What a surprise for me. In my case, I have a selenium setup where I need to pass a proxy per session. I'm using preferences to set the proxy, so even UI isn't necessary for me.

Installing & configuring extensions from the Selenium web driver will be too complex.

Comment 120

[youlold]

Still awaiting

Comment 121

[Randell Jesup [:jesup] (needinfo me)]

Last I checked, neither we nor chrome support SOCKS v5 with auth. It still would require a fair bit of work to hook up a UI for this. You can also see comment 95 by McManus.

Comment 122

[BMO Automation]

Moving bug to Core/Networking: Proxy.