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.
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.
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.
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.
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAFE8Ch5frVQ5ircoHeCP7ny7yUKnExVGbSMVXDwve70%2BJJCnEA%40mail.gmail.com.
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.
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.
I definitely think we should do the webRequest part of it though!
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.
CheersAGL
Isn't this already the case with any certificate details about the domain being visited?
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.
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?
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.