Semantics and scope of extensions in multi-profile world

[Dominic Battre]

Hi.

We are currently working a System URLRequestContext that is not tied to a specific profile and should handle URL Requests for OCSP, Intranet Redirector and possibly others (because these requests are not tied to a specific profile).

The support of proxy settings by extensions triggered a discussion where we are looking for ideas.

Assume you have two profiles: "at home" and "at work"

You start your browser in "at home" mode and then add an "at work" window. This triggers the loading of all "at work" extensions. 

Say you have an "at work" extension that configures your proxy settings. What are the desired proxy settings for system URL requests? All "at home" windows will use the proxy configuration from the "at home" profile, all "at work" windows will use the proxy configuration from the "at work" profile (configured by an extension). But what should happen to system URL requests?

Here are a couple of ideas... and I like neither of them...

Option 1:

- we do not allow extensions to access the preferences of system URL requests --> these are configured by policies, command-line preferences and the operating system (in decreasing order of precedence). The user has no UI for modifying these settings with extensions. Other APIs (e.g. the Torbutton guys) might have similar issues of not seeing system URL requests. Users won't be happy, see http://crbug.com/266 .

Option 2a:

- we introduce extensions that live exclusively in the system-context and have no effect on requests from windows. They are started before profiles are loaded.

Option 2b:

- we introduce extensions that live in the system-context and their preferences can be overridden by extensions in profiles (overridden preference values are only visible from within a profile).

Option 3:

- we allow all extensions to modify the system preferences (i.e. BrowserProcess::local_state()). What could be a sensible tiebreaker if several extensions want to modify the same values? (within a profile we make the last extension installed the one that wins).

Option 4:

- ???

My current preference is Option 2b. I think that in most cases, people would install an extension and say "activate for all profiles". Only in few cases they will want to limit an extension to a specific profile. The downside of option 2b is that is requires quite some work and makes the UI more complex.

UI-wise, I could imagine an chrome://extensions/ tab, that contains entries like this

----

EXTENSION NAME

*Reload* - *Disable* - *Uninstall* - Activate for [........] - [x] Allow in incognito

----

where Activate for [.......] contains a rollup with values "ALL profiles", as well as each individual profile.

Any thoughts? We probably need input from the multi-profile folks, extension folks, network folks, and UI folks.

Best,

Dominic

[Matt Perry]

My preference would be option 3 (extensions can modify the system prefs). We'll have to deal with conflicts between 2 extensions, but as you pointed out, we have this problem with per-profile settings already. I think we can come up with some way to decide who wins.

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Peter Kasting]

On Mon, Jan 31, 2011 at 2:16 PM, Matt Perry <mpcom...@chromium.org> wrote:

My preference would be option 3 (extensions can modify the system prefs). We'll have to deal with conflicts between 2 extensions, but as you pointed out, we have this problem with per-profile settings already. I think we can come up with some way to decide who wins.

For example, most recently activated (if you load profile A then profile B, then extensions from profile B win).

If multiprofile work can allow users to restore windows from multiple profiles simultaneously this won't work, but otherwise it should be fine.

PK 

[Miranda Callahan]

I like option 3 as well, as it seems to me to be the clearest. I like
the most recently activated tiebreak idea because it seems to me that
this is what the user would expect it to do -- and that this also
allows the user to easily change system behavior by activating the
desired profile. In an ideal world, we would restore windows from
multiple profiles simultaneously, but this is by no means necessary.

[Evan Martin]

On Mon, Jan 31, 2011 at 3:21 PM, Miranda Callahan <mira...@chromium.org> wrote:
> On Mon, Jan 31, 2011 at 17:19, Peter Kasting <pkas...@chromium.org> wrote:
>> On Mon, Jan 31, 2011 at 2:16 PM, Matt Perry <mpcom...@chromium.org> wrote:
>>>
>>> My preference would be option 3 (extensions can modify the system prefs).
>>> We'll have to deal with conflicts between 2 extensions, but as you pointed
>>> out, we have this problem with per-profile settings already. I think we can
>>> come up with some way to decide who wins.
>>
>> For example, most recently activated (if you load profile A then profile B,
>> then extensions from profile B win).
>> If multiprofile work can allow users to restore windows from multiple
>> profiles simultaneously this won't work, but otherwise it should be fine.
>
> I like option 3 as well, as it seems to me to be the clearest.

