proposal for removing CertStore/SignedCertificateTimestampStore

[Emily Stark]

[site-isolation-dev@ is on bcc. The code in question doesn't fall squarely under any particular team or group of people so I'm sending this to a selection of lists and individuals that I think might have useful feedback.]

A few weeks ago I wrote up a proposal to kill //content's CertStore and SignedCertificateTimestampStore with reasons why I think it's reasonable to do so: https://docs.google.com/document/d/1X6Pj9BecYy6K2zANMgS8hP07RtZjOKfbxah8eXiQYrA/edit

Summary: these stores confusingly tie certificate/SCT lifetime to a particular renderer's lifetime, don't work particularly well for PlzNavigate, and lead to some convoluted code. They can be reasonably straightforwardly replaced by sending the objects to the renderer processes that need them.

Please comment on the doc and let me know if you think this is a good idea or a bad idea! (No particular rush -- this refactor is on the back burner for me.)

Thanks,

Emily

[Ryan Sleevi]

Hi Emily,

Thanks for putting this doc together. I think you've definitely captured some of the weird edges in our SSL code at the //content layer and above.

However, I suppose my main concern is this seems to place full trust in the renderer, rather than treating it as a bug that we trusted the renderer in the first place? I'm not sure how to square that - on it's face, it makes me extremely uncomfortable to trust the renderer for true and accurate display of information, much in the same way we wouldn't trust the renderer with our security UI. With efforts like PlzNavigate, it seems like we should be tracking this better/more accurately in the browser process, rather than giving up and saying the renderer can tell us whatever it wants.

[Emily Stark]

Hi Ryan, thanks for the comments. I'll respond to the other concerns you raised in the doc but wanted to reply about the trust-in-the-renderer issue here.

Hey, who said I'm giving up?! Ok, well, you're right that I glossed over this question a bit in my thinking and in the doc. But, pondering it more now, I think the question of trusting the renderer is somewhat orthogonal. This proposal maintains the current level of trust in the renderer, and I don't think it makes it any harder for us to reduce that trust. (I might have phrased things in the doc so that it sounds like "oh well the renderer wins this war so let's just give up" -- I'll go back and check for that.)

Specifically, I started thinking about how we might go about reducing trust in the renderer:

