501697 - Certificate manager could allow user to restrict the domain/realm of authority for a CA certificate

Status: RESOLVED WONTFIX

(Core :: Security: PSM, enhancement)

Description

[Dominic Hargreaves]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.11) Gecko/2009061212 Iceweasel/3.0.6 (Debian-3.0.6-1)
Build Identifier: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-3.6a1pre.en-US.linux-i686.tar.bz2

A nice feature to add to Firefox would be the ability to confine the authority of a CA certificate to a list of URL patterns. For example, A private CA might exist to authenticate the servers of a given organisation, so I will install the CA certificate into my browser, but I would like to confine the risk of that CA being compromised to my access of sites run by that organisation.

A compromise in this case includes a deliberate attempt by that organisation to hijack my sessions to other websites.

Reproducible: Always

Steps to Reproduce:
1. Import a new private CA and choose to trust it for the authentication of web sites, for the purposes of authenticating their own sites.
2. Imagine a malicious admin in control of that CA intercepting my traffic and intercepting an SSL session to my bank
Actual Results:  
The SSL session to my bank would be compromised.

Expected Results:  
The SSL session to my bank would not be compromised, since I would have been able to restrict the trust to the organisation's own domain.

Comment 1

[Johnathan Nightingale [:johnath]]

There are cert-level semantics for restricting the issuing of CAs to certain domains, but I'll bump this over to PSM to discuss the merits of client-level control.  I think it's a relatively niche feature, and might be better served by an extension than inclusion in the core product - but it's a neat idea, too, so I don't want to WONTFIX it without getting some others to chime in.  It may be, for instance, that even if we don't choose to include the UI, we can make the APIs easier for an extension to use.

Comment 2

[Matt McCutchen]

I don't think this is niche at all: private CAs are very common and I don't know of any that are using the "cert-level semantics" yet, so the only practical solution for the near future is user configurability.  See bug 394919 comment #6.

Comment 3

[Matt McCutchen]

Here's a discussion of the reverse scenario where a user trusts a particular private CA for a domain, to the exclusion of all other CAs:

https://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/23ddc03fd2376e97

This use case had crossed my mind too, and it would be nice to have.

In addition, Bob Relyea suggested the technique of re-signing CA root certificates with one's own key to apply the desired name constraints, which applies equally to both scenarios.  I tried that, but I was unable to access https://koji.fedoraproject.org with my client certificate because Firefox sent my re-signed root along with the client certificate and the server (understandably) rejected the root as untrusted.  In addition, this technique is probably too hard for the average Firefox user to perform.

Comment 4

[Matt McCutchen]

Oops, in comment #2 I meant to cite bug 469263 comment #6.

Comment 5

[Daniel Veditz [:dveditz]]

I believe Bob (or maybe it was Nelson) told me that supporting cross-signing as you describe in comment 3 would require us using CERT_PKIXVerifyCert() to verify certs. Currently we still use the older CERT_VerifyCert and only use PKIX for EV certs.

Comment 6

[Matt McCutchen]

This feature would most likely use the same code path as name constraints in certificates and would therefore rely on bug 394919 to affect common names.

Comment 7

[jayhenn]

FYI - it might be advantageous to enable this feature even for pre-installed CAs, as a man-in-the-middle attack with access to an authorized CA could potentially cause a compromise of SSL sessions.

For example, a bit of US traffic was recently routed through a foreign country whose government has access to authorized CAs:
        http://www.nationaldefensemagazine.org/blog/Lists/Posts/Post.aspx?ID=249#

Comment 8

[jayhenn]

FYI - this functionality may be helpful in cases like the Comodo SSL incident, where .com SSL certificates were successfully signed by a CA based in Southern Europe by attackers:

http://threatpost.com/en_us/blogs/phony-web-certificates-issued-google-yahoo-skype-others-032311

Comment 9

[Matt McCutchen]

(In reply to comment #8)
> FYI - this functionality may be helpful in cases like the Comodo SSL incident,
> where .com SSL certificates were successfully signed by a CA based in Southern
> Europe by attackers

It won't work, because Comodo issues legitimate certificates in .com as well.  If you'd like to help solve the general problem, please join the discussion:

https://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/f29806f084b329f6

Comment 10

[Dana Keeler (she/her) [:keeler]]

This would be a colossal footgun for the vast majority of users. Also, the population of users that would find this useful is so small that we can't possibly justify the engineering effort to implement this.