Open Bug 122752 Opened 23 years ago Updated 6 months ago

SOCKS: Username/Password Authentication (V5)

Categories

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

Product:
Core
Component:
Networking: Proxy
Type:
defect

Tracking

()

People

(Reporter: ivan.dolezal, Unassigned)

References

(Blocks 1 open bug)

Details

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

Attachments

(3 files, 5 obsolete files)

Patch to give ConnectSOCKS5 function support for u/p authentication
5.69 KB, patch
Biesinger
: review-
Details | Diff | Splinter Review
Patch
4.61 KB, patch
Biesinger
: review-
Details | Diff | Splinter Review
Alternate Patch, allowing set auth per connection per API - v8
56.44 KB, patch
Details | Diff | Splinter Review
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
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
Closed: 23 years ago
Resolution: --- → WORKSFORME
Changed severity too, since this is more of a bug rather than a request for enhancement.
URL: ftp://... anything from our firm's in...
Severity: enhancement → minor
-> 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
What is the status of this bug? pi
Let's rest this bug in peace until someone can give a clear way to see the problem. pi
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME
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 → ---
Blocks: 200882
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).
NEW, nsbeta1. End users need error messages.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: nsbeta1
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
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. ***
-> defaults.
Keywords: nsbeta1-
Blocks: 225485
*** Bug 225485 has been marked as a duplicate of this bug. ***
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
-> defaults again.
Assignee: neeti → darin
Worse, once you have pointed to a socks server that does not work, you cannot switch socks servers, see bug 233811.
(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.
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).
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...
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.
*** Bug 257522 has been marked as a duplicate of this bug. ***
QA Contact: socksqa → benc
Blocks: 257522
Why is it taking so long to fix this simple problem?
*** Bug 285562 has been marked as a duplicate of this bug. ***
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...
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.
Assignee: darin → nobody
QA Contact: benc → networking
Target Milestone: Future → ---
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.
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.
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]));
For now, can't you just add some settings into about:config, pull it from there... Something better can be done later.
HM2K: I have no idea how to access the about:config preferences, that seems like it is the best way to do it however
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.
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.
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.
any news up on this?
please fix this issue, it's very important
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.
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.
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.
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.
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).
Attached patch Patch — — Splinter Review
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.
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.
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.
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.
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.
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.
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-
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.
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
Patch is against current Firefox trunk
Attachment #697715 - Flags: review?(cbiesinger)
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).
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.
Here's a modified and updated version of :BenB's patch.
Attachment #8496337 - Flags: review?(jduell.mcbugs)
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
Attachment #8496443 - Attachment is obsolete: true
Attachment #8505061 - Flags: review?(michal.novotny)
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?
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.
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.
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.
@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 ...
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-
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.
(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)
Depends on: 1200802
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
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.
It's been nearly 14 years now. Please fix/implement this.
Welcome in 2016! ;] I wonder what forces are blocking this primary and easy to implement (I think so) feature?
Whiteboard: [tor] → [tor][necko-backlog]
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!
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)
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)
(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.
(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
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]
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.
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
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.
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.
(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)
(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 :(
> 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.
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P3 → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
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.
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.
> 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.
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...
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!

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

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.

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)

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

Severity: minor → S4

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.

Flags: needinfo?(kershaw)

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.

Flags: needinfo?(kershaw)

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.

firefox-110.0.1 64-bit on linux

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

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

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.

Still awaiting

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.

Moving bug to Core/Networking: Proxy.

Component: Networking → Networking: Proxy
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: