New issue
Advanced search Search tips
Starred by 48 users

Issue metadata

Status: Archived
Owner: ----
Closed: Nov 2015
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Feature

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

SOCKS5 authentication support

Reported by, Jul 2 2013

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.110 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Launch chromium from the command line with proxy specifications
2. chromium --proxy-server="socks5://foobar:66" --proxy-auth="user:pass"
3. Pages won't load

What is the expected behavior?
Chromium will successfully connect to the proxy and browse the web through the proxy.

What went wrong?
SOCKS5 authentication support appears to be unimplemented. 

Did this work before? No 

Chrome version: 27.0.1453.110  Channel: stable
OS Version: debian testing
Flash Version: disabled

Comment 1 by, Jul 10 2013

Labels: -Cr-Internals-Network -Type-Bug -OS-Linux Cr-Internals-Network-Proxy Type-Feature OS-All

Comment 2 by, Jul 10 2013

Status: Available
Correct: socks5 proxy auth is not implemented.

Also note that --proxy-auth= is not a valid flag.

Does this work for you on other browsers? As I recall Firefox doesn't implement it either.
Firefox does not support this, although there has been a patch proposed. The relevant bug is:

Rekonq, Konqueror and KDE in general does not support SOCKS5 authentication. GNOME also doesn't support socks5 autnetication, as shown in 

Arora and many non-browser QT-based apps do support it, as do multiple GTK apps. The lack of secure proxy mechanisms is frustrating.

Comment 4 by Deleted ...@, Sep 15 2013

Maxthon supports SOCKS5 authentication (
Are there any updates on this?
It'd be nice if *one* of the major browsers would finally get around to exposing this.

Comment 7 by Deleted ...@, Apr 17 2015

Yeah this is ridiculous, SOCKS5 is not new or anything, PLEASE ADD THIS NOW.
Chromium, you refuse to implement APNG. Maybe you want people to use WebP/M and that's okay. What's the reason behind this? Are we dumb for wanting to use SOCKSv5? Is there a better alternative coming so it's unnecessary to spend time implementing this? What?

For people who want to use an authenticated SOCKS server with Chrome, a neat trick is to terminate the security using a SOCKS client/server combo on your end.

Comment 9 by, Nov 16 2015

Status: Archived
Going to go ahead and archive this bug.  Sorry guys, this bug is not on anyone's radar, and this is very unlikely to happen, given the fairly low usage of authenticating SOCKS5 proxies.
I think what you mean is that it isn't on any Chromium developer's radar. It's obviously on the radar of the people who have starred it as important to them. I'm disappointed, but will look for other options. Thanks for the honest update.
Indeed, that's exactly what I meant.
Please reopen this!!!

It is almost 2017 and the only browser (that I know of) that supports socks5 authentication is some scammy Chinese browser called Maxthon which has been caught stealing peoples personal info. >>>

Please reopen this issue and finally implement Socks v5 authentication already!

Comment 13 by, Sep 22 2016

I agree this needs to be implemented, it's ridiculous it's not done already holy shit. 
FF is adding this support [] and author of FoxyProxy will provide a user interface to enter username/password.
Why would you comment in an archived post to mention that a DIFFERENT BROWSER has some feature? This is why I can't ever follow these things.

Comment 16 by, Dec 14 2016

2017 is going to be the year of the VPN, where VPNs and proxies see unprecedented usage as governments around the world start trying to de-anonymize and regulate the content of the internet, and net neutrality comes ever closer to being eliminated.

Maybe FireFox adding this feature will bring the attention to it that it deserves, since authenticated proxies have exploded in popularity over the last 2 years when this was deemed a non-issue.

Comment 17 by, Mar 29 2017

I completely agree that this should be implemented, however you should know that password is sent in clear text and I think the data as well, so it's not helping much against governments.

Comment 18 by, Sep 27 2017

This should definitely be implemented. At this day and age proxies (or VPNs) are a must have. A socks5 proxy server is particularly easy to set up, if only Chrome would support it.
I vote for protected socks proxy server support in chrome.* web extensions API — let us know if we should create a separate ticket for chrome.* API support. user:password@host:port format in PAC-scripts is also desired.
Dear god, I need this functionality so much :( please implement it

Comment 21 by, Oct 31 2017

2017 is coming to an end, 6 years after the issue was opened, doesn't even seem to be acknowledged. 

Comment 22 by, Oct 31 2017

It's acknowledged in #9, and deemed not a priority to fix given how rare *authenticating* SOCKS5 proxies are. 
We need SOCKS5 authentication support. When you will add it?????
Firefox already added this 
Just a brief example of a usecase for this thing. I want to have my own proxy to be able to access stuff which is blocked by my government. What I don't want is to make this proxy public (is such case it will be overloaded, or blocked, or whatever can happen to the person who runs a public proxy in a country with government which bans stuff on the internet). So a logical solution - make this proxy authenticated.
What is being asked in this bug thread is username/password authentication (RFC 1929).

This sends the user/name password in the clear and offers no integrity or confidentiality. It is pointless from a security perspective when speaking to a non-local proxy server, since your password, and all the sites that you connect to, are sent in the clear.

If you actually want to protect traffic in the desired manner, better options are:
  - use a VPN
  - use an HTTPS proxy
  - use a SOCKS proxy running over a secure channel

In the case of SOCKS over a secure channel, a commonly used option is "ssh -D", which creates a local proxy server whose traffic is sent over SSH. You handle authentication via the SSH client.

Since RFC 1929 offers no security for non-local SOCKS proxy servers, one is constrained to talking to a local proxy server regardless.

Sign in to add a comment