Issue 163116: Flash and other plugins should be forced through the browser's proxy

I might add that this problem also exists with the Google Talk Plugin, with the additional headache that you probably can't send UDP packets through your proxy.  But users who have the talk plugin and a proxy configured should be given a choice about whether they want Talk Plugin to circumvent their proxy or not.

Comments on Plugins: +brett, raymes
Comments on Sockets: +darin
Comments on API surface for Apps&Plugins: +miket,erikkay
Policies on Sandboxing networking: +Feature-Security

I don't believe there is anything that can be done for NPAPI plugins (like Google Talk), given that the trust level that they execute within. NPAPI plugins further may not support proxies at all, may attempt to discover proxy settings themselves, or may attempt to discover them via NPN_GetValueForURL with NPNURLVProxy. Chromium can only return the proxy information if they use that latter interface - and I don't believe many do.

Pepper based plugins should be using the proxy interfaces afforded by Pepper, which should offer similar functionality for NPN_GetValueForURL. However, if the connection being made is not to a URL, or not a URL type supported by the API (such as for a direct socket connection), then likely no proxy information will be received. I don't believe either Pepper or NPAPI use concepts like "tcp://foo" or "udp://bar" to indicate resolutions for raw sockets.

Finally, I do not believe our Sandbox functionality is intended to restrict network connections in this way. That is, socket APIs are "part of" the API surface intentionally being exposed.

Pepper (and Apps) expose APIs to allow plugins/apps to make raw TCP and UDP socket connections, equivalent to their POSIX equivalents (eg: no automagic proxy handling, even when SOCKSv5 is being used). For Apps, this is governed by the permission policy associated with the installed App. For Plugins, I believe this is (presently) restricted to Flash, and is governed by Flash socket policy files, the same as it is for native Flash plugins. I'm sure this will also come up with WebRTC and its SDP, so it's worth thinking about.

I'm pretty sure everything here is, for better or worse, "Works as Intended", but the extra visibility should garner some comments if I've mispoken here.

When you use TCP sockets in Flash, you're using TCP sockets. To my knowledge, we can't force any particular proxy behavior on this in a way that would keep that feature working.

Of course, we can't do anything at all for NPAPI plugins, since they're outside our network stack. However, it seems like the presence of a SOCKS proxy would imply that Pepper perform the handshake and route the native tcp/udp connection through the proxy. Since the proxy does support arbitrary protocols and from the plugin's perspective the behavior would be essentially transparent.

(Also, if I see one more person use "raw" tcp or udp incorrectly I will possibly  explode.)

I recommend closing this bug as WontFix.

The network activity for plugins does not have to go through the browser, and hence does does not need to respect any browser level or system level proxy settings.

There are two questions here:

One is, do we try to find a solution for all plugins?  If so, there are various methods for achieving that, such as hooking OS calls (you could use tsocks or equivalent), or specc'ing a solution via Pepper and nudging people towards it.

The second and more pressing question is: how will Google fix this for the plugins that actually ship with Google Chrome?  That bug should definitely NOT be wontfixed.  There are plenty of adequate hacks to fix it in the specific case of Flash, including the tsocks-type solution or working with Adobe to pass the proxy in via any method you like.

If all else fails, you should add a setting to disable Flash sockets if the user has set a proxy and is in Incognito mode.  You can do that with a mms.cfg file, per:

http://www.ghacks.net/2010/09/07/enforce-global-flash-player-security-and-privacy-settings/

Flash is using a Pepper TCP API, isn't it?  If that's the case, it sounds like this is just a question of supporting your Windows SOCKS proxy setting in that case.  This would also protect us in the future for Chrome apps that use the sockets API.  For plugins like Talk that don't go through Pepper for networking, it's a different story of course.

Yes, all Pepper plugins should honor the SOCKS proxy settings. They go through our stack and the user's intent is clear. We can't do anything about NPAPI, but we can and should make PPAPI work correctly.

