6 ms·

They 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 ba

by agl 14y ago

They 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 ago
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?
- agl 14y ago
  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.
  - tptacek 14y ago
    Does Safari grok Name Constraints yet? I thought it didn't.
    - agl 14y ago
      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.
      - rmhrisk 14y ago
        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 http://unmitigatedrisk.com/?p=24
0x0 14y ago
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?
- agl 14y ago
  "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.
  - 0x0 14y ago
    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?
    - tptacek 14y ago
      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.
      - 0x0 14y ago
        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?
  - 14y ago
rmhrisk 14y ago
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.
- ivanr 14y ago
  Are they audited by GlobalSign, or by an independent third-party (i.e., same as all other CAs)?
  - rmhrisk 14y ago
    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.
wbl 14y ago
Can't you just manually install your own root certificate on your machines instead of buying from a CA?

by agl 14y ago

jmix 14y ago

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?

agl 14y ago
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.
- tptacek 14y ago
  Does Safari grok Name Constraints yet? I thought it didn't.
  - agl 14y ago
    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.
    - rmhrisk 14y ago
      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 http://unmitigatedrisk.com/?p=24

0x0 14y ago

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?

agl 14y ago
"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.
- 0x0 14y ago
  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?
  - tptacek 14y ago
    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.
    - 0x0 14y ago
      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?
- 14y ago

rmhrisk 14y ago

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.

ivanr 14y ago
Are they audited by GlobalSign, or by an independent third-party (i.e., same as all other CAs)?
- rmhrisk 14y ago
  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.

wbl 14y ago

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