Bug 155844 – Compare leaf certificates if that's all we have in allowsSpecificHTTPSCertificateForHost

• Status: RESOLVED
• Resolution: WONTFIX
• Component: New Bugs

[Alex Christensen]

Compare leaf certificates if that's all we have in allowsSpecificHTTPSCertificateForHost

[Alex Christensen]

Created attachment 274844 [details]
Patch

[Alex Christensen]

Created attachment 274880 [details]
Patch

[Sam Weinig]

Can we test this?

[Alex Christensen]

Manually, yes.  I think this might not be the right solution, though.  See rdar://problem/25249263

[Alex Christensen]

This is not needed and not secure.

[Michael Catanzaro]

(In reply to comment #5)
> This is not needed

Agreed.

> and not secure.

Why not? If it's exactly the same server (leaf) certificate that the user previously added a security exception for, then it does not matter what the other certificates in the chain are. There's really no reason to look at anything besides the server cert.

[Michael Catanzaro]

Looking at your allowsSpecificHTTPSCertificateForHost, I'm honestly not sure what it's doing. In the soup port, we use allowSpecificHTTPSCertificateForHost ("allow" rather than "allows") to set a certificate that is to be accepted for a host even though it failed normal certificate verification (i.e. when a user clicks through a security warning). But I'm not sure that's what the code you touched is for....

[Alex Christensen]

It's always safer to check the entire chains, especially if you have the entire chains.  Hash collision attacks can make the same leaf with different chains, and the user may have accepted the certificate because of the verification of the entire chain, not just the leaf.  That said, most browser users don't even know what a certificate chain is, they just click accept so they can see what they think is the content they want to see, so allowing this at all is somewhat insecure.