Re: [chromium-discuss] Feature to warn about possible SSL snooping

[Chris Bentzel]

+security-dev would likely be in better position than net-dev

There's also related topics in the security FAQs:

http://www.chromium.org/Home/chromium-security/security-faq#TOC-Why-aren-t-physically-local-attacks-in-Chrome-s-threat-model-

http://www.chromium.org/Home/chromium-security/security-faq#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters-

On Mon, Apr 25, 2016 at 7:25 AM Primiano Tucci <prim...@chromium.org> wrote:

On Mon, Apr 25, 2016 at 11:38 AM John Lafortune <john.m.l...@gmail.com> wrote:

I recently discovered my employer, like many others, performs SSL interception to decrypt and inspect HTTPS traffic. I assume the majority of employees have no idea this is even possible. They may see in company policy the network is monitored but assume traffic with the green padlock, like their bank or email, is untouchable.

The thing is: as long as somebody is able to run arbitrary code on your machine, they have won. there is very little chrome can do to in these cases. 

 

I would like to see Chromium flag unknown certificates with a warning symbol, so that users are aware something might not be quite right. The same icon that's used for mixed HTTPS/HTTP resources. And a message if you click on it, such as "your connection is encrypted, but the certificates are unknown to Chromium and as a result your communications may be visible to a third party."  It doesn't make sense to me to show the green "https" and padlock. I think that implies the connection is truly secure from prying eyes. 

Even if chrome did show a warning symbol, somebody's code running on your machine could attach (in the ptrace, or equivalent, sense) to chrome and call the method to make the padlock to be green again.

 

I don't know much about Chromium internals but assume it can differentiate between known and trusted root CAs versus those added later to the user's browser or operating system. Has any similar feature been discussed (none were found in my search)? 

+net-dev might be your best point of contact here.

I am not a net/security expert, but I suppose that what you propose is defeating the concept of a "trusted CA". The problem is: when you see a certificate for yourbank.com signed by a malicious (yet trusted) CA how can you possibly tell that it is not valid if you have never seen the original cert before? (If you did HSTS pinning would prevent the attack you describe, but this is not the case here). The only thing you could do is considering any certificate signed by a non-bundled CA as doubtful, but that would mean making a trusted-CA not really "trusted".

(eventually you might argue about solutions like SSL Observatory, but this would drag this thread off-topic w.r.t.  the original discussion of the green padlock)

IMHO the problem here is not the presence of an extra trusted ca, is the fact that somebody can run arbitrary code on the machine you use to log into your bank, and this is not something that can be reliably detected / fixed at a Chrome level. If somebody is able to install trust CAs on your machine, they can be as well able to run a keylogger. There is nothing an userspace program can do to prevent/detect that.

 

Thanks!

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

--
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/CA%2ByH71dPB1wUBFD7isHGFJiJSTE0XyjHW0CcT9tQDvS9QFi5AQ%40mail.gmail.com.

[Adrienne Porter Felt]

This is a topic that I wrestle with a lot.

On one hand, I would like proxies and enterprise controls to be transparent to end users.

On the other hand:

• If the proxies don't want to be seen, they can hide themselves (as Primiano described).
• A huge fraction of clients have local inline proxies intentionally installed, and they typically apply to every HTTPS connection. Showing a warning would be overkill.

The best I've been able to come up with is that we can add a note in DevTools or the PageInfo bubble. However, most people won't notice this; you'd have to go looking for it, which perhaps makes it not very useful.

[Eric Lawrence]

This topic seems to come up every few months.

A certificate represents the assertion of a site's identity by some organization. The strength of that assertion varies, but I worry that we risk misleading users if we continue to reduce HTTPS to a boolean ("Secure" vs. "Not").

