For sale: Trusted root SSL CA signing certificate
globalsign.com
globalsign.com
It may also give you the power to issue certificates for any name or, hopefully, it will be name constrained([1]). That's up to the CA however. The CA is taking on responsibility for all certificates issued under these cross-signs when they do this. Mozilla is currently in the process of requiring that these enterprise certificates either be name constrained, or be audited at the same level as roots.
I think Symantec will sell you much the same thing: http://www.trustico.com/material/DS_GeoRoot_0205.pdf
This is one of the reasons that we are pushing Certificate Transparency: http://www.imperialviolet.org/2012/11/06/certtrans.html
[1] X.509 Name Constraints allow an intermediate or root, CA certificate to be limited to issuing certificates within a certain scope, i.e. a domain. https://tools.ietf.org/html/rfc5280#section-4.2.1.10
But there are two ways to use Name Constraints: they can be marked critical or non-critical.
Critical Name Constraints are great, but they will cause anything that doesn't support Name Constraints to reject the certificate. This is obviously a problem because few deployments have much control over their client base.
Non-critical name constraints provide a security benefit to clients that support them without affecting those that do not. Clients that don't support them are vulnerable to misuse of the constrained certificate, of course, but since the alternative is often an unconstrained, CA certificate, it's still a clear win.
Here is a summary of where clients were a year ago, opera has support now so its slightly out of date - http://unmitigatedrisk.com/?p=24
Also, other people in this thread have commented that the 4.2.1.10 name constrained thing isn't really implemented anywhere?
That's very different from, say, TrustWave, who issued such a certificate with full knowledge of what it would be used for.
I agree that this isn't the best of situations. Certificate Transparency is the best answer that we have, but it's going to take a while to deploy.
Earlier today I thought that nameConstraints was ineffective, but it seems to turn out that the problem is mostly limited to Safari.
I guess all iOS devices are still "vulnerable" to a rogue nameConstrained CA then - assuming they share code with Safari?
There's a huge difference in security between a cryptographic-strength guarantee enforced by reliable technical mechanisms and the security provided by a civil law contract enforced by an audit regime. Also, note that the world's true Relying Parties (i.e., every web user and server operator who could potentially be MITM'd by this private key) are usually not formally acknowledged as parties to these contracts and as such have no say in their creation or even knowledge of their existence.
The only way to know how a certificate may or may not "be used" is by looking at how the source code of all client applications to see how they will interpret it.
How many of the cases of trusted-root chained MITM seen in the wild (Iran, Turkey) were prevented by the business agreements making MITM "forbidden"?
They are used by large environments like Google and Microsoft to issue certificates for their assets and people.
They are contractually and technically (new but now standard) prohibited from using them for malicious use cases including MiTMs.
They are audited to conform with those terms and must meet the same requirements a certificate authority in the Mozilla guidelines.
I feel like I have to be misunderstanding something about this page and the attached data sheet, because it seems to be promoting a service that directly contravenes Mozilla's policies: you're not allowed to use CA=YES certificates to enable enterprise MITM tools.
Furthermore, minting certificates for a large and growing number of popular web properties --- which is something you end up doing almost immediately when you set up enterprise web proxies --- is a good way to get noticed by Google's SSL/TLS team and shitcanned from Chrome. That's a consequence of Google's certificate pinning regime, which operates incidentally as a kind of surveillance network for certificate forgery.
Edit: Apparently this is the enterprise cross-signing use case. So, ideally they're using name constraints and their issuing policy would need to comply with the browser and OS root CA policies.
That said, I feel like our team and Mozilla's are making some real progress here on a path toward a far more transparent and reliable CA system. And things like pinning and reporting are useful both as stopgaps and longterm tools for more security conscious site operators.
If you can only issue certificates for your domains and subdomains, then it's not an issue. This sounds more like an alternative to setting up a Windows Enterprise CA and then distributing the root cert to all of your non-Windows clients.
e: Think of it like this: instead of just giving you a wildcard cert, they're letting you make individual certs for your subdomains yourself.
There have definitely been attempts to build products that use technical controls in the CA product to enforce the restrictions --- ie, the customer gets a locked down box that tries to make sure it isn't misused --- but as I understand it, these are no longer OK to sell.
I saw this on another site discussing Trusted Root certs:
> What is required to get a Root Signing Certificate?
> Each certificate provider has different requirements for trusted rootsigning certificates. Most will require something similar to the following:
> - Substantial net worth and insurance
> - A Certification Practice Statement (CPS) outlining your exact policies on issuing and managing certificates.
> - A FIPS 140-2 Level 2 compliant device to generate and managing your root certificate keys.
So it sounds like they are handing out the keys and then hoping that auditing/policies/insurance are in place to cover themselves.
For those not versed in this particular jargon: "FIPS 140-2 Level 2" pretty much means "tamper-evident seal" (part of a sticker over the opening stays on the box when you try to remove it - this is only slightly more secure than I make it sound.) Note also that this does not appear to include any restriction on the computers which can say "please sign this certificate for me". Sensible CAs will have extensive physical security around such devices, but can we count on anyone with $BIGNUM dollars to get this right?
On a cryptographic level, there is the paper discussed at http://blog.cryptographyengineering.com/2012/06/bad-couple-o... (http://hal.inria.fr/docs/00/70/47/90/PDF/RR-7944.pdf), which totally pwns some well-regarded smart cards using a (really nifty improvement on) a years-old crypto attack, then goes on to note that the authors really wanted to try their hand at a couple of HSMs too but lacked the funds. Which doesn't prove anything about HSMs, but doesn't exactly give one a lot of confidence either.
So yeah, they do seem to be handing out the keys and hoping that auditing/policies/insurance covers it.
EDIT: Changed RFC number from 2459 (obsolete) to 5280.
Do you see the expressions of surprise about this policy here on HN? These are the world's more informed client application developers.
Consider now that your home router's firmware update client, your server's IPMI, and the entire global network for real-time trading of [strategic material] was written by developers to RFCs that told them they had absolutely no reason to implement the Name Constraints extension because if it ever appeared, it was guaranteed to be marked 'critical'.
Careful. You're going to show up on "Shit HN Says".
4.2.1.10. Name Constraints
...
Conforming CAs MUST mark this extension as critical
I think this is wrong both in principle and in practice.
Whether or not one ought to rely upon a CA that would sell such a cert to a 3rd party is a question of trustworthiness which is (wisely) left out of scope for the RFCs.
Client app developers have a "root CA inclusion program" for this reason. It's more of a business process than a technical one. Mozilla's is probably the most publicly open and well-documented inclusion policy. I believe it also explicitly forbids the practice you describe.
http://www.mozilla.org/projects/security/certs/policy/Inclus...
We consider verification of certificate signing requests to be acceptable if it meets or exceeds the following requirements: all information that is supplied by the certificate subscriber must be verified by using an independent source of information or an alternative communication channel before it is included in the certificate; [...] for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf;
This requirement clearly cannot be met by a root cert under which sub-CAs with no (or noncritical) name constraints are given to 3rd parties.
Here you go: https://wiki.mozilla.org/CA:Communications February 17, 2012 1) Subordinate CAs chaining to CAs in Mozilla’s root program cannot be used for MITM or “traffic management” of domain names or IPs that the certificate holder does not legitimately own or control, regardless of whether it is in a closed and controlled environment or not. Please review all of the subordinate CAs that chain up to your root certificates in NSS to make sure that they cannot be used in this way. Any existing subordinate CAs that can be used for that purpose must be revoked and any corresponding HSMs destroyed as soon as possible, but no later than April 27, 2012.
Note the word "cannnot" there. It's not "prohibited by contractual agreement", it's "destroy the HSMs containing the private keys".
Again GlobalSign's policies do not allow the use of certificates that chain to our roots to be used for MiTM purposes (or other malicious use cases for that matter) and we have controls in place that protect against such things occurring.
http://www.mozilla.org/projects/security/certs/policy/
http://social.technet.microsoft.com/wiki/contents/articles/3...
Because if they indeed are offering CA=yes certs, that's just plain unbelievable.
If someone wants to be fully independent, the only way is to accept to be treated as a CA in their own right (and undergo all audits, etc).
First off so there is no ambiguity let me say clearly that GlobalSign's policies do not allow the use of certificates that chain to our roots to be used for MiTM purposes (or other malicious use cases for that matter).
That said there are lots of reasons why a company might want or need to operate their own in house PKI and have that PKI trusted; one easy to understand case is google; though they are not our customer they operate their own in house PKI that they use to issue the many many SSL certificates their infrastructure utilizes: https://sslcheck.x509labs.com/en_US/sslcheck?host=www.google...
But SSL is not the only reason one might want to operate their own internal PKI that is trusted, other cases include business to consumer and business to business communication (for example S/MIME).
As for how we (and other CAs) go about ensuring trusted root deployments are not used for MiTM cases, there is the obvious contractual obligations that are accompanied by audits but we also were the first publicly trusted CA to use Name Constraints to deploy qualified subordination to these deployments (which has become a requirement now – it was not when we started).
This approach technically limits what domains these enterprise trusted root customers are trusted by mainstream clients for - see: http://unmitigatedrisk.com/?p=24
There are also a set of “Trusted Root” customers who are in the process of becoming trusted by browsers (which can take 3-5 years) where we will cross-certify their root enabling them to be trusted while their own key material becomes ubiquitously trusted.
I should also add that Mozila’s root inclusion policy (as well as Microsoft’s and the other root programs) allow for these scenarios.
I hope this helps clarify, please let me now if you have any questions.
Ryan Hurst CTO, GlobalSign ryan.hurst@globalsign.com
Do any of your offerings provide customers with custody of an X.509 certificate that chains to a GlobalSign certificate that is trusted by any of IE, Mozilla, Chrome, or Safari where that X.509 certificate has CA:TRUE in its Basic Constraints?
By "custody" I mean that the private key corresponding to that certificate is held in some fashion on customer premises, regardless of the technical controls implemented in the device in which it's held.
However our policies have always been that those entities need to meet the same requirements (operationally, etc) as we do which includes not participating MiTMs with any key material associated with that PKI.
Those customers who do have such CAs are also (normally) subject contractual restrictions to what namespaces they can issue against and they are always subject to audits where we confirm their usage is consistent with those policies.
In the very rare cases where that is not the case they are audited to meet the exact requirements we meet - we almost never do this.
It’s a difficult problem as a whole, there are legitimate use cases that help secure the web and enable commerce that are best served by having publicly trusted certificates our goal as an industry is to find ways to address those needs while reducing the risk.
To that end when I joined GlobalSign a year ago (from Microsoft) one of the first things I did was started here to advocate the industries use of name constraints as a means to reduce risk for all parties involved in these scenarios.
Ryan
Are the nameConstraints extensions on these certs marked critical? I didn't know they could even be non-critical (one RFC says they can't) but 'agl says otherwise and would know.
When it comes to crypto and the level of trust that the entire world puts into this, this is the only definition of "MITM cert" that matters.
It's interesting that we bring this up, because it makes me now think that maybe the best way to jumpstart TACK is to implement it as a library that IOS programs can use.
Ryan
That said, if we're (a) in a universe where critical:true nameConstraints are enforced on the last couple versions of Safari, Chrome, Firefox and IE, and (b) you're only issuing critical:true nameConstraints certificates, it probably isn't worth being alarmist here.
In any case, thank you for commenting here. I had hoped to have a chance for once to join my fellow HN commenters in a rousing game of baying at the moon over the injustice of it all, but instead find myself amidst a carnival of X.509 learning. Hooray?
TACK can't get here fast enough!
Moving forward Name Constraints will be adopted (finally) which is a good thing. Today it is supported by the majority of devices on the internet and given how fast browsers update now it wont be too long until the extension can be marked critical.
On a semi-related note check out how many governments have their own roots : http://unmitigatedrisk.com/?p=181
Will you reissue them all (for free) once you decide to start marking new ones critical? Will you require all such entities get reissued certs? Can you contractually require that they destroy the old certificates?
Then there's the matter of how problematic OCSP is; even if you revoke the old ones, it may not matter.
Said migration would ave no cost from us on the customer, I can't speak to what the other CAs do.
Name Constraints support is pretty good in modern certificate libraries. It's certainly in CryptoAPI these days which accounts for the bulk of users.
But there are two ways to use Name Constraints: they can be marked critical or non-critical.
Critical Name Constraints are great, but they will cause anything that doesn't support Name Constraints to reject the certificate. This is obviously a problem because few deployments have much control over their client base.
Non-critical name constraints provide a security benefit to clients that support them without affecting those that do not. Clients that don't support them are vulnerable to misuse of the constrained certificate, of course, but since the alternative is often an unconstrained, CA certificate, it's still a clear win.
Many libraries built these into regression tests for their chain engines and the suite covers name constraints pretty good.
Deploying non-critical name constraints to the existing community of subcas reduces the risk for everyone and gives apple time to fix their aged tls / certificate stack.
What economic benefit does it provide that outweighs the reduction in security experienced by users of Safari and countless other non-browser clients by allowing Google to be in possession of a private key that can impersonate the identities of arbitrary TLS servers?
Beyond that, Google operates one of the four most important clearinghouses of Internet trust by managing the Chrome certificate policy. It's a little silly to suggest they're pulling a fast one on the Internet; if you don't trust them, you have bigger problems than nameConstraints.
Google did not create the subsidiary CA problem.
Perhaps if you were to mentally s/Google/that hospitality company customer of Trustwave/ perhaps you could see my point more clearly.
RMH chose Google. For him, it was a brilliant rhetorical strategy :-)
So who would be a good example of an organization possessing a 3rd party sub-CA for me to advance my argument? It's much harder because most of them are already relied upon in other critical ways, or are kept secret under confidentiality.
"That hospitality company issued a sub-CA by Trustwave" is the best I can come up with at the moment.
The sole raison d'être for the entire CA infrastructure is to prevent active MITM-style attacks. So from that perspective what you said is positively Orwellian.
Noncritical name constraints absolutely do affect clients that don't support them. It reduces their security by making them vulnerable to MitM!
The entire purpose of the critical flag was to allow evolving the PKI system without reducing security for existing systems. We ought not set the flag FALSE because the CA's big customers prefer flexibility to the security of the whole ecosystem.
Clients that don't support them are vulnerable to misuse of the constrained certificate, of course, but since the alternative is often an unconstrained, CA certificate, it's still a clear win.
A false dichotomy being imposed by a well-funded minority for which it serves their interests.
Critical nameExtensions protect Chrome, IE, Firefox, and (because Safari will barf on them) Safari.
NO nameExtensions protects nothing.
Adam's point is simply that non-critical name extensions strictly dominate unconstrained certificates. His point isn't Orwellian at all.
Don't you see how, once again, the CA industry has shifted the debate from the level of security everyone expected them to provide all along to another lesser of two evils?
The discussion isn't about whether or not we must require name constraints on 3rd-party sub-CAs to be marked 'critical'. The issue is that the world of SSL/TLS client application users and developers believe, expect, and rely upon the non-proliferation of private keys with the ability to forge identities for the servers to which they connect.
So, yeah, maybe it's more Overton than Orwellian.
The stuff he's talking about does exactly the opposite of what you claim it's surreptitiously doing.
But this is not about the the person or the corporation. It's about the users of PKI and the massive existing code infrastructure (not just browsers) they rely upon today and the attacks to which our systems may or may not be vulnerable under the different CA issuance policies.
RFC 5280: 4.2.1.10. Name Constraints: Conforming CAs MUST mark this extension as critical
Sure, there are times when bending the rules of an RFC may be the right thing to do. But breaking this rule violates an interface contract critical for security, thereby retro-actively reducing the security of conformant implementations.
Therefore, users and developers of existing security products must oppose this violation of RFCs.
Of those four organizations, I feel like I could make a strong argument that Google is the one with the best activist stance on improving Internet privacy, the one doing the most to improve the core HTTPS infrastructure.
The RFC you're citing is the product of a bunch of people sitting in a room talking. RFC policies do not bind organizations. About the most you can say about them is that they mean the HTTPS cabal is using something other than HTTPS. Ok, but that is the mother of all [sp]e[md]antic arguments. (Can we use "spemdantic" from now on?)
If Name Constraints are indeed important, I'd much rather see the CAB Forum first work with Apple until support is universal (or reasonably-well supported; whatever that means), and then start to use them.
While I'm not alarmed by what GlobalTrust is doing, I think CA's should not be in the business of selling CA=YES certificates to other organizations. No matter what X.509 allows them to express.
But at the end of the day the world needs to have secure SSL/TLS applications. This requires it to be possible for "one skilled in the art" to be able to design and implement an application using this protocol. He must be able to understand the stated and implied requirements for security in order to have any chance of producing a secure application. And a secure application needs not just to interoperate well, but it must also refuse to interoperate insecurely, prevent impersonation, and so on.
So if we can't end up with secure applications by writing them to the RFCs, then what the hell do we write them to?
Where is this document defining all the ways in which CAs now and in the future feel free to relax the identity constraints which rely upon them to provide?
If it is not possible for a competent and conscientious software developer to write a client application from existing documentation, rely upon a set of root CAs, and end up with a countably finite and well-bounded number of private keys in existence that can impersonate legitimate servers to his application then the CA system has failed in its one and only mission.
You've fallen for the old switcheroo.
Nevertheless, if you want to sell sub-CAs with critical name constraints to 3rd parties from your widely-trusted root, fine. That's been a defined feature of PKI for a long time.
If you want to sell sub-CAs with noncritical name constraints to 3rd parties, that's fine too. Just do it from a different set of roots than the ones that we all agreed to rely upon, precisely because we had our expectations set that they would not do that sort of thing.
"We" are citizens living in repressive regimes who rely upon HTTPS to protect our emails arranging our family's emigration and escape from persecution.
"We" are software developers relying on HTTPS to secure our connections to Github to prevent attackers from inserting backdoors in our codebase.
"We" are the servers who rely upon the HTTPS client to do a thorough job of proving the absence of an active attacker on the network between us.
"We" are the relying parties.
You're probably correct in that "4 organizations in the world need to agree on TLS PKI policy", but that doesn't make it a good thing. The problem is that these N ~= 4 organizations tend to not see themselves as directly bearing the risk of a security failure in the trusted root program. The true Relying Parties are greatly underrepresented in this discussion.
I see people from many of these orgs here in this HN discussion. And, yeah, you can count on some folks getting an earful as soon as the occasion arises.
For anyone coming to RSA 2013 San Fransisco we'll be having an SSL/TLS panel discussion. This topic seems likely to come up.
It is allowed by all the root programs.
The practices (both technological and procedural) we put around our program are some of the best in the industry, we take this responsibility very seriously.
More over we very rarely do it and instead work with customers to utilize our managed PKI offerings where we operate the infrastructure on behalf of the customer.
Really? Care to name names?
If this is so common, allowed, and totally above-board, why is the industry being so secretive about it?
Why won't the CA industry disclose even the number of sub-CA (constrained critically, noncritically, or not at all) private keys in possession of 3rd parties (HSMs or no)?
As for disclosing all CAs have agreed to disclose -- no secret here at all.
And clearly from this thread I am being very open :)
This is not directed specifically at you @rmhrisk, but it's really disappointing how everyone involved in PKI seems to have a systematic habit of pretending like clearly identified potential risks and vulnerabilities are equivalent to impossible until (and sometimes even after) they're actually caught being used in an actual exploit.
With that said GlobalSign has committed to implementing CT and we hope all other CAs agree to do the same as Adam points out earlier in this thread its the way to bring the desired transperancy.
That said it alone inst enough either, to start we also need TACK (and/or HSTS pinning), CAA, robust revocation checking and Name Constraints.
And while conversations like this are uncomfortable (certainly for me being on the receiving end) I think they help too.
I could get on board with that.
I also believe that certificate transparency by itself is insufficient and the other items I mentioned are also needed.
And from https://wiki.mozilla.org/CA:SubordinateCA_checklist
"Third-party private (or enterprise) subordinate CAs: This is the case where a commercial CA has enterprise customers who want to operate their own CAs for internal purposes, e.g., to issue SSL server certificates to systems running intranet applications, to issue individual SSL client certificates for employees or contractors for use in authenticating to such applications, to issue SSL certificates for pre-approved domains that are owned/controlled by the customer, and so on.
These sub-CAs are not functioning as public CAs.
For these sub-CAs we need assurance that they are not going to start functioning as public CAs. Currently the only assurances available for this case it to ensure that these third parties are required to follow practices that satisfy the Mozilla CA Certificate Policy, and that these third parties are under an acceptable audit regime.
In Bug #394919 NSS is being updated to apply dNSName constraints to the CN, in addition to the SANs.
We plan to update our policy to require CAs to constrain third-party private (or enterprise) subordinate CAs so they can only issue certificates within a specified domain. See section 4.2.1.10 of RFC 5280."
Astonished, you would hope this would be sent in covert emails or just suggested to chiefs etc. but man ON THE INTERNET!
Look: we sell these FBI badges for use in your business whenever there are some policy issues... your personnel will trust the wearer!
Sorry.
open /System/Library/Keychains/*
I don't run OS X anymore, but I was not happy with what I saw at the time.
So what you really need is something that watches every CA cert your browser ever sees and then does detective work on them. Which is sort of what Moxie Marlinspike's Convergence project was doing.
(I already used keychain access some time ago to untrust CNNIC, Türktrust and Diginotar earlier)
Code signing.
EKU is used to restrict what certificates are good for, this bug explains a behavior the majority of code signing delegation is dependent on - https://bugzilla.mozilla.org/show_bug.cgi?id=321156
Basically a parent ca can say, I trust you for S/MIME certificates but not for SSL or code signing -- this is a common scenario.
Additionally root programs do not delegate code signing to all roots.
Basically the ability to do code signing is rarely delegated to a root and doing so to subordinate CA outside the CAs control should be even rarer.