Are there system APIs for modifying the systemwide proxy settings on
all platforms? On Linux the answer is almost certainly no, but if
this works on Mac and Windows then I wouldn't let that veto the idea.

[Mike Mammarella]

Well, we already have code to read GNOME and KDE proxy settings. In
the case of GNOME, the code to modify them would be pretty
straightforward, since we're already using the normal gconf API to get
at them. In the KDE case, we currently read the configuration file
directly in order to avoid picking up a dependency on the KDE
libraries. So, the KDE case would be tricky and fraught with gotchas
if we wanted to write browser code to do it. For other desktop
environments we rely on environment variables or command line
arguments, which we certainly can't do anything about.

However, this is something that could potentially be done with an
xdg-style script, for instance by adding to xdg-settings that we wrote
and contributed to xdg-utils to help with default browser selection.
If we shell out to an xdg script to update the proxy settings, then
we'd presumably pick up the change via the normal proxy configuration
change notification mechanisms when it became effective. If we want to
do it that way, it would be useful to design the APIs with potential
failure in mind (in the case of an unsupported desktop environment),
and to be asynchronous (to allow the script to run a while before
receiving a success status, and to allow that success status to
precede the actual proxy settings change).

[Mattias Nissler]

I think what Dominic meant is not the system proxy settings, but the proxy configuration used for the to-be-introduced system URL request context that is meant to handle all requests not associated with a profile. Question is whether extension should be able to control that through the proxy extension API, and if so, how exactly that should behave.

[Aaron Boodman]

On Mon, Jan 31, 2011 at 12:25 PM, Dominic Battre <bat...@chromium.org> wrote:

> We are currently working a System URLRequestContext that is not tied to a
> specific profile and should handle URL Requests for OCSP, Intranet
> Redirector and possibly others (because these requests are not tied to a
> specific profile).

Why is it important that these requests are not tied to a specific profile?

- a

[Mattias Nissler]

+willchan, who owns the system request context work: http://crbug.com/67232

AFAIK, there's lots of code that isn't tied to a profile (and shouldn't be). It seems weird that you can only make network requests if you live in a profile, hence the idea for the system URL request context.

[Dominic Battre]

OTOH, you could always use the most recently started profile for system URL requests.

[Chris Bentzel]

Cookie store will need to be on a per-profile basis, and some surprising things like TCP socket pools may need to be as well due to connection-based HTTP authentication.

It's possible we could have a "system profile" for doing things like safebrowsing bloom filter fetches [or most things which use URLFetcher]. 

[Wez]

On Jan 31, 8:25 pm, Dominic Battre <bat...@chromium.org> wrote:
> Hi.
>
> We are currently working a System URLRequestContext that is not tied to a
> specific profile and should handle URL Requests for OCSP, Intranet
> Redirector and possibly others (because these requests are not tied to a
> specific profile).
>
> The support of proxy settings by extensions triggered a discussion where we
> are looking for ideas.
>
> Assume you have two profiles: "at home" and "at work"
>
> You start your browser in "at home" mode and then add an "at work" window.
> This triggers the loading of all "at work" extensions.

I'd have thought that in a multi-profile world, this is what triggers
what is in effect a whole new browser instance, distinct from the
original, with its own set of child processes, extension state and
other context.

> Say you have an "at work" extension that configures your proxy settings.
> What are the desired proxy settings for system URL requests? All "at home"
> windows will use the proxy configuration from the "at home" profile, all "at
> work" windows will use the proxy configuration from the "at work" profile
> (configured by an extension). But what should happen to system URL requests?

Fundamentally I'd expect *all* requests of any sort to have
originated, however indirectly, from something the user did with the
browser, and therefore be implicitly bound to a profile.

In the OCSP example, requests arise as a result of my visiting sites
with certificates that support OCSP verification. So if I open up a
Work profile window and navigate to chromium.org, I'd expect that to
use my work profile settings to apply. Similarly, if I'm typing text
into the Omnibox of a Work profile window then I'd expect that traffic
to pass through the Work proxy, not pass through some other route in
the browser.

> Here are a couple of ideas... and I like neither of them...

[snip]

Since I don't like them either that means we agree on at least one
thing, which feels like a good start. ;)

