7 ms·
For sale: Trusted root SSL CA signing certificate
- 0x0 14y agoCan someone explain to me why these guys are still allowed to be present in, for example, the OS X trusted key store?
- rincebrain 14y agoI would bet that, in 7 days or less, either this link will be dead, or they won't be...
- guns 14y agoIf you feel uncomfortable about this trust decision made for you by OS X, I would suggest taking a peek at the entire set of trusted root certificates in /System/Library/Keychains/ (note that Keychain Viewer hides one of them from view by default, so run: open /System/Library/Keychains/* from a shell). I don't run OS X anymore, but I was not happy with what I saw at the time.
- tlrobinson 14y agoI wish there was a tool for auditing root certificates. Like point out which certs are owned by governments, reputation of companies, etc.
- tptacek 14y agoThe problem with that idea is that the CA root store on your computer is a tiny subset of all the CA=YES certificates out there, because of intermediate chained CA certificates. 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.
- 0x0 14y agoI double clicked the "SystemCACertificates" and that seems to have added a fifth keychain to keychain access (it used to display four, I think). That didn't seem too bad, a few Geotrust and VISA items, and a bunch of DOD ones? Well, I guess it's a bit weird to have 20+ DOD certificates there. (I already used keychain access some time ago to untrust CNNIC, Türktrust and Diginotar earlier)
- sharth 14y agoJust to make sure I'm not confused. I can purchase a root certificate from this company? And this certificate will be seen as valid by the major browsers?
- pfortuny 14y agoIf I am not mistaken, that is exactly what they are claiming (albeit stressing that they are issued to be used for subdomains) but others have pointed out that that limitation is unenforceable (i.e. inexistent).
- tptacek 14y agoSince this comment is pegged to the top of the thread and is strictly inferior to the 'agl comment below it, I think you should downvote this one and upvote his. 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.
- justinschuh 14y agoYeah, I'm reading this the same way you are. I guess Monday is going to be another fun day at the office. 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.
- tptacek 14y agoYou sound ruefully sarcastic but I have to say that the prospect of a week of political and logistical wrangling to get the most powerful tech company in the world to stomp mightily onto the forehead of a rogue SSL CA would absolutely get me out of bed bright and eager. I sort of envy you!
- justinschuh 14y agoWell, I rarely have to deal with these things directly because it mostly falls to Langley and Palmer. But anything involving the CAs always feels like far more work than it really should be. Both Mozilla and Chrome have root certificate inclusion policies that clearly outlaw this kind of behavior (assuming I'm reading correctly), but the CAs have operated for so long without any transparency that many of them are less than consistent on compliance. So, when we find violations we make them fix it, but it's a painful process because the mess is usually bigger than it appears on the surface, and you don't want to break all the innocent sites that are relying on the CA. 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.
- ak217 14y agoIs this against some sort of rule? They're allowing their clients to run their own delegate CAs, this can be very convenient for sysadmins. I'm not sure what's bad about it, or what new attacks it enables.
- 0x0 14y agoUnless I'm completely mistaken, running a delegate CA means you can MITM any SSL site on the internet.
- ak217 14y agoOh. That makes sense, thanks. Is there no way to restrict a CA cert to only be able to sign certs under a particular domain name/CN?
- pfortuny 14y agoA-m-a-z-i-n-g and they dare not even suggest that what they are doing may break each and every "normal" chain of trust. 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!
- pfortuny 14y agoWrong: see above. Nowadays it would work only against Safari and another browser. Sorry.
- davidillsley 14y agohttps://wiki.mozilla.org/CA:Problematic_Practices#Allowing_external_entities_to_operate_subordinate_CAs https://wiki.mozilla.org/CA:Problematic_Practices#Allowing_e... And from https://wiki.mozilla.org/CA:SubordinateCA_checklist 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."
- tlrobinson 14y agoThis seems like the fastest way to become untrusted by every browser.
- agl 14y agoThey aren't MITM certificates, they are cross-signs for enterprise deployments. If you run a large enterprise you might have lots of foo.corp.example.com and bar.corp.example.com hosts. A cross-sign would allow you to issue certs for these names that would be trusted by default. 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 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 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 https://tools.ietf.org/html/rfc5280#section-4.2.1.10
- jmix 14y agoThanks for the clarification. On a related note do you understand where the X.509 Name Constraints effort sits? Which, if any, browsers implement it? If it's not 100%, do you know why browsers are hesitant to deploy it?
- agl 14y agoName 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.
- marshray 14y agoSince nobody's mentioned this yet, I thought I'd bring this up: Code signing.
- rmhrisk 14y agoCode signing is another beast all together, in 5280 (and its predecessors). 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 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.