When last we met to discuss this, it was agreed that Pepper *should not* go through the proxy settings, since that significantly limits the ability for Pepper apps to fully implement a variety of protocols. That is, the application (whether Pepper or AppsV2) should instead be able to query the settings and implement its own connection logic.

Consider, for example, jingle-like protocols which collect a variety of possible connection points to attempt - both proxied and non-proxied.

For applications that don't care about that distinction, we also discussed providing new APIs to establish such connections.

But at no point did the notion of the sandbox or API guarantee extend to *requiring* connections go through a proxy.

People configuring a SOCKS proxy are doing so because they *really* need to guarantee all their traffic will be proxied, and they're willing to accept the overhead. If that wasn't their intent, then they'd configure per-protocol proxies. Also, are there any significant cases where pepper plugins are actually relying on unproxied connections as you suggest? Because I'm not aware of any offhand, and I'd think we should satisfy the primary (only?) case before we start discussing exceptional cases.

jschuh: I'm looking at http://developer.chrome.com/dev/apps/app_network.html as an example of the types of Apps we're promoting.

Explicitly adding eroman, as your description of SOCKS is one that we've so far (intentionally?) avoided. The use of proxies - including SOCKS - is much more nuanced and complex here, for a variety of reasons; multi-profile and ChromeOS are two prime examples.

jschuh: configuring a SOCKS proxy doesn't guarantee anything to a user, right?  Based on how this appears to behave, it's clearly just advisory for Windows apps to follow, right?  Given this I don't see how users would assume this is a guarantee.  I agree with you that it does seem to be the user's intent though.  I'm just curious what percentage of windows apps respect the setting, which ones don't out of ignorance (or laziness) and which ones intentionally avoid it because they have to in order to function properly.

rsleevi: It sounds like your suggestion is that we expose SOCKS information as an API and let the application choose whether to use a configured SOCKS proxy or not.  What if we defaulted to using it and gave the application an option to ignore it?

re: configuring proxies having no effect - correct. In fact, *many* applications do not respect SOCKS proxies. Entire software projects exist that do things like intercept BSD socket APIs (on Linux) or provide SOCKS support as Winsock LSPs (a variety of firewall products). But for *most* users, configuring of SOCKS is done per-application, and may or may not affect all aspects of that application.

I believe we already expose the SOCKS information, but in a non-ideal way. I believe Pepper has an API that mirrors NPAPI's GetProxyForURL. For addresses/protocols/ports that are not expressed as URLs, this doesn't work well. So yes, what had been discussed previously was an API to say "Get configured proxies". We did discuss at length whether or not Pepper (and AppsV2) should provide a "Give me a stream API", which is explicitly higher level than a "give me a socket API" (aka: what Apps provides today, which is closer to BSD sockets API). The "give me a stream API" would handle things like negotiating DNS resolution, happy eyeballs, proxies, etc, so that it eventually yields a stream. During the discussion, it was pointed out how closely this overlaps with WebSockets and what WebSockets provides, as well as concerns about how it relates to other "streams-over-sockets" protocols like SPDY, WebRTC, and... others...

I will see if I can find notes from that meeting. But during the discussion (with brett, raymes, and others), it was discussed that automatically wrapping sockets (whether Pepper or Appsv2) in SOCKS was desirable, and the conclusion was that no, it  isn't, when all factors are considered.

erikkay: My point is that supporting SOCKS implies that we would fully support it to the reasonable extent that we can. Because people really do configure SOCKS expecting anything that supports it to be fully tunnelled. As for providing a way to bypass the proxy, I'm of that opinion that should be explicitly opt-in rather than opt out.

jschuh: While people may expect that, that has never been the policy or implementation of Chrome (see, e.g.,  Issue 123716  ). From the perspective of the network stack, support for SOCKS beyond the *URL* request has been "best effort", and there are a wide variety of Chrome features that do not observe such proxies in such a mode. So you're arguing for a viewpoint that's not supported and never been, which is why I'm pushing back :)

