Hacker News Reader

But if they give you the power to issue certificates for any name, how are they not "MITM certificates"?

Also, other people in this thread have commented that the 4.2.1.10 name constrained thing isn't really implemented anywhere?

"MITM certificates" are those used for the purpose of intercepting secure traffic. Many organisations have the certificates to do that, but are under audits, and technical and legal constraints not to.

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.

But - is there anything inside these certificates that identify to a browser what the "intended purpose" of a given certificate is, and prevents such a CA from being used for MITM attacks? How would a regular browser such as IE or Safari act when presented with a certificate for "bank.example.com" signed by such a CA?

Yes: the X.509 nameConstraints field, which modern browsers will read to determine which subdomains are acceptable as subjects for certs signed by the CA.

Earlier today I thought that nameConstraints was ineffective, but it seems to turn out that the problem is mostly limited to Safari.

Hm ok, I guess that makes it less of a big deal, but it still sits funny with me.

I guess all iOS devices are still "vulnerable" to a rogue nameConstrained CA then - assuming they share code with Safari?

I think it would be more accurate to say a "MITM certificate" is any private key with the ability to impersonate server and intercept SSL/TLS traffic.

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.

It's a question of terminology, but when groups like Chrome Security, Mozilla etc talk about MITM certificates and that they are forbidden, we mean those that are used for intercepting traffic.

I think this is a case where the precise terminology is critical.

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

Thanks Adam, yes these are not MITM certificates.

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.

Are they audited by GlobalSign, or by an independent third-party (i.e., same as all other CAs)?

For us we require CAs that are not technically constrained to be independently audited to WebTrust for CA requirements, Moving forward thanks to Mozillas new policy the same will be true for all CAs.

Thanks 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?

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.

Does Safari grok Name Constraints yet? I thought it didn't.

I'm not sure, but in the back of my mind I don't think that it does. I've agreed to write about this stuff for the Web PKI Working Group so I'll need to do a survey of the various capabilities at some point.

not currently, their move off of OpenSSL to their own libraries makes this more complicated for them to do but I am hopeful they will soon.

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

Can't you just manually install your own root certificate on your machines instead of buying from a CA?