
Mozilla to Certificate Authorities: no subordinate CAs for traffic interception - mbrubeck
http://blog.mozilla.com/security/2012/02/17/message-to-certificate-authorities-about-subordinate-cas/
======
yason
I think CA's are problematic nevertheless because they involve a third party I
never invited. I would much prefer to have a ssh style public key fingerprint
that you must verify and accept for one site, and know that once I've decided
to trust them, nothing can come between me and them unlike with SSL
certification chain. I would prefer to receive my bank's public key on paper
when signing up for online banking and verify that it equals what I see when I
first connect to their servers.

This reduces the MITM to the initial handshake. This could be worked out _to a
degree_ with some p2p scheme or a set of DHTs for popularity count.
Fingerprints would be submitted to a public service that accumulates
submissions from different users, identified by the same public key used to
sign the submissions. Trustworthiness would be weighted based on the history
and age of the users' submissions: someone who has used the same public key
and submitted fingerprints for five years is likely to be a real user that you
can trust instead of a bot that generates new identities in order to submit
false fingerprints to launch a MITM. There are numerous ways to implement
this.

One positive thing would be to bring the same attention to trustworthiness to
people's minds that they must employ in "real" life as well, i.e. offline. A
website that's never fraudulent or genuine (unless you got it in writing) but
shades of trust more reflects the interactions we encounter in real life (can
I trust this guy because my friend said he's ok?).

~~~
joshtalon
> This reduces the MITM to the initial handshake.

Mostly. No matter much you trim your certificate chain, there's nothing
preventing Google/your bank/Amazon/etc from sharing their private key with,
say, Uncle Sam. However, the backdoor admin access that the gov't gets to
sites like TwitterFace and Gmail probably makes that a pointless effort.

Confidentiality/Authenticity are pretty much impossible to guarantee unless
you control everything on both ends.

~~~
dasil003
Um, that's not MITM then is it?

I mean yes, if you're paranoid enough you probably should build an underground
bunker in the mountains and grow your food, but objectively there is a huge
security difference between whatever shenanigans a trusted partner may be up
to and a large body of auto-trusted with potentially leak able-to-who-knows-
where subcerts.

------
jtchang
Suppose you visit <https://mail.google.com/> from inside a corporate network.

Assuming ideal scenarios no one can snoop on your traffic between you and
Google because of SSL.

If a company wants to monitor you they have lots of options. One option is to
try and record all traffic between you and Gmail. However if the try to do
that your web browser will pop up a warning saying mail.google.com is
pretending to be someone else.

To get around this a company can create fake certificates that are trusted by
your browser. Then they need to intercept the traffic and basically pretend
they are gmail all the way recording you.

Ignoring the fact that companies already have a lot of rights to snoop on
whatever you do this is just bad precedent.

~~~
icebraining
See dektz's reply. Companies create their own CA cert (you can do that using
e,g. openssl) and use domain policies to install it on every machine they
control. Then they can setup a proxy that takes the CA cert and dynamically
generates certs for each domain that is accessed over HTTPS (Squid can do
that).

~~~
wcchandler
So this article is suggesting that this practice is wrong and will not be
tolerated or that the root CA authorities should not be the ones to generate
the certificates?

~~~
tptacek
No.

There is nothing wrong with creating your own CA root certificate and
installing it on computers you use. People do this all the time. For instance,
web testing proxies all synthesize a fake CA root cert, because otherwise they
wouldn't be able to run tests against HTTPS sites.

What happened here was, a company didn't want to go through the (significant)
bother of installing something in thousands of computer systems. So they did
an end run around the system and got a complicit CA to in effect add them to
the _global Internet CA root system_ , which they had no business being a part
of. Since the certificate they minted in this process appeared to browsers to
be a real, signed, chained-from-the-roots CA=YES cert --- something nobody can
make for themselves, not being able to do that being the whole point of
SSL/TLS --- they didn't have to install anything. On any computer. Anywhere on
the Internet.

------
DrCatbox
Awesome news, finally someone stands up to the blatant misuse of trust. I work
in such a company where SSL mitm is a part of day-to-day development. It is
disgusting that the security of SSL is broken for the sake of corporate
control over its workers.

~~~
tptacek
Mozilla was faced with what appears to be the worst possible abuse of the
privilege of being a Mozilla CA root. The abuse happened for commercial
purposes. The transaction that occurred was on its face abusive of the CA
system. The CA hasn't (and probably can't) name the company that was given
illegitimate CA privileges.

