using proxy for non-http traffic

[Guo-wei Shieh]

Hi,

From the code, chrome's "--proxy-server" only affects http and https.

I have 2 questions.

1. What about tcp connection? Does "--proxy-server" affect that?

2. Is there any mechanism for chrome to use proxy with UDP protocol?

Thanks,

Guowei

[Ryan Sleevi]

On Wed, Jun 17, 2015 at 10:43 AM, Guo-wei Shieh <guo...@chromium.org> wrote:

Hi,

From the code, chrome's "--proxy-server" only affects http and https.

I have 2 questions.

1. What about tcp connection? Does "--proxy-server" affect that?

Strictly speaking, no, but it can be used (the HTTP CONNECT method takes the 'authority' portion of a generic URL, per RFC 7231 - http://tools.ietf.org/html/rfc7231#section-4.3.6 )

Different components may use the proxy or not, but it's fairly complex there.

 

2. Is there any mechanism for chrome to use proxy with UDP protocol?

Strictly speaking, a SOCKSv5 proxy can be used for UDP. However, this is not supported by Chrome (nor reliably supported by most SOCKSv5 proxies) 

[Guo-wei Shieh]

Is there any design doc describing how chrome handles proxy? i.e. where it decides to route a connection through proxy or not?

--
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 post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CACvaWvbeynhU2vU3Z4Xf-LFgkwr1iToHiA1SVk74GfvYRsMsTw%40mail.gmail.com.

[Eric Roman]

On Wed, Jun 24, 2015 at 9:52 AM, Guo-wei Shieh <guo...@chromium.org> wrote:

Is there any design doc describing how chrome handles proxy?

Search for "proxy" from https://www.chromium.org/developers/design-documents/network-stack to read up more.

 

i.e. where it decides to route a connection through proxy or not?

There isn't a single document that will rationally explain this for you, because there isn't a single "proxy settings" concept in Chrome.

To get you started exploring how proxy decisions are made, consider some of these factors

• The "component" which issued the network traffic
  
• TCP/UDP traffic generated for DNS resolution will not respect per-profile HTTP proxies, nor SOCKS v5 proxies. In theory it is possible to proxy this traffic, but in practice this traffic is done by the system library (i.e. getaddrinfo()) and does its own thing.
• Plugins and WebRTC can do their own thing and not consider any Chrome per-profile proxies.
• Similarly Chrome extensions might be using the chrome.sockets API and not using any per-profile proxies
• Things like safe browsing requests, OCSP requests, certificate CRL fetches, pre-fetch / pre-render requests, etc, although HTTP, may go through alternate proxy settings or none at all.
• The protocol affects how proxies work too
• System settings and PAC scripts can obviously stipulate different proxies for different URL schemes (i.e. a proxy for http://* vs https://* vs ftp://*), however there are also subtleties in how non-HTTP schemes use an HTTP proxy.
• FTP proxy support in Chrome is incomplete and doesn't route traffic through a SOCKS. When using an HTTP or HTTPS proxy with FTP it will issue an HTTP request. You might have otherwise expected it to do a CONNECT and then talk FTP, but that isn't how it currently works.
• WebSockets has its own interpretation of proxy
• Different Chrome profiles can have different proxy settings (incognito, different profiles, etc). Moreover the proxy settings per profile can be influenced by:
• Chrome extensions - yes they can change proxy settings
• Group policy settings
• Command line flags
• Environment variables
• "System Proxy settings"
• "System proxy settings" means a variety of things and there isn't necessarily a single concept for this either.
• Different network interfaces can have different settings
• The meaning on ChromeOS is also different
• System settings can have proxy overrides by host name, or IP block ranges. The way these are specified and applied is also different per platform.
• Different providers of "system proxy settings" on each platform. For instance winhttp vs wininet vs 32-bit registry hive vs 64-bit on Windows. KDE vs Gnome vs environment variables, vs different versions of KDE and gnome settings on Linux.
• Proxy settings are dynamic
• When specified via a PAC script the proxy selection is not necessarily predictable or deterministic
• PAC scripts can change (and will be re-polled by Chrome)
• Individual proxy servers may be unreachable, however PAC scripts can return a list of fallback options. Chrome maintains a cache of "bad" proxy servers, which will influence which of the possible proxy servers will be used
• Chrome's Bandwidth reducing proxy will also influence how the proxy is selected. When enabled it currently functions as a fallback. So if you indicated to connect directly, it may instead send it through the BRP.

It is worth throwing this up into a document even if incomplete. Maybe https://code.google.com/p/chromium/issues/detail?id=472705 is the right place to tackle this. There is unfortunately a lot of configurability that makes it hard to reason about what proxies are used, and even more may be appearing in the future.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CABM%3Dn%2B3_6VBWCyh4hkHMfo9zUoM%2Br5Lq-a%2BMKahxdqNRBLZKcg%40mail.gmail.com.

[Guo-wei Shieh]

One more question. Is there any way to know a priori, given a remote server,  if a proxy is going to be used? Or the only way is to really use it as int ProxyService::ResolveProxy?

Also, I assume the decision of which proxy is going to be cached if proxy setting is not changed in anyway, correct?

Thanks,

Guowei

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAFswn4%3DogRX4moHOHcJvqKmwb0XxuUGtPbOyG%3DB%2B_%2BwuG1SCww%40mail.gmail.com.

[Eric Roman]

On Fri, Jun 26, 2015 at 1:16 PM, Guo-wei Shieh <guo...@chromium.org> wrote:

One more question. Is there any way to know a priori, given a remote server,  if a proxy is going to be used? Or the only way is to really use it as int ProxyService::ResolveProxy?

Correct, you have to call ProxyService::ResolveProxy() and wait for the asynchronous result.

Also, I assume the decision of which proxy is going to be cached if proxy setting is not changed in anyway, correct?

False. 

When proxy settings are configured via a PAC script, a javascript program is run over the URL to decide what proxies to use (if any). The explicit input to this program is the URL, however it can also have dependencies on the time, DNS resolutions, randomness, global state from other requests, etc.

So consecutive calls to ResolveProxy() for the same input can yield different outputs even when the proxy settings have not changed.

Also a network change could happen between calls to ResolveProxy(), causing proxy auto-discovery to run anew and discover a completely different script. Or the PAC script itself could change. Basically you can't guarantee anything about the results.

Even if the settings don't use proxy auto-discovery or PAC, the results can still change. For instance proxies that failed recently are de-prioritized, so depending how much time has elapsed you could get a different ordering of proxies to try.

[Guo-wei Shieh]

Thanks. My goal was to use the presence of proxy.  if there is, we'll not use UDP as it's not routed hence causing IP leak. And as you pointed out, presence of proxy is a very complicated topic since it depends on so many factors.

However, for our use case, I feel I don't need a 100% accurate solution. Instead of answering "Will there be a proxy b/w me and server A", I will just try to answer "if the user only proxy configuration is manual (i.e. no auto_config nor PAL) AND a proxy for http/https/socks is configured". If that's true, we'll just turn off UDP.

By looking at the code, it seems that if I could get a hold of ProxyConfigService, I could get the current config (GetLatestProxyConfig) as well as observe any change on that configuration. Does this sound reasonable given the simplification I mentioned above?

[Ryan Sleevi]

On Tue, Jun 30, 2015 at 3:16 PM, Guo-wei Shieh <guo...@chromium.org> wrote:

Thanks. My goal was to use the presence of proxy.  if there is, we'll not use UDP as it's not routed hence causing IP leak. And as you pointed out, presence of proxy is a very complicated topic since it depends on so many factors.

However, for our use case, I feel I don't need a 100% accurate solution. Instead of answering "Will there be a proxy b/w me and server A", I will just try to answer "if the user only proxy configuration is manual (i.e. no auto_config nor PAL) AND a proxy for http/https/socks is configured". If that's true, we'll just turn off UDP.

By looking at the code, it seems that if I could get a hold of ProxyConfigService, I could get the current config (GetLatestProxyConfig) as well as observe any change on that configuration. Does this sound reasonable given the simplification I mentioned above?

That sounds like a very fragile and non-deterministic solution, which will cause no end of headache for users and administrators alike. There's also the layering concern.

Are you sure that's the best way to accomplish your goal? Wouldn't it be better, more reliable, and more explainable to let users (or enterprise settings or extensions) opt in to or out of that behaviour?

[Guo-wei Shieh]

We're trying to find a reasonably good default for most of the following users. 

1. User who is concerned with ip leak and is using VPN to address it.

2. User who is concerned with ip leak and is using Proxy to address it. (I assume that most of enterprise users are not in the category. Its IP belongs to an identify of enterprise, not individual. They also likely have auto-config or PAC.  For individuals, it is likely to be some manual configured proxy, like Tor, for example.).

For #1, we still want to have UDP. I'm basically trying to find a way to identify majority of users in #2. 

--

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 post to this group, send email to net...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CACvaWvZLLLVvTEhXUaRzb2FmV1T7XHCoXyRynmvpGUTc0HJzYQ%40mail.gmail.com.