I expect that the vast majority of users already make that reduction (or worse, and more commonly: "Safe" vs. "Maybe Not Safe?") but as our UX evolves I think we hold some important ability to shape those perceptions. We also should be sensitive to the fact that we have some savvy users who are more likely to notice that things are amiss if we don't make it hard (a la "Superfish"). I argue that browsers should help users distinguish between a government-issued ID card and a inkjet-printed business card.

In some privacy-sensitive locales, organizations performing SSL interception are required to provide "notice" that they're doing so, to the point that in IE we considered adding a specific "TLS Interception" OID that would change the lock icon to a lock with an overlay so that the user could be informed that their data was being intercepted, and they may elect to perform some sensitive tasks (e.g. interacting with health data) away from corporate-monitored PCs.

One question I have is how complex it would be for a Chrome extension to grab the certificate details and/or participate in the evaluation of a certificate's validity. In Internet Explorer, this was near impossible, but over the years we had a number of requests for this capability-- first, to provide a "PetName" type extension (where a site's certificate could be bound to a user-selected image), next to offer Opera-like lockdowns ("Prompt before accepting when encountering a certificate from the Turkmenistani National CA") and later to offer HPKP certificate pinning before the browser itself had that feature.

In Chrome 52, we explicitly tell the user that their connection is "Private" even if an interception certificate is in use:

We don't currently show the issuer in the OIB UI and the current plan is to move it to the Developer Tools which seems to only reinforce the notion that all certificates from all issuers are equivalent.

--

Eric Lawrence
Chrome Security

[Peter Bowen]

On Mon, Apr 25, 2016 at 8:20 AM, 'Eric Lawrence' via Security-dev <securi...@chromium.org> wrote:

This topic seems to come up every few months.

A certificate represents the assertion of a site's identity by some organization. The strength of that assertion varies, but I worry that we risk misleading users if we continue to reduce HTTPS to a boolean ("Secure" vs. "Not").

We don't currently show the issuer in the OIB UI and the current plan is to move it to the Developer Tools which seems to only reinforce the notion that all certificates from all issuers are equivalent.

Maybe it would be worth making an attempt to provide a different UI treatment for certificates that chain to CAs known to follow the Chrome CA policy.  It would not be fool-proof but might be enough to encourage vendors to be more responsible in installing private roots (e.g. use an extension rather than MITM the TLS connection or use name constrained roots for private networks).

[Chris Palmer]

Adrienne, want to add that to the FAQ?

You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

[Adrienne Porter Felt]

Good idea Chris. I took a stab at it. Everyone, feel free to edit.

[Adrienne Porter Felt]

On Mon, Apr 25, 2016 at 8:20 AM, Eric Lawrence <elaw...@google.com> wrote:

This topic seems to come up every few months.

A certificate represents the assertion of a site's identity by some organization. The strength of that assertion varies, but I worry that we risk misleading users if we continue to reduce HTTPS to a boolean ("Secure" vs. "Not").

I expect that the vast majority of users already make that reduction (or worse, and more commonly: "Safe" vs. "Maybe Not Safe?") but as our UX evolves I think we hold some important ability to shape those perceptions. We also should be sensitive to the fact that we have some savvy users who are more likely to notice that things are amiss if we don't make it hard (a la "Superfish"). I argue that browsers should help users distinguish between a government-issued ID card and a inkjet-printed business card.

In some privacy-sensitive locales, organizations performing SSL interception are required to provide "notice" that they're doing so, to the point that in IE we considered adding a specific "TLS Interception" OID that would change the lock icon to a lock with an overlay so that the user could be informed that their data was being intercepted, and they may elect to perform some sensitive tasks (e.g. interacting with health data) away from corporate-monitored PCs.

One question I have is how complex it would be for a Chrome extension to grab the certificate details and/or participate in the evaluation of a certificate's validity. In Internet Explorer, this was near impossible, but over the years we had a number of requests for this capability-- first, to provide a "PetName" type extension (where a site's certificate could be bound to a user-selected image), next to offer Opera-like lockdowns ("Prompt before accepting when encountering a certificate from the Turkmenistani National CA") and later to offer HPKP certificate pinning before the browser itself had that feature.