In response to this, Mozilla sent out a letter. That letter doesn't even
instruct CAs not to sell subCAs! It says, "don't sell them for MITM purposes".

I think Mozilla is between a rock & a hard place here, but there is no spin I
think you can put on this story in which Mozilla stood up against abuse of
trust.

~~~
feralchimp
> Mozilla is between a rock & a hard place here, but there is no spin I think
> you can put on this story in which Mozilla stood up against abuse of trust

I'm not sure it's worth our energy to be so disappointed in Mozilla here. That
"they're between a rock and a hard place" precisely _is_ the spin within which
they stood up against abuse of trust.

They have sent out a letter _so far_. One of your worries appears to be that
it sets the precedent that companies who do what Trustwave did can expect
(only) letters in the future. But (iirc, and perhaps even in the bugzilla
thread) one of the stated purposes of the letter is to set the opposite
precedent: to publicly warn commercial CA's that future bullshit will result
in distrusting.

I happen to think Trustwave had plenty of warning without the letter, but this
particular hard place is particularly thorny because Mozilla is such a central
policy hub. That's a problem you touched on above, that we agree needs a fix,
but it's the way things are today.

The other half of the hard place is that before Trustwave pulled this BS, they
issued a whole lot of legit commercial certs to a predominantly innocent user
population. And you know, they can and should all go acquire certs from
someone else, but they can't do that overnight. So if we really want Trustwave
to get distrusted, I feel like we should focus our energy on a) telling people
that Trustwave sucks and urging them to migrate, and b) paying
attention/effort to initiatives like the one you mentioned from MM.

~~~
tptacek
I'm mostly with you. But Mozilla could issue a blanket moratorium on the
issuance of CA=YES certs to external organizations; Verisign would, during the
moratorium, only be allowed to issue chained CA certs for Verisign properties.

They could do that today. Nothing would break.

Then they could spend some time --- spend as much time as they like, really
--- coming up with a policy that allows extraordinarily trusted companies to
sponsor and sign subCAs.

But they didn't do that. It's not just that they only issued a letter; it's
that the letter is comically weak.