> Option 4:
> - ???

Perhaps Option 4 is for it to be impossible for requests to be
generated without a context in the first place, and for extensions,
plugins, etc, to be completely isolated on a per-profile basis?

Cheers,

Wez

[Bernhard Bauer]

On Wed, Feb 2, 2011 at 18:21, Wez <w...@chromium.org> wrote:
> On Jan 31, 8:25 pm, Dominic Battre <bat...@chromium.org> wrote:
>> Hi.
>>
>> We are currently working a System URLRequestContext that is not tied to a
>> specific profile and should handle URL Requests for OCSP, Intranet
>> Redirector and possibly others (because these requests are not tied to a
>> specific profile).
>>
>> The support of proxy settings by extensions triggered a discussion where we
>> are looking for ideas.
>>
>> Assume you have two profiles: "at home" and "at work"
>>
>> You start your browser in "at home" mode and then add an "at work" window.
>> This triggers the loading of all "at work" extensions.
>
> I'd have thought that in a multi-profile world, this is what triggers
> what is in effect a whole new browser instance, distinct from the
> original, with its own set of child processes, extension state and
> other context.
>
>> Say you have an "at work" extension that configures your proxy settings.
>> What are the desired proxy settings for system URL requests? All "at home"
>> windows will use the proxy configuration from the "at home" profile, all "at
>> work" windows will use the proxy configuration from the "at work" profile
>> (configured by an extension). But what should happen to system URL requests?
>
> Fundamentally I'd expect *all* requests of any sort to have
> originated, however indirectly, from something the user did with the
> browser, and therefore be implicitly bound to a profile.

There are requests that are sent at startup or shortly thereafter (for
example IntranetRedirectDetector or the misleadingly named
GoogleUrlTracker), or in regular intervals in the background (for
example SafeBrowsing database updates or the extension blacklist).

> In the OCSP example, requests arise as a result of my visiting sites
> with certificates that support OCSP verification.  So if I open up a
> Work profile window and navigate to chromium.org, I'd expect that to
> use my work profile settings to apply.  Similarly, if I'm typing text
> into the Omnibox of a Work profile window then I'd expect that traffic
> to pass through the Work proxy, not pass through some other route in
> the browser.
>
>> Here are a couple of ideas... and I like neither of them...
> [snip]
>
> Since I don't like them either that means we agree on at least one
> thing, which feels like a good start. ;)
>
>> Option 4:
>> - ???
>
> Perhaps Option 4 is for it to be impossible for requests to be
> generated without a context in the first place, and for extensions,
> plugins, etc, to be completely isolated on a per-profile basis?
>
> Cheers,
>
> Wez
>

[Wez]

Bernhard,

On 2 February 2011 17:29, Bernhard Bauer <bau...@google.com> wrote:

On Wed, Feb 2, 2011 at 18:21, Wez <w...@chromium.org> wrote:
> On Jan 31, 8:25 pm, Dominic Battre <bat...@chromium.org> wrote:
>> Say you have an "at work" extension that configures your proxy settings.
>> What are the desired proxy settings for system URL requests? All "at home"
>> windows will use the proxy configuration from the "at home" profile, all "at
>> work" windows will use the proxy configuration from the "at work" profile
>> (configured by an extension). But what should happen to system URL requests?
>
> Fundamentally I'd expect *all* requests of any sort to have
> originated, however indirectly, from something the user did with the
> browser, and therefore be implicitly bound to a profile.

There are requests that are sent at startup or shortly thereafter (for
example IntranetRedirectDetector or the misleadingly named
GoogleUrlTracker), or in regular intervals in the background (for
example SafeBrowsing database updates or the extension blacklist).

Isn't opening the first window for a profile the multi-profile equivalent of starting the browser in the single-profile model, and therefore the point at which to perform those kinds of start-of-day tasks?

Wez

[Bernhard Bauer]

These requests update state that's shared by all users, so
conceptually there's no real association to any profile in particular.
That said, technically it might very well be possible to associate
them with a profile if needed (for example by simply using the
last/first profile like Dominic suggested).

Bernhard.

> Wez
>

[Wez]

So you're saying that if I were to run two copies of Chrome with different user-data directories, or run two copies under different operating system user accounts on the same machine, I'd hit problems with them competing to update system-wide data?

