

For sale: Trusted root SSL CA signing certificate - 0x0
https://www.globalsign.com/certificate-authority-root-signing/

======
agl
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>

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>

~~~
0x0
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
"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.

~~~
marshray
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.

~~~
agl
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.

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

------
tptacek
_Since 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.

~~~
rmhrisk
I think you are misunderstanding.

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...](https://sslcheck.x509labs.com/en_US/sslcheck?host=www.google.com#74.125.227.114-cert)

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

~~~
tptacek
Hey, Ryan. Thanks for clarifying. I only have one followup question.

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.

~~~
rmhrisk
They do and that's is specifically what this offering is about.

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

~~~
tptacek
Thanks. I'm sorry, I knew MITM wasn't the only or most common reason
enterprises wanted these certs, but wrote lazily.

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.

~~~
rmhrisk
That's the position we start with when we engage with a customer but its
dependent on the community in which they are going to communicate with. To be
honest in most cases today (due to Safari) criticality is not enabled on most
deployments.

~~~
lawnchair_larry
As far as I'm concerned, that is in fact a MITM cert. Because you can
technically MITM.

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.

~~~
tptacek
You can only MITM Safari & Opera with that cert, FWIW.

~~~
lawnchair_larry
You seem to think that SSL is only for browsers.

~~~
tptacek
I think that to a first approximation CA trust only matters for browsers,
because non-browser applications have a whole panoply of other mechanisms that
they should already be using to ensure the authenticity of SSL certificates.
To put it differently: people running non-browser applications tend to have
more control of their destiny.

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.

------
davidillsley
[https://wiki.mozilla.org/CA:Problematic_Practices#Allowing_e...](https://wiki.mozilla.org/CA:Problematic_Practices#Allowing_external_entities_to_operate_subordinate_CAs)

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

------
pfortuny
A-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
Wrong: see above. Nowadays it would work only against Safari and another
browser.

Sorry.

------
0x0
Can someone explain to me why these guys are still allowed to be present in,
for example, the OS X trusted key store?

~~~
guns
If 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
I wish there was a tool for auditing root certificates. Like point out which
certs are owned by governments, reputation of companies, etc.

~~~
tptacek
The 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.

------
sharth
Just 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
If 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
I'm one of those people and it looks like I am, for the most part, wrong about
that.

~~~
pfortuny
Wow thanks for taking the trouble to answer: I guess I got it wrong. Somehow I
would like to be able to unpost some comments.

------
ak217
Is 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
Unless I'm completely mistaken, running a delegate CA means you can MITM any
SSL site on the internet.

~~~
ak217
Oh. 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?

~~~
0x0
Not that I know of (and tptacek seems to confirm the same elsewhere in this
thread)

~~~
tptacek
He confirmed it wrongly.

------
tlrobinson
This seems like the fastest way to become untrusted by every browser.

------
marshray
Since nobody's mentioned this yet, I thought I'd bring this up:

Code signing.

~~~
rmhrisk
Code 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>

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.

