Implementing SOCKS5 authentication via credentials in URL

[Adam Rice]

A very kind external contributor has provided a CL to implement authentication for SOCKS5, which is a long-standing and popular request.

My one concern is that it works differently from HTTP proxies. Instead of the user being prompted for a username and password, it is included in the proxy URL, ie.

socks5://user:pass@foopy

We can clean up the code to make it clear in the code that this format is only intended to work for socks5, but is there a security reason not to do it this way?

The CL is here: https://chromium-review.googlesource.com/c/chromium/src/+/5952488

[Matt Menke]

So, potential concerns that occur to me.  Note that I'm not coming out against it, just brainstorming issues to consider, I don't have particularly strong feelings about this, either way:

1)  Lack of encryption.  These passwords are sent in plain text.  This is the main reason we've focused on HTTP proxies rather than socks ones in the first place, HTTP proxy code also applies to HTTPS proxies, so at least there's a secure option, even though we don't actually require it.  Of course, we still do allow HTTP authentication over insecure channels, though with a prompt, we can at least make clear it will be sent in the clear in advance, though no idea how clear we currently make it.

2)  Lack of configuration compatibility.  When we get servers to connect to from PAC scripts or system configuration, if we support user/passwords in socks5, and other consumers of the same source of information do not, we'll behave differently.  This does not apply when the configuration comes from a chrome-only source (e.g., group policy or extensions - yes, other browsers have adopted Chrome extension APIs, but they're not something where we've historically cared about cross-browser support).  Also, on platforms where we let the OS run the PAC script (do we do this anywhere?  I think we have an option to on Windows, at least), we'd potentially behave differently if the OS PAC script logic rejects such proxy URLs.  A prompt-base approach would at least mean other socks5 consumers could successfully connect to a socks5 server, though if they get an auth challenge and don't have credentials, they won't be able to actually use the server.

3)  User tracking.  Unique passwords can be used to track individual users invisibly, particularly if the proxy configuration comes from a setting they may not be aware of. Of course, so can IP address in many cases, and so can unique proxy hostnames, so this seems likely not a huge issue.  Showing a password prompt instead would fully address this.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAC_ixdxyRJebYQLWOKys0ha0WpqK%2B8h_s5DPL1C0a5%3DjmCgWaQ%40mail.gmail.com.

[Adam Rice]

On Thu, 24 Oct 2024 at 23:32, Matt Menke <mme...@chromium.org> wrote:

1)  Lack of encryption.  These passwords are sent in plain text.  This is the main reason we've focused on HTTP proxies rather than socks ones in the first place, HTTP proxy code also applies to HTTPS proxies, so at least there's a secure option, even though we don't actually require it.  Of course, we still do allow HTTP authentication over insecure channels, though with a prompt, we can at least make clear it will be sent in the clear in advance, though no idea how clear we currently make it.

This doesn't bother me much, because I don't think people have a high expectation of security from SOCKS5 to begin with. The credentials just raise the bar for abuse a bit.

 

2)  Lack of configuration compatibility.  When we get servers to connect to from PAC scripts or system configuration, if we support user/passwords in socks5, and other consumers of the same source of information do not, we'll behave differently. 

This is a good point. ChromeOS tries to share the proxy configuration between the ChromeOS side and the Android side, and already has problems with Android not understanding data: PAC URLs.

I'm less worried about use in PAC scripts, because anyone who puts a password in a PAC script clearly enjoys living on the edge to begin with.

Also, on platforms where we let the OS run the PAC script (do we do this anywhere?  I think we have an option to on Windows, at least)

The command-line option still exists, but we don't appear to expose an enterprise policy for it.

 

, we'd potentially behave differently if the OS PAC script logic rejects such proxy URLs. 

My impression is that Edge uses it to provide backwards compatibility in enterprise environments, and maybe there's a handful of enterprises using it in Chrome. The overlap with people who will use this feature is probably zero.

3)  User tracking.  Unique passwords can be used to track individual users invisibly, particularly if the proxy configuration comes from a setting they may not be aware of. Of course, so can IP address in many cases, and so can unique proxy hostnames, so this seems likely not a huge issue.  Showing a password prompt instead would fully address this.

Anyone who controls enterprise policies or otherwise controls the configuration of the browser can already track users in dozens of ways. Having to enter their username & password would make it more obvious to the user, but also more annoying.

It is apparently possible for an extension to automatically provide proxy credentials via the webRequest API, although I haven't yet found one that works with Manifest v3. But that would provide a way out for people who are annoyed by the auth prompt.

Getting SOCKS5ClientSocket::Connect to return ERR_PROXY_AUTH_REQUESTED if it needs credentials and doesn't have them looks straightforward, but plumbing that back so that eventually URLRequest::Delegate::OnAuthRequired is called correctly could be tricky.

 

[David Benjamin]

What's the reason for embedding the credentials in the proxy URL instead of prompting? Other than the things Matt mentions, it seems bizarre to me that we'd make SOCKS5 and HTTP credentials behave differently. And it means we now have to worry about both paths here. Even if we believe both paths are okay, it's twice as many things and an odd inconsistency.

[Matt Menke]

On Thu, Oct 24, 2024 at 1:10 PM Adam Rice <ri...@chromium.org> wrote:

On Thu, 24 Oct 2024 at 23:32, Matt Menke <mme...@chromium.org> wrote:

3)  User tracking.  Unique passwords can be used to track individual users invisibly, particularly if the proxy configuration comes from a setting they may not be aware of. Of course, so can IP address in many cases, and so can unique proxy hostnames, so this seems likely not a huge issue.  Showing a password prompt instead would fully address this.

Anyone who controls enterprise policies or otherwise controls the configuration of the browser can already track users in dozens of ways. Having to enter their username & password would make it more obvious to the user, but also more annoying.

It's not Enterprise-configured proxies where I think this might be a concern.