That's a good idea. A lot of people have asked for this in the past, and it's currently not available information.

 

In Chrome 52, we explicitly tell the user that their connection is "Private" even if an interception certificate is in use:

We don't currently show the issuer in the OIB UI and the current plan is to move it to the Developer Tools which seems to only reinforce the notion that all certificates from all issuers are equivalent.

It's more like, we don't expect non-developer users to be able to interpret the issuer information, rather than saying it is not important information.

[Emily Stark]

On Mon, Apr 25, 2016 at 10:18 AM, Adrienne Porter Felt <fe...@chromium.org> wrote:

On Mon, Apr 25, 2016 at 8:20 AM, Eric Lawrence <elaw...@google.com> wrote:

This topic seems to come up every few months.

A certificate represents the assertion of a site's identity by some organization. The strength of that assertion varies, but I worry that we risk misleading users if we continue to reduce HTTPS to a boolean ("Secure" vs. "Not").

I expect that the vast majority of users already make that reduction (or worse, and more commonly: "Safe" vs. "Maybe Not Safe?") but as our UX evolves I think we hold some important ability to shape those perceptions. We also should be sensitive to the fact that we have some savvy users who are more likely to notice that things are amiss if we don't make it hard (a la "Superfish"). I argue that browsers should help users distinguish between a government-issued ID card and a inkjet-printed business card.

In some privacy-sensitive locales, organizations performing SSL interception are required to provide "notice" that they're doing so, to the point that in IE we considered adding a specific "TLS Interception" OID that would change the lock icon to a lock with an overlay so that the user could be informed that their data was being intercepted, and they may elect to perform some sensitive tasks (e.g. interacting with health data) away from corporate-monitored PCs.

One question I have is how complex it would be for a Chrome extension to grab the certificate details and/or participate in the evaluation of a certificate's validity. In Internet Explorer, this was near impossible, but over the years we had a number of requests for this capability-- first, to provide a "PetName" type extension (where a site's certificate could be bound to a user-selected image), next to offer Opera-like lockdowns ("Prompt before accepting when encountering a certificate from the Turkmenistani National CA") and later to offer HPKP certificate pinning before the browser itself had that feature.

That's a good idea. A lot of people have asked for this in the past, and it's currently not available information.

Yeah, there has been a lot of interest, for various use cases, in adding an extension API for certificate information and SSL properties, and it would be relatively straightforward to add it to webRequest and/or the HAR spec, so that extensions can read this data after the fact. However, adding an API that allows extensions to inspect/validate certificates during connection setup and block/change connections would be much more complicated and have much deeper performance implications.

I definitely think we should do the webRequest part of it though!

 

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

[Eric Mill]

On Mon, Apr 25, 2016 at 10:59 AM, Adrienne Porter Felt <fe...@chromium.org> wrote:

This is a topic that I wrestle with a lot.

On one hand, I would like proxies and enterprise controls to be transparent to end users.

On the other hand:

• If the proxies don't want to be seen, they can hide themselves (as Primiano described).
• A huge fraction of clients have local inline proxies intentionally installed, and they typically apply to every HTTPS connection. Showing a warning would be overkill.

The best I've been able to come up with is that we can add a note in DevTools or the PageInfo bubble. However, most people won't notice this; you'd have to go looking for it, which perhaps makes it not very useful.

These are very reasonable concerns, though I think you should really consider adding *some* kind of note somewhere, even if it's deep in the DevTools or PageInfo bubble. 

In addition to the already-described concerns about notifying users, it makes sense from a debugging perspective: Chrome now uses the presence of a locally installed root in the validation path to change its security behavior in at least one case (enforcing pinning). What state Chrome is in should be reliably ascertainable *somehow* by the user, even if it's just for the level of power user where you expect them to file bug reports.

