Closed Bug 469263 Opened 16 years ago Closed 16 years ago

RFE - Restricting SSL Certificate Authority issuance to a particular domain

Categories

(NSS :: Libraries, defect)

Product:
NSS
Component:
Libraries
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 394919

People

(Reporter: jayhenn, Unassigned)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.18) Gecko/20081029 Firefox/2.0.0.18 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.18) Gecko/20081029 Firefox/2.0.0.18 Many large sites, including several universities and corporations, have decided to save money in purchasing host SSL certificates by forming their own Certificate Authority. These CAs then need to be installed into the browsers/OS of constituent systems in order to be used in the web of trust. The issue is that installing these Certificate Authorities currently grant carte blanche authority for accepting *any* certificates signed by them, whereas it may not be wise to assign to them the same level of trust as one would to a bona fide certificate authority. For example, someone who is a student at greatu.edu and also a client of bigbank.com might trust the Great U. technical staff to properly guard and administrate their Certificate Authority certificate for the purposes of their web mail and grades server, however should it get into the wrong hands, a malicious person might then be able to believably sign a fake certificate for https://www.bigbank.com and capture improper credentials for anyone at that university. My request is: could the mozilla TLS suite consider inclusion of an option to certificate authorities that would allow them to be only valid for a particular domain or domains? In this scenario, a student of greatu.edu would be able to trust the Certificate Authority to authenticate any certificates serving https requests within the greatu.edu domain, however if the browser were to see that CA being used to sign certificates in other domains (such as bigbank.com), it would not honor it. Another potential security benefit for this feature would be that country-specific Certificate Authorities could have their scope restricted to only authenticating certificates for domains residing in that country. ie - a Spain-only CA could be granted (by default or explicitly on a client system) only the ability to sign certificates in the .es domain. Humbly submitted, Jay Reproducible: Always
There has been RFC work in this regard - including language for specifying constraints on the names that a certificate can issue. Unfortunately, this standardization does not apply to the legacy practice of using the CN field to specify domain names, applying instead to only the fields intended to hold domain names. As a result of which, a CA could issue certs in contravention of the restrictions which browsers would continue to accept. The trick is that there is, of course, massive inertia around issued certificates now, and making the decision to stop honouring something that, while never "official", has always worked, is not one to be taken lightly. I am going to move this bug to the component where our crypto code is managed, and where I suspect it will be marked as a duplicate of an earlier bug. But I appreciate you filing it, because I think as the number of subordinate CAs proliferates, it will come to be a larger issue. I'll let those closer to the crypto code comment on, or disagree with, this next statement, but it seems to me that the easiest way to reach that goal would be to implement this stricter validation as an option, so that testers could try it, and report back on how much breakage it creates. Doing that, however, means duplicate code paths for certificate verification, which is a bad idea for several reasons, so it may be an unpalatable course of action, in the end.
Assignee: nobody → nobody
Component: Security → Libraries
Product: Firefox → NSS
QA Contact: firefox → libraries
Whiteboard: DUPEME?
Summary: Request ability to increase security by restricting SSL Certificate Authority to a particular domain → RFE - Restricting SSL Certificate Authority issuance to a particular domain
It has been discussed recently at m.d.t.c. and for naming constraints to be effective, NSS would need to stop honor the non-standard CN field for server certificates. This however is something which requires a concerted effort - Johnath, you could bring this up at the EVB forum perhaps.
Johnathan, your analysis seems just right. Regarding implementing a change that allows name constraints to constrain Subject Common Names, if the short-term goal is so that "testers could try it, and report back on how much breakage it creates", we could do that with a patch and a test build using Mozilla's "try server". Testers could try the trial build to see how badly things break. I'm sure that Mozilla would not want to unilaterally stop supporting DNS names in Subject Common Names by itself, because in the short term, that would only driver users to other browsers. But IF we got all the browser vendors to agree to decommit support for Subject Common Names at some date in the future, say, end of 2009 or end of 2010, such that all browsers decommit it together at the same time, then it seems feasible.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
Whiteboard: DUPEME?
What if we were to add a simple attribute in Mozilla-specific metadata that allowed such a constraint to be applied?
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Please continue this discussion in bug 394919
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → DUPLICATE
This bug is bigger than bug 394919. Once common names are subjected to the proper level of scrutiny, we would still need every organizational CA to apply for a name-constrained certificate from a public CA, and we would need public CAs that offer such certificates for a reasonable price. CAcert, for example, doesn't offer them (http://wiki.cacert.org/SubRoot). So I request that this bug be unduped from bug 394919. I have to believe this issue is really common. As a college student with a moderate interest in open-source software, I'm hitting it on five domains: umd.edu, cs.umd.edu, math.umd.edu, samba.org, and fedoraproject.org . My current solution is to add a security exception for each server after manually checking its certificate against the proper authority with "openssl verify". This is a PITA, and the typical user without the sophistication to do this has the choice to compromise his/her security by either adding exceptions willy-nilly or trusting an organizational CA for the entire web.
To be clear, the enhancement I'm seeking here that isn't part of bug 394919 is a box in Firefox's "Edit CA certificate trust settings" dialog that lets me limit trust to a specified domain.
Matt, As I perceive it, the difference between what you're requesting, and what was being discussed back in late 2008, is WHO specifies the domain restrictions on the CAs. In the original proposals, the restrictions would be imposed either (a) by the root CA itself, or (b) by Mozilla Foundation (or Mozilla Corporation, not sure which) as a matter of policy, at the time that the CA certificate was approved for addition to Mozilla's root CA list. You're raising the specter of a user adding a root certificate from a root CA that has not been approved by Mozilla Foundation AT ALL, and wishing to impose on that newly trusted certificate some domain name constraints of the user's own choosing. I agree that the feature of which you're thinking is not entirely contained within bug 394919. The feature you want has (at least) 3 components, which are: 1) the ability to impose domain name constraints on all relevant domain names ina cert, including those in Subject Name Common Name attributes. This is the subject of bug 394919. Unless and until this bug/feature is fixed or implemented, nothing else that I will describe below matters one whit. 2) The ability to store a set of externally imposed domain name constraints and a pointer to, or copy of, the certificate on which they are imposed. This might be done in NSS, or might be done in PSM. That's a major design issue. This part would be needed whether the constraints were imposed by the user, or by Mozilla Foundation, but not if the constraints are imposed by the root CA itself. 3) Some UI in PSM by which the user can impose the domain name constraints that he wishes to impose on CA certificates of his own choosing. This part applies purely to PSM, not to NSS (NSS does no UI). I'd suggest that you file a new Enhancement request, against product Core, component: Security/PSM in which you request UI by which the user can impose his own name constraints on CA certs of his own choosing. You can cite this bug, and bug 394919. Definitely cite bug 394919 as a dependency (or "blocker") of your new enhancement request. But understand that Mozilla may or may not decide to implement your request, and that, in any case, unless and until bug 394919 is resolved, nothing else that anyone does about this issue will have any effect. You might wish to discuss this issue in the mozilla newsgroup/mailing list named mozilla.dev.security.policy. I think you'll find lots of people there who'll be interested in this subject (but, maybe not).
Isn't adding an exception for a whole domain what you want? E.g. *.domain.com in the servers exception tab would match anything in that domain name AND by that specific CA. Just my 0.02$
Re comment #9: That doesn't work. If I enter https://*.fedoraproject.org in the "Add Security Exception" dialog (even coming from an "Untrusted Connection" error on koji.fedoraproject.org), Firefox unsurprisingly fails to fetch the certificate. And if I edit cert_override.txt to change my existing exception for koji.fedoraproject.org to *.fedoraproject.org, I get "Untrusted Connection" again on koji.fedoraproject.org.
Did you try without https:// in the Server section? If it fails I suggest to open a new bug with this feature requested.
I tried entering just *.fedoraproject.org and Firefox still failed to fetch the certificate. I didn't expect that approach to work, and given that it actually doesn't work, I have no interest in pursuing it further. Instead, I'll enter a RFE for the UI in comment #7.
I found bug 501697 and will hop on board there instead.
You need to log in before you can comment on or make changes to this bug.