Chrome falsely accepts a version 2 certificate which has extensions
Reported by
chen...@stu.xidian.edu.cn,
Mar 2 2017
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 Steps to reproduce the problem: 1. To open the "setting" menu of Chrome. 2. To click "show advanced settings". 3. To click "HTTPS/SSL:Manage certificate ..." 4. To click "Authorities" tab and to click "import". To select "basicCA.pem" which is attached to this report and to select "Trust this certificate for identifying websites". 5. To click "Your Certificates" tab and to click "import". To select "7.p12" which is also attached to this report and input the password "123654". 6. Chrome accepts "7.p12" without any warning and Chrome shows that "This certificate has been verified for the following useages: ...". 7. To select the imported certificate and to click the "View..." button, you will find in the "Details" that its version is "version 2" and that it has extensions. What is the expected behavior? Chrome should reject the certificate. What went wrong? Sec. 4.1.2.1 of RFC 5280 requires that "If no extensions are present, but a UniqueIdentifier is present, the version SHOULD be 2 (value is 1); however, the version MAY be 3". Therefore, the version 1 certificate which has issuer unique identifier should be rejected. Did this work before? N/A Chrome version: 54.0.2840.59 Channel: stable OS Version: 1604 X64 Flash Version: Shockwave Flash 20.0 r0
,
Mar 2 2017
Internals>Network>Certificate is the right category
,
Mar 2 2017
I agree that a version 2 certificate with extensions should be rejected. However the certificate validator that is permitting this here is the platform verifier (the bug says Linux, but your user agent says Windows -- which platform do you experience the bug on?) While we could add further restrictions in Chrome that checks for this case where the platform verifier otherwise allows for it, I don't think there is much value in doing that. From a security perspective, this is a certificate with a valid signature that chains to a trust anchor. So really it is a misissued certificate; a trustworthy CA should not have signed such a TBSCertificate in the first place. I would recommend closing this as WontFix, and following up with a bug against the underlying verifier.
,
Mar 3 2017
Thank you for your agreement! We conducted experiments on Ubuntu v1604 x64. When we were filling the form provided by Google, the sentence "UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36" did not exist. However, the sentence appeared after we submitted the filled form. We do not know where it comes from. As for the fixing problem, it represents the attitude of a great company such as Google to its users. As we know, matrixSSL has forbidden version 1/2 certificates except v3 ones. As for the security perspective, we are not clear how it will be used by others since we are not good at lauching attacks currently. Therefore, we reported it as an ordinary bug instead of a security bug. Thank you all for your hard work! Best wishes!
,
Mar 13 2017
Thanks for the bug report! As we don't believe this results in a security issue or significant compatibility issue, we will close as WontFix. In general we aren't going to try and solve all the problems or inconsistencies between the various platform-specific certificate verifiers (libpkix in this case) that Chromium uses.
,
Mar 21 2017
For comparison, it looks like Firefox intentionally allows treating v1 certificates as if they were v3, on the grounds of compatibility: https://dxr.mozilla.org/mozilla-central/source/security/pkix/lib/pkixcert.cpp?q=pkixcert.cpp&redirect_type=direct#110
,
Mar 22 2017
We have seen the content in this link. Don't you think it is not right in logic for them to deal with v1 certificates in this way? |
|||
►
Sign in to add a comment |
|||
Comment 1 by jkarlin@chromium.org
, Mar 2 2017