Wez

[Bernhard Bauer]

Sorry, I meant user as in the real-world entity corresponding to a
profile (in Dominic's example, we'd have a Work and a Home persona),
so we're talking about one browser process and one --user-data-dir
here.

Bernhard.

> Wez
>

[Matt Perry]

We had a meeting today to discuss this in more detail. Here's a quick recap of the conclusions we reached:

- There should be a SystemURLRequestContext for requests not tied to a Profile (Safe Browsing updates, OCSP, etc).

- We should extend the proxy extension API so that developers can opt-in to applying their proxy to system-level requests. Otherwise, they only apply to the current profile.

- If an extension tries to change the system-level proxy and another extension has already done so, that is an error. We notify the extension, and it can decide how it wants to handle that situation.

[Daniel Wagner-Hall]

Does this entail any additional permissions? If so, do we have an idea
what the warning messages for them may look like?

[Aaron Boodman]

I don't see why there's be different warnings for "system" proxy
setting vs "normal" proxy setting.

- a

[Matt Perry]

I'm starting to rethink this a bit. We didn't give a whole lot of thought to Dominic's option 1 (ie, don't let extensions control the proxy for system requests). Do extensions really care about system requests?

I spoke to my brother (author of the Torbutton extension for Firefox), and it sounds like the only thing Torbutton would really want to go through Tor is OCSP requests. And perhaps OCSP requests should be tied to a profile anyway. In fact, based on how safebrowsing works, Torbutton might want those requests *not* to go through Tor.

The other major proxy extension is FoxyProxy. Maybe we should reach out to the extension developers and see if they even want to change the system proxy. Until then, how about we postpone support for setting the system-wide proxy?

[Ryan Sleevi]

If an extension is implemented as part of a privacy-preserving scheme (such as Torbutton is, as far as I can tell), I would think it would want access to the system proxy settings/the settings OCSP/certificate validation uses, as they could lead to revealing the user's IP address to a malicious endpoint.

The "attack" I'm thinking of is this: A malicious site directs a user to an attacker-controlled HTTPS site. The HTTPS site serves a certificate with an AIA extension pointing to an issuer certificate hosted on an attacker-controlled HTTP site, and intentionally omits that issuer certificate as part of the SSL handshake. When the user attempts to load the original HTTPS site, as part of the certificate validation for that site, the attacker-specified HTTP site will be hit as part of a request for the issuer certificate, based on the AIA extension. At a minimum, the user's IP would be revealed to the attacker, although without much context. However, an attacker could go further and generate such certificates on the fly, with relative cheap computational cost, and embed unique tracking identifiers as part of the AIA URL. This would allow them to correlate the original browsing/SSL session to the user's specific IP. With SSL session resumption on, which is not something extensions can currently control, then even as the user hops Tor exit nodes, the original mapping of user<->IP remains.

With Torbutton and how Firefox implements proxy settings and certificate validation, I believe such requests are directed through the appropriate profile settings always, ergo the user's privacy is preserved (ie: AIA request goes through Tor). For Chrome, it's full of nuance, so the above "attack" would work against an extension that looked to do what Torbutton, or any other privacy-preserving proxy tool, does.

Since the original question from Dominic and Will originated in the context of OCSP, I did want to point out the nuances currently related to the implementation across platforms, since I believe it may help make the decision easier - or it will open up a whole lot of TODOs. The TL;DR version of what follows is that already today, there are settings completely out of reach of extensions, and using the above attack, can be used to compromise privacy-based proxy extensions. So as much as users are unhappy about http://crbug.com/266 and the potential unhappiness from Option 1, unless the certificate validation logic is changed on all platforms, to the likely detriment of users, OR Chrome starts actively modifying the OS-system proxy settings, there will remain an element of Chrome functionality that does not respect whatever the user/extension specifies on Windows and Mac. My thought is that having an element on Linux/ChromeOS that equally ignores the profile settings, as Option 1 describes, probably isn't the worst that could happen.

Nasty details explaining why:

OCSP and certificate validation raise an edge case though the differences between the different platforms. The system (that is, Chrome-wide) proxy settings would only apply to Linux and ChromeOS, as both of those use NSS to perform the certificate validation logic, which in turn depends on Chrome's network stack to fulfill the CRL/OCSP/AIA requests. As certificate validation may involve three types of external resources (CRLs, OCSP, and AIA), any requests for resources of those three types on Linux and ChromeOS are dictated by whatever decision is made regarding extensions and proxy settings.