- Browser-side security UI (lock icon, omnibox, OIB): As you pointed out, with PlzNavigate, it'll become possible to use trusted information from the browser to populate them -- my proposal doesn't preclude that, I think. The browser process should be able to just retain the information it needs for the navigation request, rather than relying on the renderer to report back the security information (whether it's a cert id or a certificate) for the navigation request.

- DevTools security panel: I might or might not hold the opinion (I can't decide) that the security panel is designed specifically as a debugging tool for developers, and it's not "secure UI" despite the fact that it displays security-relevant information. I'm not sure that we can hope for DevTools to truly be secure UI, given that it itself runs in a renderer. But setting that concern aside for a moment, if we imagined in a world in which we send security information from the browser directly to DevTools to display in the security panel, I don't think that world is too much affected by the presence or absence of the CertStore. In the yes-CertStore world, we would send a cert id to DevTools on each request, and DevTools would query back to the browser for the information corresponding to a given cert id. In the no-CertStore world, we would send the information that DevTools wants to display on each request.

Thanks again,

Emily

[Ryan Sleevi]

On Mon, Apr 11, 2016 at 6:24 PM, Emily Stark <est...@chromium.org> wrote:

- DevTools security panel: I might or might not hold the opinion (I can't decide) that the security panel is designed specifically as a debugging tool for developers, and it's not "secure UI" despite the fact that it displays security-relevant information.

We removed the explanation on the Lock Icon under the statement that DevTools will replace it. It would sound like we replaced "trusted UI" with "untrusted UI" (mod the existing caveat that seems to have regressed that we're trusting the renderer regardless, which was arguably a bug to begin with)

[Emily Stark]

+lgarron

In my mind, the separation is that the browser UI contains the trusted information that an end user needs to make decisions about their security and privacy, whereas the security panel contains information useful for developers to debug their sites, which we were okay with making untrusted. The hazy middle ground, in my opinion, is power users: we probably took away information from trusted UI that they use to make security/privacy decisions.

It sounds like we should figure out what exactly our stance is on whether DevTools is truly secure UI and try to make it so if we want it to be so -- but I think it's still a separate question from CertStore.

[Ryan Sleevi]

On Mon, Apr 11, 2016 at 6:52 PM, Emily Stark <est...@chromium.org> wrote:

We removed the explanation on the Lock Icon under the statement that DevTools will replace it. It would sound like we replaced "trusted UI" with "untrusted UI" (mod the existing caveat that seems to have regressed that we're trusting the renderer regardless, which was arguably a bug to begin with)

In my mind, the separation is that the browser UI contains the trusted information that an end user needs to make decisions about their security and privacy, whereas the security panel contains information useful for developers to debug their sites, which we were okay with making untrusted. The hazy middle ground, in my opinion, is power users: we probably took away information from trusted UI that they use to make security/privacy decisions.

Agreed. This also brings into question how we handle EV - are we (effectively) trusting the renderer process to tell us something is EV or not? And what certificate it is? Right now, we position EV as something that's useful to users to make an informed decision about security/privacy, but perhaps that's not the case in the implementation?

Having looked at the code more, it definitely seems like we've been placing a lot of trust in the renderer. The CertStore was part of trying to not do that (only certificates a renderer has used are accessible to it), but perhaps didn't do so completely. There's also the performance characteristics - certs of 3-4kb each, chains of 3-5 certs. You have extremely high hit rates for things like root certs and intermediates (across all origins), near complete hit-rates for resources loaded over QUIC/SPDY/HTTP2 (due to connection coalescing), and high hit rates for resources on a page. Each of these were over 90% - and so that's a lot of possibly duplicate information to send over.

[Emily Stark]

On Mon, Apr 11, 2016 at 7:01 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

On Mon, Apr 11, 2016 at 6:52 PM, Emily Stark <est...@chromium.org> wrote:

We removed the explanation on the Lock Icon under the statement that DevTools will replace it. It would sound like we replaced "trusted UI" with "untrusted UI" (mod the existing caveat that seems to have regressed that we're trusting the renderer regardless, which was arguably a bug to begin with)

In my mind, the separation is that the browser UI contains the trusted information that an end user needs to make decisions about their security and privacy, whereas the security panel contains information useful for developers to debug their sites, which we were okay with making untrusted. The hazy middle ground, in my opinion, is power users: we probably took away information from trusted UI that they use to make security/privacy decisions.

Agreed. This also brings into question how we handle EV - are we (effectively) trusting the renderer process to tell us something is EV or not? And what certificate it is? Right now, we position EV as something that's useful to users to make an informed decision about security/privacy, but perhaps that's not the case in the implementation?

Yes, insofar as the renderer populates the SSLStatus on the NavigationEntry, but I feel like maybe that's not what you're getting at? I thiiiiink the security panel is totally EV-agnostic and doesn't differentiate EV in any way, not 100% sure though.

 

Having looked at the code more, it definitely seems like we've been placing a lot of trust in the renderer. The CertStore was part of trying to not do that (only certificates a renderer has used are accessible to it), but perhaps didn't do so completely.

I don't think there's a meaningful security boundary there; even if cert ids weren't predictable, a renderer can request subresources for whatever sites it wants and then it learns the cert ids of those certificates. (Though maybe at some point in history there a plan to lock that down in some way that I don't know about.)

[David Benjamin]

On Mon, Apr 11, 2016 at 10:16 PM Emily Stark <est...@chromium.org> wrote:

On Mon, Apr 11, 2016 at 7:01 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

Agreed. This also brings into question how we handle EV - are we (effectively) trusting the renderer process to tell us something is EV or not? And what certificate it is? Right now, we position EV as something that's useful to users to make an informed decision about security/privacy, but perhaps that's not the case in the implementation?

Yes, insofar as the renderer populates the SSLStatus on the NavigationEntry, but I feel like maybe that's not what you're getting at? I thiiiiink the security panel is totally EV-agnostic and doesn't differentiate EV in any way, not 100% sure though.

 

Having looked at the code more, it definitely seems like we've been placing a lot of trust in the renderer. The CertStore was part of trying to not do that (only certificates a renderer has used are accessible to it), but perhaps didn't do so completely.

I don't think there's a meaningful security boundary there; even if cert ids weren't predictable, a renderer can request subresources for whatever sites it wants and then it learns the cert ids of those certificates. (Though maybe at some point in history there a plan to lock that down in some way that I don't know about.)

I agree that the security boundary isn't meaningful and think this is a good plan. It makes things simpler which makes it easier to work out an actual security boundary later. (E.g. PlzNavigate doesn't work with certificate IDs right now. DevTools currently has all kinds of weirdness because it's reliant on a cert ID owned by a different process, so the certificate is no longer accessible once the other process dies.)

David

[Emily Stark]

An external contributor (Daniel, cc'ed) would like to go ahead with the removal of the SignedCertificateTimestampStore as part of adding additional CT information to DevTools. I hope that removing the SCTStore is less controversial than removing the CertStore, and I've described why below. But nevertheless I went through and updated the doc that I sent in this thread to explain why I still think that removing both the CertStore and SCTStore makes sense (does not make it harder to reduce trust in the renderer, and does not have to introduce an unacceptable performance penalty).

As to why I think removing the SCTStore is fairly straightforward:

- Daniel is planning to attach SCTs (instead of SCT ids) to IPCs, but only when DevTools is enabled. I believe that SCTs are much smaller than certificate chains, and can be attached only when DevTools is enabled, so I hope the performance penalty is more palatable than what I originally proposed (always attaching certificate chains to IPCs).

- In my mind the SCT details fall squarely into the category of information used for debugging rather than the category of information that someone would use to make security decisions, so the particular way in which they flow through the untrusted renderer is less interesting than certificates.

Also note that the SCTStore can be removed completely independently of the CertStore: there's no reason that removing one means we have to remove the other. Though I do still want to remove the other. :)

[Eran Messeri]

FYI the removal took place in https://crrev.com/88f6c692a10e5da4d1d87dac49d243359048f097.

Thanks, Daniel!