Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 663971 Make it easier to open the Certificate Viewer on HTTPS sites
Starred by 202 users Project Member Reported by lgar...@chromium.org, Nov 10 Back to list
Status: Fixed
Owner:
Closed: May 4
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux, Windows, Chrome, Mac
Pri: 2
Type: Feature

Blocked on:
issue 657267

Blocking:
issue 718553


Show other hotlists

Hotlists containing this issue:
Hotlist-1


Sign in to add a comment
Certain details used to be in the connection tab in Page Info, which was either two clicks (on valid HTTPS pages) or one click (on broken HTTPS pages). Opening the cert viewer was an additional click on a button which was very close by.

The Security panel can takes some time to open, especially on slower machines (but we don't know exactly how much – see Issue 555860).

Right now, we have:

Opening the Security panel directly:
- Page Info [mouse] -> "Details" link [mouse]

Opening DevTools:
- menu icon (three dots) [mouse] -> More Tools [mouse] -> Developer Tools
- View menu [mouse] -> Developer [mouse] -> Developer Tools [mouse]
- Cmd-Shift-I (depends on platform) [keyboard] -> Developer Tools

Switching DevTools to the Security panel:
(First open DevTools, which is not instant.)
- DevTools must be open -> Click on "Security Panel" [mouse]
- DevTools must be open -> Cmd-8 (unless you moved your panels around) [keyboard]
  - This requires enable shortcuts in DevTools, which must be done once in each profile of each installation – you're out of luck if you need to use temporary profiles or debug on new computers/VMs/Chrome installations regularly.

Opening the certificate viewer from the Security panel:
- Tab (assuming you're in a freshly opened Security panel) -> Enter
- Click on "View certificate"

If we remove the Page Info "Details" link ( Issue 646465 ), then a new profile requires either raising the number of actions to open the cert viewer, or force the user to switch between keyboard and mouse.

This may sound a little silly, but I've heard a few complaints about how we seem to be making it hard to get to the Security panel, and specifically the cert viewer. Paul Irish has also talked to me about how developers love their shortcuts, and right now it is impossible for them have shortcuts for this.

Some options:
1. Ignore this concern and just remove "Details" with  Issue 646465 .
2. Try to leave have both "Security Details" and "Learn more" links in Page Info.
3. Add a shortcut for the Security panel and/or cert viewer to the entire browser.
4. Provide a mechanism for devs to use shortcuts in their profile (is this possible through an extension API? Is it easy to expose through something like AppleScript on all OSes?)

CCed folks: How do you feel about this?
I'm okay with ignoring it, as long as we acknowledge we are adding a tiny bit more pain to people who have to use the Security panel every day. If people do come to us, this can be the bug to discuss it in the future.
 
I vote for Option #1 for M56. With HTTP-bad phase 1, I think it's more important to help average people understand what's going on than to avoid annoying developers.

Any of options 2, 3, or 4 seem fine to me with a future release. I probably like #3 best.
Labels: -Type-Bug Type-Feature
Status: Available
It's critical that average users can get to the Help Center article especially for M56. I would vote for #1 for M56 (just because I think there are more critical things to get to before branch).

For a future release, I'd prefer 3 or 4 over #2, because I think that PageInfo should primarily be a user-oriented feature. If we went with #2, I could imagine a user clicks "not secure", sees two links, panics, clicks "security details", sees nothing they understand, and continues to panic.

It would be great if you could point devs to this bug, if they ask, to suggest any alternatives, and to explain our reasoning!

BTW: can you give me a feel for how hard #3 is? I'm guessing that generally the supply is small and demand high for browser shortcuts so we need a good argument? Can we prove this with the metrics for Security Panel opens?
There was pushback against adding a shortcut even for Page Info. :-/
Issue 536158
Cc: lgar...@chromium.org
 Issue 671638  has been merged into this issue.
User feedback notes that EV without identity info isn't really EV.
https://twitter.com/randomoracle/status/808395813994958849
Some more details about option 4:

There is a DevTools extension API [1]. It currently exposes two specific panels, but there is no precedent for exposing a panel-specific method like SecurityPanel.showOverview() or SecurityPanel.openCertificateViewer().

(Also, keep in mind that that this would only work for users with an appropriate extension installed, and enabling extensions in Incognito is not a good practice. I don't think this solution would satisfy *all* developers, given that there are plenty of situations where it is a good idea/necessary to debug using a fresh profile.)

paulirish@: Does that seem like the kind of thing DevTools would be happy to have, or are there concerns we'd need to work through?

[1] https://developer.chrome.com/extensions/devtools_panels
I came here to echo Comment 7.

I went to a site in 56.0.2924.21 that had an EV certificate, but that certificate was issued to a third party running a promotion for a different company. I was curious to find out more about the certificate and details (since I was concerned about a potential phish,) but the traditional step of clicking on the lock to find more information yielded no useful information. And the Help Center article it did link to had no additional information about how to see certificate details.

I'm here after following a link in the product forum and another bug, wherein I was reminded that there are developer-specific features to access this information.

I realize this is developer-oriented ticket, and so this may not be the place to log the issue, do please do realize that easy access to certificate information is more than a developer convenience. It allows users to judge the veracity of EV certs.
Option 2 please.

+1 Comment 7
+1 Comment 9

The discussion has focused on two user types, "Standard User" & "Developers". There is a 3rd type of user that falls in between these two and should be represented, "Power Users".

Power users, which would include system admins and help desk, need to investigate issues and having the certificate details deep in the UI makes life difficult.
Please restore clicking on the lock to get security info, or at least some easy link to security info! Having to go through developer tools is a huge PITA, and most of the time I just give up on my security curiosity. This is a step backwards. Please add it back.
Cc: elawre...@chromium.org
If we do work here, one important thing to note is that the Developer Tools can be disabled by policy (prefs::kDevToolsDisabled). If that happens, we should consider doing what we used to do and make our "Show security" link open the certificate inspector directly?
lgarron, IMO option 4 wouldn't be great for these folks as it's opt-in. I'd prefer a solution that works more out-of-the-box for people.

In my mind it seems like we could do two things 1) improve performance of opening devtools. 2) tease more data about the site's certificate on the overview.
paulirish: What are your thoughts on an extension API (see comment #8)?
Re #13.2, I think the details folks would want to expose would likely be too heavy for the overview.

We could add a link to "how to see certificate details" in the help center, but not sure if that would fully solve this.
I am not a Chrome developer so I dont fully understand Option 4.

Would Option 4 just make it easier for a developer to be able to view
Certificate Viewer when they are doing their work?

Would Option 4 give developers an ability to open Certificate Viewer up for
people using their application by calling
SecurityPanel.openCertificateViewer()?

Craig Carlston
Costco Wholesale, Information Services
Identity and Access Management, Key Management Team
office 425-416-5275  cell 206-234-8176
As a user, I want to know if the security warnings I'm getting are to be expected or not. In a corporate environment, I know that my firewall is performing (for better or for worse) MITM attacks on some web resources, in order to do things like vulnerability scans on the content I'm getting. I need to be able to readily look at the warning information to verify if the warning is the result of that corporate firewall (ie, that the untrusted CA is my employer), vs something more nefarious.
Re #17: You shouldn't be seeing interstitial warning pages in the case of a corporate firewall, because your machine should have the organization's CA certificate installed in its trust anchor store. HTTPS signed by your firewall should appear perfectly 'good'. And such firewalls usually MITM all traffic, not just some. So I'd be surprised if you are sometimes seeing the corporate firewall, and sometimes seeing other root CA certificates. Are you?

Generally, and unfortunately, once a MITM appliance/firewall thing is in place, you have to fully trust it. I'd be very surprised if checking the root CA of every page load is really helping you gain any security. If you're concerned about the corporate firewall spying on you or increasing your exposure to fake sites, you're best off using your phone for personal stuff, and just doing work on your work machine.
I'm user and will just see CA chain quickly to confirm it's secure, why it's not (autosigned,expired..) if it use a free CA (let's Encrypt for example). or intercepted (Avast AV can, why badware can't?)
chrome secure but not original cert.png
124 KB View Download
If you're using AV software, you can generally assume that it is intercepting all of your HTTP and HTTPS connections, in the manner shown in #19: The AV software installs a local trust anchor (CA certificate), and uses it to sign all sites.

If you don't want that, turn it off. (Hopefully your AV program offers the option to turn that off.)

In either case, if Chrome shows the green lock, that is the best indication that the certificate chain is valid, for whatever definition of 'valid' applies on your machine.

And, indeed, malware that gets control of your local user account, or the local administrator account, could install a trust anchor and then transparently MITM your HTTPS just as AV software does. But, it could also spy on your browsing (and all other stuff you do on the computer) by many other means. That's not a Chrome problem — once malware gets to run as you or as admin, it's not your computer anymore.
Comment 21 Deleted
I agree with others here, e.g. comment 7, but want to make sure to say this explicitly: viewing the certificate is NOT just for developers.  Maybe you want to dumb things down for the average user and that's fine, but finding the certificate should not be like a quest for the Holy Grail.

At a bare minimum, the help page you get to from "Learn More" should actually tell you where the certificate lives.  Right now the best available documentation on how to find the certificate is this bug report.

But to reiterate, since Joe Average User may need to see what is in a certificate, it shouldn't be so hidden.
Comment 23 Deleted
Agree with comnent #7, #8 and #17.

As for local trust roots, it's still useful to be able to confirm that MITMing is active on the page you're currently viewing. Simply assuming "I have an AV running, so it's probably doing MITM is a kit more vague than actually checking.

Additionally, I believe there will always be cases where certificate warnings need to be manually overridden, as unfortunate as it is. 

E.g., there are universities whose trust root is not part of the store. In practice, students need to override cert warnings before (if ever) an admin can install the root certificate. Being able to easily check identity is needed to tell "good" cert warnings from "bad" cert warnings.
 Issue 686789  has been merged into this issue.
The biggest problem in my opinion is that development tools are often disabled via group policies in big companies. So it's impossible to get certificate chain details.
If you remove it from the normal "lock dialog" it's not good but moveing it to development tools is a very bad decision. That's anti security.
I'm in complete agreement with #22.

It's essential to be able to verify a certificate as a user. While I do have a slight security background and am thus a bit more paranoid, which changes my behavior to a good extent, I still do, before every single Google or PayPal login check the certificate to at least check the Issued To and Issued By fields.

The way average users see internet security is "If it has a green lock, it's safe to put in all my passwords and credit card data". They are not even aware of most attack vectors and have been trained to believe "green lock = safe". And if bnakofamerica.com, which they accidentally and without noticing mistyped into the address bar, has a valid SSL cert and the user sees the green lock: done deal! Log in and gone is the account.

Granted, checking the spelling in this case would reveal the mistake and is easier than checking the cert, but phishing doesn't only target bad spelling...

Sorry, I got side-tracked I believe...

Basically the green lock gives a false sense of safety, while the inability to verify the green lock's validity cements the sense of safety to entice users into making mistakes.

I apologize for the incomprehensibility of this reply, I have difficulties expressing myself coherently.
Labels: Hotlist-CertificateViewer
Hi all.
I'm above average user and using Chrome for good few years now. I'm also developing simple websites and using SSL certs, and I totally can't understand the great push to take away the details of certificate away from the view. In the older days I just clicked the padlock and I could see the details of the cert, who signed it, expiry date, chain of trust etc. The it got moved to the developer view (to my annoyance), however there was a link from the padlock menu. And now there is no link whatsoever and I had to google the issue to figure out what went wrong. In the day of Lenovo MITM SSL attack and number of  "security suites" taking over the encrypted connections I think this is irresponsible to show green padlock and no easy way to view what the heck we are dealing with. Maybe I'm not the average user but I do check the certs of the websites, especially the important ones (banks, password manager etc), on daily basis. Chrome mobile for android is still showing the cert info as it supposed to (again, as some bright spark tried to remove it in the past).
Would you please consider to bring it back where it belongs, to the green padlock menu. 
Regards
Sam

Hi,

I'm going to agree with #29. This change really is counterproductive to the whole notion of getting users to check the certificate chain for issues and MITM.

I'm still not clear on why this change is necessary and why getting typical users to dive into the developers menus is a good idea?

Has anyone actually run this through any sort of usability testing with non technical users rather that talking within the filter bubble of the tech world?

Please give us an EASY way to check the certificate chain without complex menu interactions that normal non-technical users can find and understand!

Kind Regards

Simon Zerafa

RE #30: Yes, the Chrome team conducts a great deal of user testing. The question at hand isn't about the ease of launching the Certificate Viewer, but rather the importance of doing so for most users.

Can you elaborate on what "issues" you'd like the user to check the certificate chain for, and under what circumstances you'd expect this approach to be useful for in detecting a MITM?

Thanks!
Re #31: Verifying identity against the threats of rogue CAs and covertly installed local root certificates. Note also #7, that EV certs don't really make sense without an easy way to verify them.

Furthermore, I don't understand the general sentiment. If the goal is a more secure web, wouldn't it make sense to give users *more* tools to educate themselves about web security instead of taking away tools?
To reiterate, the existence of this Issue is to add a shortcut to the Certificate Viewer in order to accommodate the myriad (but perhaps uncommon) use-cases for which the Chrome 56 change was frustrating. 

> rogue CAs and covertly installed local root certificates.

Generally speaking, anything that can install (covertly or not) a Local Root certificate also has the ability to manipulate the execution environment (e.g. binaries on disk, data structures in memory) to mask itself from discovery. A locally installed root can name itself anything it wants, including spoofing the name of other (legitimate) CAs.

The threat of "Rogue CAs" (CAs who miss-issue) is a bit different. Manual Certificate Inspection (or surfacing of the relevant chain details) *could* be useful for discovering attacks, although only by the very small set of users who bother to inspect chains and are qualified to notice that something is amiss. Certificate Pinning and Certificate Transparency (required for all certificates starting in October 2017) are the primary means by which this threat will be blunted.

To secure the web, we need automatic mechanisms for detecting attacks. I believe that work like HSTS, CT, pinning, etc are the most effective way forward and will be more successful than hoping to educate the masses about PKI.

But to reiterate, yes, I too want a shortcut to get to the Certificate Viewer.
RE #31: An assumption has been made that is wrong. It is not true that a company that does the MITM threat management gateway inspects *ALL* sites.

There is a white list of sites for banks and other things that may have employee's personal data that a company does not want to be responsible for knowing. I like to know if a particular site has been intercepted so I look at the chain.

It would be nice if there was an easy way to view the Root certificate in a chain. Maybe even if you hover over the lock in the address bar it could list the name of the root certificate.

The "learn more" link is fairly redundant when the site has a valid certificate with no warnings. For a page served over HTTP, by all means prioritise a "learn more" link where regular (non-developer) users can read about the risks of insecure transport. But for a page that's served over HTTPS, my belief is that most people clicking the padlock will be looking for more details about the certificate (or site owner), rather than a guide page explaining the different lock statuses.

I cannot see why both options can't be made available in the same place. All that's required is a "certificate details" or similarly worded link beneath the summary info. I am in complete agreement with others above; that this kind of information should be made easy to access for anyone with a bit of curiosity or a concern about MiTM / rogue certs, rather than buried away in dev tools.
RE #33:

> Generally speaking, anything that can install (covertly or not) a Local Root certificate also has the ability to manipulate the execution environment (e.g. binaries on disk, data structures in memory) to mask itself from discovery. A locally installed root can name itself anything it wants, including spoofing the name of other (legitimate) CAs.

Not always true: In our organisation, users generally download an appropriately named corporate CA and install it themselves. That doesn't imply the organisation can install whatever-it-likes-at-will. Any corporate MiTM making use of the corporate CA would have that single known CA in its chain. On the occasions when I visit my banking site using my work laptop, I always check the issuing CA, just in case.
#36: Is your corporate CA used to MITM your traffic, to authenticate corporate servers, or both?

From your description that you have to download it and install it manually, it sounds like your employer does not exercise control over your laptop? To me that suggests that there is no client-side AV or DLP process that uses the CA cert for MITM, and that the cert is only for server authentication.

If that's the case, it sounds like you aren't at much increased risk of hostile MITM from that CA, and manually checking the issuer every time you visit your bank probably isn't buying you much additional assurance.

(The MITM risk could be further reduced by name-constraining that CA, FWIW: If it's for authenticating corporate servers, it should only be able to issue certs for names under example.com.)
#37: Please bear in mind that mine is just one example of a situation where inspecting the cert details is a useful defence. In fact, my organisation does _not_ to my knowledge routinely MiTM, although it has happened at least once that I'm aware of (on that occasion by accident rather than maliciously).

Yes, the corporate CA(s) is/are used for server auth.
Yes, my employer does exercise control over my laptop, but that's not the case for everyone that has the org's CA installed (eg contractors / consultants / independent developers).
No, there's no client-side software doing MiTM.

The MiTM risk is due to the fact that web traffic passes through web filters (to check IWF lists etc). If that filtering device were to start generating certs on-the-fly using the corporate CA (this is where the above 'accident' happened), I'd have no way of knowing, except for checking the chain manually.

Name-constraining the CA isn't something an end user can do, even if the scope of all possible future domains could be reliably predicted in advance.
One point to keep in mind with regard to manual inspection of certificates is that the CertViewer only shows the certificate of the top-level page. 

If you're worried about the actions of a possible MiTM, you must navigate with the Security tab of the Developer Tools open and you must examine the certificate chain of each Secure Origin which contributed active content to the web page, as each piece of active content could be used to break the security context of the page (e.g. a JavaScript keylogger).

Unfortunately, it's a little worse than that, because you also have to do this validation on every other navigation, because an active attacker with a valid MiTM certificate could deliver his attack payload as a long-lifetime cacheable subdownload of some unrelated page. For instance, when you download http://random.surfing.example.com, the MiTM injects subreference to https://site.idont.want.mitmd.com/app.js. That JavaScript is cached by the browser and the next time you visit the site, the trojan'd script is loaded by the markup.

tl;dr: Locally-trusted certificate roots are very powerful.
#9 stated it best:
"[...] easy access to certificate information is more than a developer convenience. It allows users to judge the veracity of [...] certs."

Because of the difficulty to check the certificate in Chrome (and Edge), many of my customers advise their users to continue to use IE where merely clicking on the lock gives a straight-forward interface to view the certificate details.
One anecdotal example is the back when MD5 was compromised:  One of my clients (Fortune 50) told their (IT) users that if anyone was involved in a security event that was a result of visiting a site that still used MD5 there would be stiff consequences.  For the next few months EVERYONE in the various IT departments was verifying certificate details on all sites they visited.  Fortunately, the corporate standard was IE and it was not an overly onerous task.
#10 has it right: “There is a […] user that falls in between [‘Standard User’ and ‘Developer’]”.  I would classify that user as “Enterprise User”, however; And if the expectation is that Chrome be used as an enterprise solution, features beyond what the “Standard” (Home) user may deem relevant must be given due consideration.

Reiterating point #39: Inspection of the top-level certificate alone does not protect against these attacks.

Internet Explorer does not offer a way to examine the certificate chains used for subdownloads, meaning that any directive that users manually verify certificate chains would be hopelessly prone to failure. IE also caches the initial certificate chain and doesn't update its display even if subdownloads from the same host later return a different certificate chain. Expecting users to implement PKI policy is not likely to yield worthwhile results, even for well-trained technical users. 
#41: I'd characterize that user persona as Network Administrator (as opposed to Enterprise User, which sounds like it could be anyone in the enterprise).

I'd suggest that the way to approach the "do we have any MD5 certs lying around?" problem would be for the network administrator to write a shell script to scan the enterprise's servers, rather than manually checking them 1 by 1.

Better, the client software should refuse to use obsolete signing algorithms altogether — as Chrome did. (The same goes for validating TLS versions, TLS cipher suites, X.509 certificate well-formedness, and so on. Those are jobs for software, not people.)

I also wouldn't blame the person using the browser for the mistakes of the server operator, but that's a different question. You should advise your client to take it easier on their staff. :)

If people find themselves manually verifying certificate chains on a regular-enough basis for this UX change to be a problem, that probably indicates a deeper issue and we should look into that first/instead.

Finally, if you do find yourself doing this a lot, I find that Control+Shift+I opens the Dev Tools, and that the last DT tools tab you had selected is selected again. So if you're using the Security tab most often and not otherwise developing web applications, then Control+Shift+I by itself gets you close to the View Certificate button, and shows the rest of the security info, too.

Which is expanded beyond what we used to show in the Page Info Bubble, btw. (We have more room now.)
Comment 44 Deleted
@chromedevs:

I'd like to add some certificates manually to chrome://net-internals/#hsts
Some sites don't use HPKP but I'd like to verify the chain and pin the CA or even the site certificate.

I don't understand why the option is moved to a position that could be disabled via group policies.

#45: You can do this by pasting in the certificate's key pin into that page, yes. You can use an openssl shell script to generate the base64-encoded form of the key pin.

We didn't move the certificate details view into the Dev Tools *because* DT can be disabled; we moved it because there is more room there to show much more detail (such as the certs for all the subresource origins and the TLS connection details). The loss of access to the Certificate Viewer is an unfortunate and unintended result, and personally I'd ask organizations that turn off DT to really think hard about what they think they're gaining by doing so.

It's probably reasonable to assume that any organization that wants to exert that level of control over your use of their computers is also MITMing the network traffic.
Agree with  issue #9 ,  #10 ,  #11 ,  #13 ,  #17 ,  #22 ,  #26 ,  #27 ,  #29 ,  #30 ,  #32 ,  #35 ,  #40 .

It's really frustrating and disorienting when a feature just gets removed with no warning. It's like going to visit a local business and all of a sudden you find a wall where it used to be. You doubt yourself, and it disrupts your day until you either find an explanation or you give up.

I would add "Skeptic" to the various user roles that need this information. Chrome says "Secure". How do I know it's secure? (Or conversely, whether it's not secure?) Because Google says so? I want to see the evidence, even if I don't understand it all, so that I can make my own decision whether or not to proceed.

I like what Firefox has done. When you click the lock, here's what you see:

1. http://imgur.com/2NGffxR  A slightly more detailed summary with a right-arrow cueing you for more information.

2. http://imgur.com/a/GUYSC  Slightly more details (this example includes ownership information saying Citigroup Inc., New York, New York, US), with "More information" for the curious user 

3. http://imgur.com/5c6M7fU A dialog box with a Security tab that shows Website identity with options to View Cookies and View Saved Passwords, along with a summary of technical details covering TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, 256 bit keys, TLS 1.2 -- and most importantly a "View Certificate" button

4. http://imgur.com/a/LzCt1 Certificate Viewer -- here's all the fancy stuff, and if I'm interested I can learn more.

I'd rather see something that has fewer clicks to get where I want, but at least it has all the clues needed to get the information I'm interested in.

Please fix Chrome to make it easier to find cert info.
Owner: elawre...@chromium.org
Status: Started
In discussion with design about whether we should move forward with https://codereview.chromium.org/2676673002/ or add a new link to the PageInfo flyout.
Cc: -palmer@chromium.org
Congrats! Replacing certificate details with a useless page aimed at complete idiots, really the way to go.
Re comment 50, please keep the discussion civil, otherwise we'll have to restrict comments on this issue. Nontechnical people aren't idiots.

In general, if you don't have a new use case or piece of information to share, please just star the bug to indicate your interest rather than posting a comment.
Please stop threatening people to lock comments, it's really getting old. That's what you *always* do anyway when you do some retarded, completely counterproductive change like this and the annoyed users strike back... (The bookmarks manager for kids failed experiment was about on par with this.)

May I ask how many users requested to have the link to certificate viewer removed? 

Been trying to educate users, basic things like they should verify the certificate fingerprint with their bank before doing online banking. With "smart" moves like this and "help" pages that tell them "green is good, red is bad" and putting certificates into a place they won't ever be able to find, the effort is just wasted. 

"If you think your users are idiots, only idiots will use it."
Re #52: The Chromium team would lock comments less if people wouldn't call the devs retarded and other users idiots when they disagree. The Chrome Security team does a large amount of usability research before making any change to security UX (some of which is published, see https://www.usenix.org/system/files/conference/soups2016/soups2016-paper-porter-felt.pdf). I stand by Chromium's decision to diminish the importance of the certificate viewer. If you are training users to rely on viewing certificate details for security, then you're already screwed. The approach to security of "build highly technical tools, teach everyone to be like me" does not work.
https://codereview.chromium.org/2676673002/

>This change adds a shortcut to open the Certificate Viewer. Now if
>the SHIFT key is down when the "Learn More" link is activated, the
>Certificate Viewer will open directly.

And how am I supposed to know that I should hold the SHIFT key down? The association of Shift+action with a particular desired behavior, is extra mental baggage we have to carry around, and I think it's bad UI design.

Please provide appropriate user cues, instead.
> If you are training users to rely on viewing certificate details for security, then you're already screwed. 

You are a whole lot more screwed when you "train" them with nonsense like "green is good, red is bad", and then - ooops, another DigiNotar/StartCom/WoSign/COMODO/... 

> diminish the importance of the certificate viewer
If you want to diminish it, do something *useful*, such as, hmmm, implementing DANE/TLSA.
#55: 

> You are a whole lot more screwed when you "train" them with nonsense like "green is good, red is bad"

Perhaps you didn't see the paper I linked above. In case you missed it, here it is again: https://www.usenix.org/system/files/conference/soups2016/soups2016-paper-porter-felt.pdf

> If you want to diminish it, do something *useful*, such as, hmmm, implementing DANE/TLSA.
This bug is neither the time nor place to discuss DNSSEC. Abruptly bringing up DANE in a discussion about UX only further tarnishes your credibility in this bug. It also diminishes the massive improvements in the web PKI space spearheaded by Chrome team over the last few years (e.g. Certificate Transparency).

If you can't limit your comments to productive discussion, I hope the Chrome team locks comments on this bug.
> Abruptly bringing up DANE in a discussion about UX 

Useful feature providing information relevant to security  was moved to a place that's either extremely hard to find, or even impossible to access by users due to GPOs and similar. That feature was replaced with a pretty much useless link to a webpage, that provides no information whatsoever about how to access the original useful feature.

The developer tools in an incredibly cluttered place that's badly confusing for normal users. The certificate information does NOT have the audience limited to developers. Normal users need to be able to verify a certificate. Now, perhaps you can hold another 3-day symposium to discuss this and produce another ~20 pages of "scientific" paper. Great way to waste money. #facepalm 

Or, you could spend that time in a useful way instead -- such as implementing the DANE/TLSA feature I mentioned. That'd at least provide an actual benefit for security. 

> If you can't limit your comments to productive discussion

Put the thing back to where it was. End of "productive" discussion. After that, get back to fixing real bugs.
Labels: -Pri-3 M-58 Restrict-AddIssueComment-EditIssue Pri-2
For more context, shift-click is not the only option we are exploring. There were a a few simultaneous conversations, and we're currently working on refining some ideas from the UI team to put either a link or some details themselves into Page Info.

I'm going to restrict external comments for now, as they are not adding anything constructive at this point.
We understand that some users strongly care about getting to certificate details easily, and we want to accommodate them. If you are such a user, please star this bug for updates.
 Issue 690507  has been merged into this issue.
Opening Devtools increases the permissions of the render process (in particular giving it access to all cookies). This seems counter-productive when the user is attempting to verify whether or not the site they are viewing is legitimate.
Re comment 60: if the threat model is a compromised renderer, then viewing the certificate of the main resource of a page does not give you any assurance whatsoever that the renderer is not compromised. You'd have to verify the certificate of every subresource on the page. (See Comment 39.) Chrome has never exposed that information in a way that can be verified by an end-user.
Cc: rbasuvula@chromium.org
 Issue 692828  has been merged into this issue.
Summary: Make it easier to open the Certificate Viewer on HTTPS sites (was: Make it easier for developers to open the Security panel/cert viewer)
Labels: -Restrict-AddIssueComment-EditIssue
Further comments on why this change is needed are not required; simply star this bug for updates.

Attached is a mockup of the current plan, which adds a "Certificate" entry to the Page Info dialog. Clicking it will open the certificate viewer. This mockup depends on changes coming in Issue 657267 that will hide default permissions.


CertificateLink.png
115 KB View Download
Blockedon: 657267
Labels: -M-58 M-59
As we're blocked on Issue 657267, adjusting milestone to M-59.
Comment 66 Deleted
Why did somebody delete comment #66?

I received it via e-mail and it didn't contain anything offensive.
See comment #64; unless you have actionable feedback about the mockups in that comment, no further comments are required.
Components: UI>Browser>CertificateViewer
I thought I was not doing it right - took me about half hour to work out that it wasn't me, but a design decision - then I had to google to find-out how to view certificates!
Comment 71 Deleted
I just got how will this end, the developers of chromium  thought end user would not need  to check with Certificate , then boom~ bye the Certificate Viewer in the padlock .

But when users check with Certificate, they usually do not use it as developer but as  worried end user. (An useless support article does not help)

Deleted Comment 71 myself to add some actionable feedback 
===
how about remove the words "credit cards" ,since you did not know if is "PCI DSS" compliable
As someone who got bit by this as a web user and not a web developer, two points in addition to the serious concerns already raised:

1. The developer tools keyboard shortcut (Ctrl+Shift+I) can and commonly is intentionally disabled by Javascript, even by legitimate pages; see the WaPo paywall for a live example. A MITM could inject this.

2. The Security tab in developer tools is often visually hidden in the default layout, adding two more clicks for a total of six clicks with no cues for the first five, whereas previously there were two clicks with visual cues for both of them.
tools.png
50.4 KB View Download
"Further comments on why this change is needed are not required [as we are working on a fix]; simply star this bug for updates."

See comment 64:
https://bugs.chromium.org/p/chromium/issues/detail?id=663971#c64

(Sorry for this seemingly useless comment, but #64 wasn't that visible anymore.)
New CL implementing the mockup from #64 is here: https://codereview.chromium.org/2737413004/

As the Page Info permission simplification is not landing until later, I'm going to try getting this button in earlier behind a new flag (chrome://flags/#show-cert-button)
Oh, Google is opinionated again.
DevTools is English only, and not all people can read English.
Comment 77 Deleted
Comment 78 Deleted
this is a problem for people who are hosting sites too.  Just want to easily see if my certs are working after installing them and it's now a pain.
Labels: Hotlist-ConOps
Guys, why did you take away possibility to _easily_ access certificate information for a site with problematic certificates? I appreciate the nice user-friendly wording around different cert errors, but accessing sites with certs from untrusted roots like https://untrusted-root.badssl.com/ is really bad. The error message: "This server could not prove that it is untrusted-root.badssl.com; its security certificate is not trusted by your computer's operating system. This may be caused by a misconfiguration or an attacker intercepting your connection" is better than some of the MSFT-style errors, but why don't you include the certificate chain of the offending cert or at least the CN of the topmost CA that Chrome does not trust, like "BadSSL Untrusted Root Certificate Authority" in this example. The point is, if you can't/won't bother providing non-obscure error messages that give you some reasonable technical info, at least do not remove the ability to inspect the offending certificate _easily_; and yeah, I know I can go to DevTools->Security->View Cert, but this is sooo bad when dealing with users.

Thanks for your attention.
Explanations for some errors is forbidden by RFC (see https://security.stackexchange.com/a/111463) and better to have consistent UX for all messages.
"better to have consistent UX for all messages."

I believe this is... Misguided. Making everything the same severity, with
no obvious remedy, makes people trust the UI less rather than more. I know
many people who use old explorer, against recommendation, because of these
sorts of decisions from Google high command. You guys aren't Apple. Please
don't treat your users like they can't possibly understand what is going on.
For a good reason *not* to bury certificate information 3+ clicks deep into a UI (and removing it from the Padlock), see the recent Unicode / punycody phishing vulnerability. 

https://hackaday.com/2017/04/19/you-think-you-cant-be-phished/

That one + this change is just real anti-user.


From Comment #82 https://bugs.chromium.org/p/chromium/issues/detail?id=663971#c82
> "Explanations for some errors is forbidden by RFC [6797]"

Not relevant.  https://security.stackexchange.com/a/111463 is not applicable to making it easier to view the certificate *in all circumstances, errors or no*.  Such a feature does not violate RFC 6797 Section 8.4 (as quoted).
Reiterating Comment #64: Further comments on why this change is needed are not required; simply star this bug for updates.

Re #81: A general principle of security error notifications is that you do not want to permit an attacker to supply spoofing content to a user making a trust decision. For instance, the suggestion that the browser should show "CN of the topmost CA that Chrome does not trust" would be very bad because nothing prevents the attacker from using a self-signed CA of "Google Internet Authority".
Comment 87 Deleted
 Issue 714038  has been merged into this issue.
Project Member Comment 89 by bugdroid1@chromium.org, May 2
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d9978fcc021c14d5260d1abffc2d0b39e41018db

commit d9978fcc021c14d5260d1abffc2d0b39e41018db
Author: elawrence <elawrence@chromium.org>
Date: Tue May 02 02:45:19 2017

Add a Certificate Viewer link to the Page Info dropdown

In Chrome 55, we removed the easy path from Page Info to the
Certificate Viewer dialog. This change puts it back in a new
Certificate view just above the Cookie view.

BUG= 663971 

Review-Url: https://codereview.chromium.org/2846913002
Cr-Commit-Position: refs/heads/master@{#468539}

[modify] https://crrev.com/d9978fcc021c14d5260d1abffc2d0b39e41018db/chrome/app/vector_icons/BUILD.gn
[add] https://crrev.com/d9978fcc021c14d5260d1abffc2d0b39e41018db/chrome/app/vector_icons/certificate.icon
[modify] https://crrev.com/d9978fcc021c14d5260d1abffc2d0b39e41018db/chrome/browser/about_flags.cc
[modify] https://crrev.com/d9978fcc021c14d5260d1abffc2d0b39e41018db/chrome/browser/flag_descriptions.cc
[modify] https://crrev.com/d9978fcc021c14d5260d1abffc2d0b39e41018db/chrome/browser/flag_descriptions.h
[modify] https://crrev.com/d9978fcc021c14d5260d1abffc2d0b39e41018db/chrome/browser/ui/cocoa/page_info/page_info_bubble_controller.h
[modify] https://crrev.com/d9978fcc021c14d5260d1abffc2d0b39e41018db/chrome/browser/ui/cocoa/page_info/page_info_bubble_controller.mm
[modify] https://crrev.com/d9978fcc021c14d5260d1abffc2d0b39e41018db/chrome/browser/ui/page_info/page_info_ui.cc
[modify] https://crrev.com/d9978fcc021c14d5260d1abffc2d0b39e41018db/chrome/browser/ui/page_info/page_info_ui.h
[modify] https://crrev.com/d9978fcc021c14d5260d1abffc2d0b39e41018db/chrome/browser/ui/views/page_info/page_info_bubble_view.cc
[modify] https://crrev.com/d9978fcc021c14d5260d1abffc2d0b39e41018db/chrome/browser/ui/views/page_info/page_info_bubble_view.h
[modify] https://crrev.com/d9978fcc021c14d5260d1abffc2d0b39e41018db/chrome/common/chrome_switches.cc
[modify] https://crrev.com/d9978fcc021c14d5260d1abffc2d0b39e41018db/chrome/common/chrome_switches.h
[modify] https://crrev.com/d9978fcc021c14d5260d1abffc2d0b39e41018db/components/page_info_strings.grdp
[modify] https://crrev.com/d9978fcc021c14d5260d1abffc2d0b39e41018db/tools/metrics/histograms/histograms.xml

Status: Fixed
Fixed in Chrome 60.0.3088 behind a flag. https://textslashplain.com/2017/05/02/inspecting-certificates-in-chrome/
Blocking: 718553
Sign in to add a comment