Just to re-iterate, doing this for plugins in general (NPAPI) is not feasible, since they don't go through Chrome's network stack. You would need to use system-level hooks.

Doing this for pepper plugins is possible, although ugly. The challenge is that pepper provides low level access to TCP sockets, UDP sockets, and host resolutions. (PPB_UDPSocket_Private, PPB_TCPSocket_Private, PPB_HostResolver_Private).

Ordinarily DNS is done by calling the system's DNS resolver through getaddrinfo(). This system library has no knowledge of the Chrome proxy settings of course, so it will not be tunneled through the desired SOCKS proxy. This is why in Chrome (just like Firefox) you can't tunnel DNS requests through the proxy server, since the networking is done by the system. Users are habitually confused by this, since URL level requests will bypass doing DNS (deferring to the proxy), however features like DNS prefetching do host lookups direclty and hence result in traffic outside of the proxy.

Chrome has an experimental DNS resolver implementation ("async DNS resolver") which can be used as a replacement for the system one. If this becomes the default one day, then it will become easy to proxy DNS requests as well, since we control the code that sends the UDP packets in Chrome.

Until that happens, to accomplish proxying pepper's host resolution API we would need to magically swap out the host resolver implementation that Chrome uses, when certain proxy configurations are detected. This could certainly work, however it is unexpected.

I conceptually agree that sending the pepper plugins traffic through transparent proxies like SOCKS is the right thing to be doing.

However what worries me is positioning this solution as a privacy/security feature. Whatever we do at the browser-level is best-effort. To be truly robust and enforce that absolutely no traffic gets sent outside of the Chrome proxy settings, it would be necessary to guarantee that every component in Chrome goes through a common network choke point. libjingle, webrtc, and every single other third party component included in Chrome, now and into the future.

Even then, there is still the unresolved problem of non-pepper plugin being able to initiate connections outside of the proxy (or for that matter do whatever they want to your system). There may also be less obvious network dependencies when you call into system libraries. For instance certificate revocation checking by the OS could send unwanted traffic.

Users that are serious about protecting their information from going onto the network would be best served by doing it at the OS networking level. For instance VPN/firewall/winsock LSP

@rsleevi - I was never talking about a wide variety of features in Chrome. I was referring only to Pepper plugins because they are web content built entirely on top of our stack (display, network, sandbox, etc.). So, it's reasonable to expect we'd do our best to honor the same SOCKS proxy settings that we would for other web content (understanding the name resolution differences due to discrepancies between SOCKS and legacy plugin protocols).

Accepting that, I think @eroman did a great job of explaining the current situation, engineering effort required, and other features that would gate work on this. So, I'm certainly not demanding we start work on this ASAP. I'm just saying the bug is legitimate and shouldn't be closed WontFix.

WebRTC seems to present another instance of this grave privacy problem. Probably WebRTC should be click-to-play if it can't be proxied, for users who have a proxy configured, because it will leak your real public IP in order to send UDP traffic.

There's an additional problem with WebRTC leaking private (LAN) IPs.  Probably there should be a process for getting user consent for those, and encouraging WebRTC developers to only ask for them if two users of an app are actually on the same LAN.

Regarding the WebRTC problem, see https://code.google.com/p/chromium/issues/detail?id=497040

Any updates regarding this old and obvious security flaw? It's annoying to have to VPN my entire internet connection, instead of just Chrome, when going on a Flash website.

Correcting this to more accurately reflect the status of this bug.

There are no plans to force Flash connections through the same Chrome networking stack, and it would be detrimental to users to do so.

For users who wish to browse "privately" (which is a complex topic not fully addressible in this bug), the correct answer is to use a VPN, configured upstream of the target device (e.g. software VPNs are insufficient).

I know Justin's comment in #c22 suggested avoiding closing this, but it's more honestly reflective of the priorities and efforts involved, the complexity, and the maintenance costs. Ensuring all connections run through a proxy is a non-goal, both for Chrome and ChromeOS (where it is even more explicitly stated).