I also think that some of the concerns above about showing a more user-visible indicator could be reduced if it weren't shown as a "warning", but rather just an ambient fact of what's happening. This might reduce the potential for warfare with enterprise IT, and for warning fatigue.

That could also mean separating it from the lock icon, so that it doesn't affect how users interpret the icon or otherwise muddle Chrome's ongoing efforts in that space to improve security usability. I could imagine something like what Chrome used to do with the RSS icon, in the days when Chrome would auto-detect whether a feed is available on a page.

-- Eric

 

You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

--

konklone.com | @konklone

[Adam Langley]

On Mon, Apr 25, 2016 at 10:35 AM, Emily Stark <est...@chromium.org> wrote:

I definitely think we should do the webRequest part of it though!

There are also grubbier reasons that we haven't done this UI before:

If we're going to show a UI, we would want it to be accurate and not confuse people. However, a user who moves into the scope of a MITM proxy might load a page, get it from cache, and thus get a "clean" indicator, which is weird. Then, a few seconds later, a subresource Javascript load might be a cache-miss, triggering a TLS connection, where we discover the presence of the proxy and now have to replace the indicator with the "MITMed" one, after the fact. (And after the user has stopped paying attention to it.)

Likewise, when a user goes out of the MITM's scope, cached resources might cause us to show the "wrong" (from the user's mental model) indicator.

One could imagine splitting the cache into "clean" and "MITMed" parts. But now consider the life of a request. We don't know which part of the cache to use until we've made a TLS connection, which means that we can't serve cache hits until a handshake has completed. That's a major change to the workings of the HTTP stack and so the cost/benefit of an indicator like this has not seemed net positive in the past.

Cheers

AGL 

[Eric Mill]

On Mon, Apr 25, 2016 at 7:26 PM, Adam Langley <a...@chromium.org> wrote:

On Mon, Apr 25, 2016 at 10:35 AM, Emily Stark <est...@chromium.org> wrote:

I definitely think we should do the webRequest part of it though!

There are also grubbier reasons that we haven't done this UI before:

If we're going to show a UI, we would want it to be accurate and not confuse people. However, a user who moves into the scope of a MITM proxy might load a page, get it from cache, and thus get a "clean" indicator, which is weird. Then, a few seconds later, a subresource Javascript load might be a cache-miss, triggering a TLS connection, where we discover the presence of the proxy and now have to replace the indicator with the "MITMed" one, after the fact. (And after the user has stopped paying attention to it.)

Isn't this already the case with any certificate details about the domain being visited? The lock icon attempts to factor in subresource loads, but the information presented when the user clicks "View Certificate" is only tied to the top-level page, and could reflect the details shown from a prior cached visit. While it may not always be fully accurate because of potential caching, it's still useful and relevant.

Even if caching weren't a concern, it would be difficult to factor in subresource loads when deciding if a local root is being used in a holistic sense, since proxies might be active for some domains but not other ones. 

I think some of the discussion about showing information or warnings about local roots gets caught up in assuming it has to behave like the lock icon and factor everything in so that the user can make a security decision. Where as if it's considered more informational, it could be tied purely to the page-level certificate chain in use -- and have its accuracy model be identical to that of the certificate chain.

 

Likewise, when a user goes out of the MITM's scope, cached resources might cause us to show the "wrong" (from the user's mental model) indicator.

This is interesting -- if the page is loaded from a cache, then it didn't go through any network, so there's no confidentiality risk associated with the proxy -- but the integrity of the content was previously verified when the proxy was active, so the content should be considered as trusted as the proxy is.

But it's also the same situation as above -- whether or not a local root is "in use" for loading the cached page will be as valid as the certificate information that Chrome is already willing to present to the user.

Maybe this would be a good place to start: when I'm looking at certificate information, or a part of the security console clearly scoped to the page's origin and not any of the subresource origins, show whether the certificate chain Chrome considers currently active for the page's origin includes a local root. On the security pane, this could go in the "Main Origin" section, in the "Valid Certificate" section.