------
melvinram
For the uninformed, what does this mean? (Btw, I did read the post; I just
didn't understand it.)

~~~
matkam
Apparently some root certificate authorities have been issuing certificates
that lets others generate their own, valid certificates at their own
discretion. Sounds these subordinate CA certificates are being used for SSL
man-in-the-middle attacks (<http://en.wikipedia.org/wiki/Man-in-the-
middle_attack>). So say your employer wants to monitor everything you're doing
at work. In order to get around the fact that a lot of your network data is
encrypted, they put in a device between your network connection and the
internet that looks at all your network traffic. For any connection that is
SSL encrypted (like https pages), it will forge its own valid certificate, and
use it to prove to your web browser (etc) that nothing is wrong with the
connection. Meanwhile, its logging the content of your Gmail, etc.

~~~
astrodust
This is the unfortunate flaw with SSL and TLS. The certificates are bound only
to the "domain name" which is a wobbly concept at best without DNSsec to
validate your DNS responses.

Anyone clever enough to create a DNS redirector that turns paypal.com into
10.0.0.2 on their closed network could also create an accompanying SSL
certificate that they own for paypal.com and you'd be none the wiser as they
proxy all of your traffic through their server, logging every bit of it.

~~~
tptacek
Wait, what? No they can't. The whole point of SSL/TLS is that you _don't_
trust the DNS.

The only way an attacker can redirect DNS for Paypal _and_ have a valid-
looking CA for Paypal is if they compromise a CA root certificate. That's the
point of SSL/TLS.

Before you suggest "but we can't trust the CAs", note two things: (1) if you
don't trust the CA, SSL/TLS isn't doing anything for you anyways, and (2)
DNSSEC also has a hierarchical PKI in which you are required to trust
commercial enterprises --- or governments, explicitly.

~~~
astrodust
SSH has more robust security than SSL seems to if only because once you've
established a connection with a remote host, whereupon their public key is
displayed and validated, it can be saved as "trusted".

The same principle doesn't seem to apply for SSL in browsers where, so long as
it's signed by a "trusted" authority, there's no question the certificate is
valid.

There has to be a better way than this.

------
tptacek
This is being read as good news, as Mozilla sticking up for its own users by
enforcing a new control on its CAs. But what it actually reads like to me is a
surrender. For once, I'll line up with the howl- at- the- moon crowd and say
that, excepting the fact that Mozilla might have been boxed into a corner
here, this is a bit of a travesty.

What you're not getting in this story is the following set of facts:

* A Mozilla-approved CA appears to have sold one of its customers a CA=YES cert --- in other words, they sold one of their customers the ability to be a CA.

* The customer wanted the cert to implement a "data loss protection" system. These are systems that either sit on the network or on everyone's machine and scan traffic to make sure people aren't exfiltrating company secrets. DLP systems want to see inside of SSL/TLS traffic.

* You don't need a CA cert to look inside the SSL/TLS traffic of your users. What you're meant to do is, create your own self-signed CA root certificate and _install it yourself_ in all your users' browsers. Yes, this is painful.

* So instead of incurring that pain, this particular company got a CA to, in effect, _install that certificate in the browser of every computer on the Internet_. That they didn't intend to MITM the traffic of every one of those computers is beside the point.

* Instead of the exact audit and certification process used by Mozilla to add new CAs, this chained sub-CA was audited by the CA itself. But: before you say, "well at a minimum you'd hope the CA audited them!", you should know: _the primary business of this particular CA is auditing_.

* The CA didn't appear to have told anyone this for a long time (I want to be careful to point out that I don't know exactly what the timelines are here; from the CRLs, it doesn't look great).

* Something happened that caused the CA to announce that they had issued the cert.

* A long discussion happened on Mozilla Bugzilla, under a critical security blocker bug that more or less requested that the CA be removed from Firefox.

* Publicly, the policy response from Mozilla was, "they came forward, and removing their cert from the roots is an extreme punishment". I think behind the scenes, getting rid of this CA was problematic for other (valid) reasons.

* So instead, stern letter to all the CAs. Yay! The Internet is safe again.

I don't know how much more cut-and-dry an abuse of the CA system you can get
than selling your CA status to random unnameable companies so that they can
implement MITM systems.

But more than that: it is simply batshit crazy that CAs are allowed to sell
CA=YES certs at all. I don't get it. Maybe someone working at a browser vendor
can reply to this comment and explain to us why any one company is trusted to
make a decision like that for the entire Internet?

I am a vocal and public fan of SSL/TLS, and I've even on occasion stuck up for
X.509 (horrid as this certificate format is). But this stuff here is the part
of the SSL/TLS system that the privacy zealots are right about. I'm hopeful
that we'll see adoption of a system like Moxie Marlinspike proposed with
"Convergence", where instead of blindly accepting Mozilla's policy decisions
(and updating our policies once- in- a- blue- moon), we'll have end-user-
selectable trust roots and thus an incentive for someone (maybe the EFF) to do
a good job running such a root. I'm also hopeful that at some point we'll
manage to figure out a UX for website trust that is better than what we came
up with in 1997.

~~~
feralchimp
Many great points; some more perspectives in the bugzilla thread here:

<https://bugzilla.mozilla.org/show_bug.cgi?id=724929>

There are a number of choice quotes, but my two favorites are from Jacob
Applebaum (@ioerror if you aren't already following him):

"TrustWave needs to be congratulated and as a reward, I think they should have
their CA distrusted."

And another commenter 'Philip' (sorry I don't lurk there and don't have more
detailed identity info for him...his words more than stand alone though):

"Trustwave appears to issue certificates directly from its root - this is not
good practice. The root should be kept offline and never - ever - have a path
to the internet." ... "the trust chain was broken at the root level, so that
is where this branch, and all leaves, must be pruned"

So I guess this is where I break slightly from tptacek's opinion: I'm not yet
100% convinced that the issuance of CA=YES certificates by public CA's is an
abusive practice.

Installing organization-specific self-signed roots in all company devices is
more than just 'a pain'; it's fundamentally impractical for any organization
that wants to let employee-owned or public devices onto its network. So just
don't do that? Or just put all the uncontrolled devices onto some airgapped
public network? Well, airgapped according to whom, and as of what last
physical audit date? Should all organizations that implement DLP have physical
security measures similar to DoD installations, where a guard with a gun makes
it clear that your iPad should be left locked in your car in the parking lot?

Not saying everything's cool, just saying "it's complicated." What _is_ clear
is that Trustwave added at least a couple extra layers of supreme jackassery
in this case.

Trustwave's issuance of a CA=YES certificate _directly from their topmost
root_ is the most distressingly unprofessional method they could have chosen.
That choice alone, in my view, is a coherent argument for why a) their root
should be distrusted, and b) they deserve (at minimum) a long cool-down period
before an alternative Trustwave root CA becomes a candidate for addition to
the default trusted set.