For Windows and Mac, however, this is an entirely different story, because certificate validation is done using the OS APIs (CryptoAPI and CDSA/Security Framework, respectively). Both platforms support fetching CRLs, OCSP statuses, and AIA-chased certificates, and do so using the OS-user proxy settings and/or the OS-system proxy settings. Unless Chrome modifies those settings, which to date has been something that has been avoided, then whatever an extension requests, or whatever profile the user is currently in, makes no difference, because the OS-settings will always win. Further, on Windows, there is one more type of request (at least on Vista+), for a root certificate update, that is also triggered by HTTPS validation.

In the context of the "attack" I originally described, Windows won't request CRLs or OCSP statuses unless it's determined the certificate validates to a known root. This reduces the ability of the attacker to generate tracking-AIAs on the fly, since unless they've been issued a CA certificate, such ephemeral certificates won't chain to a known root. I don't recall if this logic is implemented the same on Mac or in NSS, but gut/vague memory are that it may be the same there as well. However, all three systems will chase AIAs by default. On Windows, this can be disabled via OS-API flags, and with NSS, we could implement such logic in the network stack. However, on OS X, the AIA chasing happens unconditionally if the chain is partial, and there are no flags to turn this off.

In the context of http://crbug.com/266, even with the Proxy Settings API, there's an element dependent on the user's system configuration. If the user's proxy settings resulted in unreachability for OCSP, then no site could be guaranteed to be EV (I believe it would result in a revocation unknown/revocation failed, which will be a site security warning, ala mixed content). Without AIA fetching, it's possible (particularly on Mac) that an intermediate will be missing/fail to download, and the site gets the SSL validation failed interstitial. Not bad, mostly unfortunate/confusing user experience. 

[Wez]

On 2 February 2011 19:59, Bernhard Bauer <bau...@google.com> wrote:

On Wed, Feb 2, 2011 at 20:50, Wez <w...@chromium.org> wrote:
> On 2 February 2011 18:38, Bernhard Bauer <bau...@google.com> wrote:

[snip] 

>> These requests update state that's shared by all users, so
>> conceptually there's no real association to any profile in particular.
>> That said, technically it might very well be possible to associate
>> them with a profile if needed (for example by simply using the
>> last/first profile like Dominic suggested).
>>
>
> So you're saying that if I were to run two copies of Chrome with different
> user-data directories, or run two copies under different operating system
> user accounts on the same machine, I'd hit problems with them competing to
> update system-wide data?

Sorry, I meant user as in the real-world entity corresponding to a
profile (in Dominic's example, we'd have a Work and a Home persona),
so we're talking about one browser process and one --user-data-dir
here.

That doesn't sound right to me - surely if I have gone to the trouble of separating my Work & Home personae, it's clear that I want them to be separate, so I want them to have completely independent user-data, in the same way as if Work & Home were actually separate user accounts on the host computer?

Wez

[Wez]

On 3 February 2011 04:09, Ryan Sleevi <rsl...@chromium.org> wrote:

[snip]

 

For Windows and Mac, however, this is an entirely different story, because certificate validation is done using the OS APIs (CryptoAPI and CDSA/Security Framework, respectively). Both platforms support fetching CRLs, OCSP statuses, and AIA-chased certificates, and do so using the OS-user proxy settings and/or the OS-system proxy settings. Unless Chrome modifies those settings, which to date has been something that has been avoided, then whatever an extension requests, or whatever profile the user is currently in, makes no difference, because the OS-settings will always win. Further, on Windows, there is one more type of request (at least on Vista+), for a root certificate update, that is also triggered by HTTPS validation.

 

[snip]

If we're talking about operating-system-wide proxy settings then surely the problem is not specific to multi-profile functionality in Chrome, but also affects multi-user systems, if two users have different proxy requirements?

Wez

[Bernhard Bauer]

Well, that's already supported now -- just start two Chrome processes
with different --user-data-dir switches.

Bernhard.

> Wez
>

[Wez]

Which is what the "Multi-profile" support described at http://www.chromium.org/user-experience/multi-profiles essentially describes, with there being N "local" profiles, of which M (<= N) are bound to by synced to Google account profiles, isn't it?