-- Eric

--

konklone.com | @konklone

[Emily Stark]

I wasn't advocating for implementing any UI, just for exposing the certificate/SSL details to extensions. Are you saying that we shouldn't necessarily expose it to extensions because they might implement a confusing/nonsensical UI with it?

(There are completely non-UI reasons why people want this in extensions -- for example, CT has a desire to let users log certificates that they see.)

 

Cheers

AGL 

[Adam Langley]

On Mon, Apr 25, 2016 at 4:58 PM, Eric Mill <er...@konklone.com> wrote:

Isn't this already the case with any certificate details about the domain being visited?

That's correct. However, certificate details are evinced to a far lesser extent than the indicator that I think most have in mind here.

This is interesting -- if the page is loaded from a cache, then it didn't go through any network, so there's no confidentiality risk associated with the proxy -- but the integrity of the content was previously verified when the proxy was active, so the content should be considered as trusted as the proxy is.

Yes. I think an indicator which latched to "MITMed" for all origins which have loaded a resource that used a local root would probably be sufficiently accurate. Flushing the cache would reset the indicators. But I'm not claiming that would be reasonable to implement or even useful to people.

Cheers

AGL 

[Adam Langley]

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

I wasn't advocating for implementing any UI, just for exposing the certificate/SSL details to extensions. Are you saying that we shouldn't necessarily expose it to extensions because they might implement a confusing/nonsensical UI with it?

Sorry, I jumped into the thread under your post but I was specifically talking about the UI question. I believe we've reached a point in the past where we wanted to implement this UI but didn't because of the implementation complexities that I outlined. Since it was critical in the past, I just didn't want it to get lost.

Those complexities can simply be passed upwards in the case of extension APIs. I think it does affect the decision a little (i.e. will the extensions that we wish to enable be useful given that they have to deal with this?) but you cite an example (CT) where they still would.

Cheers

AGL 

[Eric Mill]

On Tue, Apr 26, 2016 at 10:39 AM, Adam Langley <a...@chromium.org> wrote:

On Mon, Apr 25, 2016 at 4:58 PM, Eric Mill <er...@konklone.com> wrote:

Isn't this already the case with any certificate details about the domain being visited?

That's correct. However, certificate details are evinced to a far lesser extent than the indicator that I think most have in mind here.

I think you're right, but I am specifically suggesting a more tightly scoped, less visible/scary indicator than was originally proposed, because I think it would still be concretely useful to Chrome and to some users, without running afoul of most of the legitimate caching/UI concerns you described.

-- Eric

 

[Chris Palmer]

On Tue, Apr 26, 2016 at 10:48 AM, Eric Mill <er...@konklone.com> wrote:

I think you're right, but I am specifically suggesting a more tightly scoped, less visible/scary indicator than was originally proposed, because I think it would still be concretely useful to Chrome and to some users, without running afoul of most of the legitimate caching/UI concerns you described.

There's a bit of a weird trade-off here. Any warning or indicator or badge or thingie needs to be important enough to raise at all. Remember, Chrome is called Chrome because it purposefully doesn't have much chrome ("prefer content over chrome") — Simplicity is a top-level goal.

A non-actionable, not-too-important, power-user-only, non-deterministically-appearing badge/indicator is not likely to meet our UX team's bar for UX features. Especially given that a power user already has a recourse: Look at the certificate chain. I believe MITM proxies are pretty immediately apparent when you look there. ("Weird, my Facebook is signed by something called 'Superfish'. Is that right? Let me Google it... Oh dear." And, "Hmm, my Gmail appears to be signed by 'FooCorp DLP Proxy'. Ahh.")

I was once strongly in favor of the badge, too, but the non-determinism (as Adam described earlier in the thread) was the key thing that swayed me against it.

I know this is unsatisfying, but ultimately MITM proxies are a layer 8 problem. We can only dance around pseudo-effectively in code, as far I have been able to tell.