~~~
tptacek
Companies already do device-by-device interventions for all sorts of other
security policy issues, from making sure machines aren't going to spread
malware to ensuring that USB drives can't be used to exfiltrate data. If a
company's employees want to bring their own devices on-site, they can have the
company's root cert installed; that's the cost of using your own device on the
company's network. That's not an unprecedented policy.

~~~
caf
...and it doesn't even _matter_ if the employee-owned devices don't have the
employer CA certificate installed; their traffic still gets MITMed and DLPed
just fine. It's just that they don't get an (incorrect) indication that their
session hasn't been MITMed, which if it is a problem at all, is a problem for
the employee.

~~~
tptacek
There are lots of applications that use HTTPS under the covers that will break
if certificate validation fails, so not having the root cert installed does
"break" those devices.

(There are unfortunately even more apps that use HTTPS under the covers that
appear not to care whether certs validate).

~~~
caf
Sure, but that falls right into the category of "a problem for the employee".
The traffic still gets MITMed, so the employer shouldn't care.

------
rwmj
First of all .. are they going to enforce this? Indeed, _can_ they enforce it?
Is it possible to detect such certificates and will Mozilla remove root CAs.

Secondly, this doesn't do anything for the fundamental broken design of CAs
which is that any CA in the world can issue a certificate for any website.
Firefox ships with dozens of certificates for such eminent organizations as
"OISTE WISeKey Global Root GA CA" (who they?), basically anyone who can stump
up the fee and fill in a form on Mozilla's website. Any of these could issue
duplicate or fraudulent certificates, and any of them could be attacked.

~~~
throwaway64
It can be enforced, because the certificate chain will indicate that the x.509
cert has been signed by an intermediate CA

~~~
rwmj
Such certificates are allowed in general, just not if the site is a 'global'
site (whatever the definition of 'global' would be). That's why I don't think
this is enforcible.

~~~
jbri
Where are you getting this "allowed in general" thing from? I can't see
anything in there at all that would imply that.

~~~
pilif
Many certificates that you can buy today are issued by legitimate resellers of
bigger CA's. That's done by the big CA (which is in the list of trusted roots)
handing out a CA certificate to the reseller.

We'd probably want to keep this as is or the already way too big list of roots
in the browsers becomes totally unmanageable. Or we move back to the days of
only a handful of roots, which probably means also going back to the old
prices ($500+ a year for a non-ev one)

~~~
tptacek
We're kidding ourselves, totally kidding ourselves, that we have made the CA
system "manageable" by allowing CAs to sell subsidiary CAs to other companies.
Yes, those certs aren't cluttering up our 2 terabyte hard disks. _That's a bad
thing_ , because they're still out there, and they work whether your browser
tells you about them or not.

------
robtoo
I would feel a lot more confident about actual compliance if Chrome came on
board with this as well.

~~~
duskwuff
For historical reasons (viz. NSS), Mozilla maintains its own list of trusted
CAs. Chrome uses whatever is provided by the OS, so they aren't in a position
to make the same sorts of demands.

Not that I disagree with the sentiment -- there's just a very specific reason
why Mozilla is involved, and it's not simply because they write a web browser.

~~~
nknight
Chrome could still maintain a blacklist of roots.

~~~
Maxious
One was written after the DigiNotar incident:
<http://code.google.com/p/chromium/issues/detail?id=94673>

------
zokier
So did they decide what to do with the TrustWave-case? Are they forgiven for
their confession? That seems to be the implication of this announcement.

~~~
joshtalon
Makes you wonder what actually happened with TrustWave (there's obviously more
to it than "Oh, this was an ethical dilemma so we stopped."). Probably their
customer found a way into the intermediate CA private key and was being
naughty with it.

What I think sparked Mozilla is TrustWave's claim that this kind of thing is
widespread and commonplace among CA's. That's shouldn't surprise anyone,
though.

------
onedognight
Thank you Mozilla.

------
guelo
Should we remove Trustwave from our personal browsers? Or as admins from our
users' browsers?

------
drcube
Time to eliminate CAs altogether. I don't see why my trust in them should be
assumed:

<http://convergence.io/details.html>

------
unseen
They have ruined security for everyone by allowing government agencies (they
didn't even bother to setup a front) and other questionable entities on that
list. The correct response is not to send out a nice letter asking everyone to
please give up crucial business information, but to kick everyone off that
list and start over.

Mozilla was compromised, not the CAs.

