Chrome ignores trusted Mac OS X 10.12 certificates in Login keychain
Reported by
gregoryj...@gmail.com,
Jul 19
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36 Steps to reproduce the problem: 1. Go to a web site for an internal VMware server such as ESX, VC that has (in some ways safer) self signed certificate un-breakable by internal CA compromise. 2. Note web site is untrusted. 3. Go to same site in Safari. Choose to view certificate than go to web site and add trust to site in keychain. 4. Quit and reload chrome to make sure any trust store changes are picked up (in case it doesn't automatically do so). 5. Go to same site and see that it is still marked as not-secure 6. Note that although chrome does not trust the certificate, viewing the certificate Chrome can see it's marked as trusted. (see screen shot) What is the expected behavior? Once someone has added trust to a leaf web certificate, chrome needs to trust it. Especially for internal servers. If you think Diginotar was bad, just remember that went uncompromised for years. Hygiene on the myriad internal CA's is sketchy at best and this style of certificate pinning is probably much safer than only trusting signed certificates. What went wrong? Chrome did not trust an implicitly trusted Web leaf certificate. Did this work before? N/A Chrome version: 67.0.3396.99 Channel: stable OS Version: OS X 10.12.6 Flash Version: lol don't use that stuff Perhaps not relevant but I found a problem with pinning previously here: https://bugs.chromium.org/p/chromium/issues/detail?id=95917 . Never was given credit lol but all good.
,
Jul 23
Removing from security bug queue and removing view restrictions. This appears to be failing "safe" in a not ideal way, so tracking this as a functional bug with our platform integration with Mac keychain.
,
Jul 23
Thanks for reporting this. I'm marking this WontFix/WorkingAsIntended - supporting trusted leaf certs, as Safari does, is not something we plan to support.
,
Jul 23
Hi and thanks for looking at this issue. It's great that you keep an eye open on public comment. Since it is marked as won't fix I would like to leave you with a few thoughts: When it comes to general end users trusting self signed certificates is something risky. And it is true that if a user switches between Safari and chrome the net result may be a bad security decision on the part of the user. To a more experienced user… the self signed certificate endpoint simply represents the basic ssh model. Some call it TOFU or trust on first use and some refine that term further to declare that the first use involves some level of validation on the part of the user. I have worked at a software development shop where every web interface was aimed at a system administrator. All server systems bootstrap secure with a self signed certificate to allow TLS. This is also true at the customer sites where these systems such as virtual center are deployed. If the system administrator decides that that system can be secured and only used by one or two web browsers he can make that choice, which one could argue is more secure than trusting a less securely maintained internal certificate authority. You are definitely making the right choice for an unskilled user but You could decide to allow someone with administrator access to set his machine to change the trust level for a securely maintained server with a self signed certificate. The Macintosh does have its own version of user access control which is even a bit stronger than the windows one in terms of requiring the user to authenticate. Of course the first Mac User on a system will be running as administrator no doubt . :-) you have already done the most impressive job of any of the browsers with working on the wording for the warning system and that would come into play. :-) thanks again for listening. |
|||
►
Sign in to add a comment |
|||
Comment 1 by dtapu...@chromium.org
, Jul 20