Hacker News Reader

Comment by madsushi | Hacker News Reader

> for issuing SSL Certificates for their own domains

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.

View on HN

There is no mechanism in the TLS X.509 PKI that enforces that rule. If a product promises transparent trust for any sort of customer-selected domains, it is either lying or selling the cryptographic equivalent of plutonium.

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.

Gotcha, if the technology isn't in place to properly restrict the issued certs to only the customer's domains, that is bad.

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.

> A FIPS 140-2 Level 2 compliant device to generate and managing your root certificate keys.

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.

Strictly speaking, the mechanism is there (Name Constraints, see section 4.2.1.10 in the RFC 5280), but it's not practical due to it not being implemented consistently across all major browsers.

EDIT: Changed RFC number from 2459 (obsolete) to 5280.

D'oh! I meant to write "effectively enforces" because I knew you'd snipe me with something like this. You win this time, Ristic.

No, you're right Ptacek because in this case the extension is being marked NON-critical. I.e., if the client code doesn't recognize the name constraint extension, it's OK to just ignore it.

If that is a problem that impacts only one popular browser, I find it easier to cast blame at the feet of the browser.

You're forgetting the huge mass of non-browser SSL/TLS clients.

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'.

Do you see the expressions of surprise about this policy here on HN? These are the world's more informed client application developers.

Careful. You're going to show up on "Shit HN Says".

Oh dude, make my day! :-)

http://tools.ietf.org/html/rfc5280#section-4.2.1.10

4.2.1.10. Name Constraints

...

Conforming CAs MUST mark this extension as critical

And? So they're not RFC compliant. Lots of things aren't.

Developers use the RFCs to write implementations. That's what RFCs are for. In this case, GlobalSign is issuing certs that are noncompliant in a direction that reduces the security experienced by users of compliant implementations.

I think this is wrong both in principle and in practice.

The alternative, which is also established practice, is to sell CA=YES certificates with no nameConstraints extension. What does the RFC say about that? Nothing. That's why bringing up the RFC is silly.

CA=TRUE with no nameConstrains is valid under the RFCs.

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.

It does not.

So how then does "the CA take reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate" when giving a 3rd party a private key which can sign a cert for any domain (and will be trusted by many clients the same as if had been issued by the CA itself)?

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".

Based on what's been said here, and on twitter (i.e. https://twitter.com/rmhrisk/status/300351604715057154 ), doesn't it appear that they are in violation of that requirement? Unless contracts and audits meet the requirement for "cannot."

The root programs all allow for technical and procedural controls to meet the this criteria. There are technical controls beyond name constraints as well.

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.

Perhaps if you described these technical controls in more detail we could reason about its security instead of by way of obscurity.

They need to meet the same criteria we do, here are some starting points but its far from exaustive:

http://www.mozilla.org/projects/security/certs/policy/

http://social.technet.microsoft.com/wiki/contents/articles/3...

http://www.webtrust.org/homepage-documents/item27839.aspx

This is very comforting. After all, it's not like any CA "trusted" under those programs ever did Bad Things; certainly, these programs loudly warned about DigiNotar, TrustWave and TURKTRUST.

Another alternative is not to sell CA=YES certificates at all.

Perhaps they don't give you the actual cert, but merely issue it, keep on their premises and then let you use it for unlimited signing through some sort of API (that enforces the subdomain restriction)?

Because if they indeed are offering CA=yes certs, that's just plain unbelievable.

Most will require that the private key be stored in an HSM (which almost certainly will be located on the customer's premises).

there is dNSName constraints but i don't know how well browsers support it. subordinate CAs seem quite problematic because they are invisible Certificate Authorities at least as far as the user is concerned.

Reply on news.ycombinator.com