Wez

[Bernhard Bauer]

It also describes being able to switch profiles from within a browser
window, which you can't do if you have separate browser processes for
each user data directory.

Bernhard.

> Wez
>

[Miranda Callahan]

once more, from the correct account...

On Thu, Feb 3, 2011 at 11:15, Miranda Callahan <mira...@google.com> wrote:
>>>> > That doesn't sound right to me - surely if I have gone to the trouble of
>>>> > separating my Work & Home personae, it's clear that I want them to be
>>>> > separate, so I want them to have completely independent user-data, in
>>>> > the
>>>> > same way as if Work & Home were actually separate user accounts on the
>>>> > host
>>>> > computer?
>>>>
>>>> Well, that's already supported now -- just start two Chrome processes
>>>> with different --user-data-dir switches.
>>>
>>> Which is what the "Multi-profile" support described
>>> at http://www.chromium.org/user-experience/multi-profiles essentially
>>> describes, with there being N "local" profiles, of which M (<= N) are bound
>>> to by synced to Google account profiles, isn't it?
>>
>> It also describes being able to switch profiles from within a browser
>> window, which you can't do if you have separate browser processes for
>> each user data directory.

Ah, let me step in here to say that a discussion with Glen and Jeff
last week made clear that this will *not* be an option in the
multiprofile system; the browser menu listing different profiles will
provide the opportunity to launch a new window with the chosen
profile. Changing the underlying profile data in a running browser
window is simply too complicated to handle here.

The idea of separate user data extends only to the data in the
personal profile directory (right now, stored in "Default") -- not to
the entire user-data-dir.

(I have edited the multiprofile design doc to hopefully make this more
clear -- see the "Profile Launch Menu" section.)

-- Miranda

[Dominic Battre]

Hi.

On Thu, Feb 3, 2011 at 3:38 AM, Matt Perry <mpcom...@chromium.org> wrote:

I'm starting to rethink this a bit. We didn't give a whole lot of thought to Dominic's option 1 (ie, don't let extensions control the proxy for system requests). Do extensions really care about system requests?

I think people will care. If you are in a firewalled environment, you might need to set a proxy to communicate with the outside world. I.e. if extensions cannot set up all proxy configuration values, the "system" traffic cannot pass the firewall.

Best regards,

Dominic 

[Mattias Nissler]

You can always work around that by setting the proxy manually in the system config (which you want to do in this case anyway).

[Matt Perry]

Ryan brings up a good point. In Tor's case, they care way more that certificate validation be done through Tor than various browser-level requests like safebrowsing. It sounds like we can't do cert validation through the proxy regardless of what we do is. Is that correct?

[William Chan (陈智昌)]

[ summons wtc ]

Well, Wan-Teh was telling me something about how we need more control over SSL settings. I forget all the reasons why. But IIRC, the conclusion was that we need to use NSS for certificate validation as well, not just the SSL handshake/encryption/decryption stuff. In that case, we'd have full control over certificate validation. Wan-Teh, please correct me if I remembered incorrectly.

So, if we do move towards that, we can do cert validation through the proxy.

[Mattias Nissler]

On Thu, Feb 3, 2011 at 8:20 PM, Matt Perry <mpcom...@chromium.org> wrote:

Ryan brings up a good point. In Tor's case, they care way more that certificate validation be done through Tor than various browser-level requests like safebrowsing. It sounds like we can't do cert validation through the proxy regardless of what we do is. Is that correct?

If we allow extensions to set the proxy for the system request context, we should be able to, no?

[Mattias Nissler]

On Thu, Feb 3, 2011 at 8:53 PM, Mattias Nissler <mnis...@chromium.org> wrote:

On Thu, Feb 3, 2011 at 8:20 PM, Matt Perry <mpcom...@chromium.org> wrote:

Ryan brings up a good point. In Tor's case, they care way more that certificate validation be done through Tor than various browser-level requests like safebrowsing. It sounds like we can't do cert validation through the proxy regardless of what we do is. Is that correct?

If we allow extensions to set the proxy for the system request context, we should be able to, no?

Ah, you mean for the win and mac case. Sorry for the noise.

[Ryan Sleevi]

From the right account this time...

