[gFeedback] - Spike in users reporting NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM error |
|||||
Issue descriptionChrome Version: M56+ OS: Win, Linux, Mac OSX Users are reporting increase in error message NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM with release of M56. User claim 1. This issue happens even in incognito mode 2. Happens on google sites like facebook.com, google.com, mail.google.com etc 3. Have tried to run with all extensions disabled Workaround identified by users 1. Installing libnss3 fixed it for me on Debian Jessie # apt-get install libnss3-1d 2. Start Chrome with --ignore-certificate-errors flag Forum https://productforums.google.com/forum/#!msg/chrome-ru/5CGUSUh58ck/SJtSviE7AgAJ https://productforums.google.com/forum/#!msg/chrome/hdC20--zWmk/DT79TcGNBQAJ https://productforums.google.com/forum/#!msg/chrome/Qb9MviYwolI/5-SjuLn_BQAJ This could be due to sha-1 deprecation but raising this bug to keep track of user feedback. Check this for feedback stats : go/cqgqo
,
Feb 6 2017
,
Feb 6 2017
I'm fairly certain this is WontFix, but I don't want to close it out per the reporter's remarks on "keeping this open for feedback". Could you indicate what next steps you'd like to take here? It's correct that we expect there to be a (temporary) spike of errors related to the deprecation, as well as a spike if a user is running a terribly old version of NSS (as noted in the feedback, if users have not been running the 'security' version of their Linux distro, it's possible they will encounter this error). We should absolutely *discourage* users from --ignore-certificate-errors - that's a terrible solution that disables all security (... which is why we're working to remove that flag). Users who see this on mainstream sites (such as the aforementioned Facebook and Google) likely have an insecure interception product on their network - whether local antivirus running SSL interception or an enterprise middlebox. For enterprise scenarios, please have the enterprise review https://www.chromium.org/Home/chromium-security/education/tls/sha-1 and work with their middlebox vendor to ensure a timely update to address the insecurity. For the antivirus case, users should be aware that the antivirus interception almost universally make the connection significantly less secure. For the academic minded, https://zakird.com/papers/https_interception.pdf provides some of the empirical data about this, the most recent in a long series of papers (https://users.encs.concordia.ca/~mmannan/publications/ssl-interception-ndss2016.pdf for another example). The solution for these users is to find the antivirus products settings for "HTTPS inspection" or "TLS inspection" and ensure it is disabled. This is why I'd like to close it as WontFix, but happy to better understand why we'd want to keep this open. My concern is that this ends up being a 'catch-all' bug (as it did with MD5 in Issue 117834 and Issue 118706 ), and I want to make sure we can focus specific bugs on specific issues. Happy to triage any issues you see coming in.
,
Feb 7 2017
Thank you so much for sharing this detailed explanation. I am waiting for feedback following 100% Windows rollout. I will close the bug in case we don't see any more feedback.
,
Feb 9 2017
,
Mar 3 2017
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by jainabhi...@chromium.org
, Feb 6 201763.1 KB
63.1 KB View Download
65.0 KB
65.0 KB View Download
54.7 KB
54.7 KB View Download