On Thu, Feb 3, 2011 at 2:20 PM, Matt Perry <mpcom...@chromium.org> wrote:

Ryan brings up a good point. In Tor's case, they care way more that certificate validation be done through Tor than various browser-level requests like safebrowsing. It sounds like we can't do cert validation through the proxy regardless of what we do is. Is that correct?

Safebrowsing, general browser-level requests:

  Linux/BSD/ChromeOS: Respects Chrome's proxy settings

  Mac: Respects Chrome's proxy settings 

  Win: Respects Chrome's proxy settings

Certificate Validation (CRL, OCSP, AIA, Root Updates)

  Linux/BSD/ChromeOS: Respects Chrome's proxy settings (uses Chrome's network stack)

  Mac: Uses CFURL/CFNetwork via ocspd, which defers to OS-system level proxy settings.

  Windows: On < XP SP2, uses WinINET, which uses OS-user's IE proxy settings. On XP SP2+, uses WinHTTP, which uses WinHTTP proxy settings (different than IE settings, see http://crbug.com/5313 ). May also involve other network stacks, as path building and revocation modules can be plugged in on the fly from third-parties.

If platform parity is better for extensions - that an extension can have the same expectation of what it will affect on all the systems - than Option 1 is a safe way to guarantee that, as there will be no platform-specific differences: extensions have no control over the proxies used for browser-level requests, including cert validation.

However, if power/flexibility is better for extensions, than Options 2 or 3 would be better, since on !Win && !Mac, it would be flexible enough to allow such privacy-relevant extensions to be developed. Certificate validation would remain an edge case to be documented by extension authors when user's are on Win or Mac.

And the nasty alternative always exists, which is that Chrome directly modifies the system-level proxy settings to try to force those layers to share the same settings as Chrome is actively using. But I suspect that most people (myself included) would be opposed to that, and it still wouldn't be guaranteed for all contexts on Windows.

[Matt Perry]

Thanks for clarifying, Ryan.

Question for the network folks: should network requests for certificate validation be issued with the profile's request context, or the global system request context? If it's the former, then Option 1 would be sufficient for Tor's needs.

[Ryan Sleevi]

On Thu, Feb 3, 2011 at 2:36 PM, William Chan (陈智昌) <will...@chromium.org> wrote:

[ summons wtc ]

Well, Wan-Teh was telling me something about how we need more control over SSL settings. I forget all the reasons why. But IIRC, the conclusion was that we need to use NSS for certificate validation as well, not just the SSL handshake/encryption/decryption stuff. In that case, we'd have full control over certificate validation. Wan-Teh, please correct me if I remembered incorrectly.

So, if we do move towards that, we can do cert validation through the proxy.

If you're referring to http://crbug.com/67622, that was just in the context of SSLv3/TLSv1/OCSP settings (and potentially SSL cipher suites, via policy, not UI).

We had previously discussed using NSS for path building/validation on all platforms, and the reason for/against using NSS on all platforms at the time were:

Con: On Windows, the certificate path building implementation via CryptoAPI is much more robust than that offered via NSS, and better integrates with other applications/user expectations and things like smart card redirection via RDP/Terminal Services. So there would be a loss of functionality switching to NSS exclusively.

Con: On Windows and on Mac, it would also increase the configuration overhead, as the user would need to configure third-party PKCS#11 modules to work with the browser, as they do in Firefox, for edge cases like smart card authentication. ( http://crbug.com/63542 )

Con: On Windows, users would lose access to custom crypto service providers that implement custom cryptographic algorithms ( such as GOST, http://crbug.com/57835 )

Pro: On Mac, the certificate path building implementation via NSS is much more robust than that offered via CDSA/Apple's trust policy. Here, there'd be a great gain of functionality ( http://crbug.com/69278 )

Pro: On Windows and Mac, using NSS across the board would make it easier to switch to a FIPS-approved version of NSS, and make it easier to use Chrome in a FIPS-approved mode of operation on those systems, as there would be only one crypto subsystem ( http://crbug.com/31087 )

So in the context of extensions, using NSS for path building/validation would add another pro, in that extensions like Torbutton could be developed for use with the browser, as all requests would go through the browser network stack. I'm just not sure how important that extension flexibility is right now, and whether or not that changes the decision to use the OS APIs.