
Maintaining Digital Certificate Security - cleverjake
http://googleonlinesecurity.blogspot.com/2015/03/maintaining-digital-certificate-security.html
======
tptacek
What seems to have happened here:

An Egyptian telecom company, MCS Holdings, contracted with CNNIC, the Chinese
national Internet authority, to obtain a CA=TRUE certificate for use in their
internal enterprise proxy --- ostensibly for use only with MCS's own
hostnames. Users of MCS traversed that proxy to get to Google, at which point
the proxy dutifully generated a (fake) Google certificate to bypass TLS for
that connection. Google noticed.

Internal enterprise MITM proxy sounds creepy but isn't. There's a bunch of
good reasons why a company would need to decrypt TLS traffic leaving their own
network.

But enterprises don't need delegated CA=TRUE certificates to accomplish this.
They can just roll their own self-signed root CA=TRUE certificate and built it
into their machines. There is no reason a CA should need to put the entire
Internet at risk solely for the convenience of a single company's IT
operations.

A Chicago company called Trustwave did something similar a few years back. Are
they still an HTTPS CA?

~~~
sekasi
Would you mind elaborating on the good reasons for MITM your company web
traffic? I'm not being facetious, genuinely curious.

~~~
tptacek
For instance, if you are a company that handles confidential medical
information (any health care organization, many insurers, every employee
benefits management organization, &c), you may be required to have controls in
place to ensure that nobody uses your Internet connection to exfiltrate
people's PII through Google Mail.

Similarly, many investment banks and financial information firms have strict
requirements to monitor all communications owing to SEC rules and insider
trading regulation.

~~~
mjs
Is there any way to detect that you're being MITM'd?

~~~
zaroth
It's the golden unsolved, perhaps unsolvable problem in crypto. Trusting trust
and such. There's always a key, somewhere, that has to be shared.

One way to hack the system is if you have actual knowledge of the person you
are talking to, and you assume some limited amount of tampering which can be
done in real-time. For example, if I know the sound of your voice, and we want
to agree on a key with no MITM, we can setup an audio channel and speak some
code words to each other. Baring an adversary which can in real-time intercept
and synthesize my voice convincingly speaking a different code, this is pretty
secure. [1]

    
    
      [ZRTP] allows the detection of man-in-the-middle (MiTM) attacks by displaying a short
      authentication string (SAS) for the users to read and verbally compare over the phone.
    

Another imperfect defense is spreading over time the data that an attacker
would have to intercept and modify in order to MITM. That's what Chrome is
doing with their pin lists. Now an adversary would have to alter the pinning
when Chrome is downloaded. Of course in this very thread we're talking about
technology which can do exactly that. E.g. technology which has any hope of
preventing data exfiltration, would have an easy time altering Chrome's pin-
list. Of course the Chrome binaries are signed, so there's another layer to
defeat, etc. etc.

So the end result is there are a lot of good technologies to prevent MITM. If
you can keep the attacker out once, you can generally be confident your future
conversations will be secure as well, since good protocols don't start from
scratch each time, but rather "ratchet" new keys from the old as you go. [2]

One of the big trade-offs is false positives and privacy. For example, it
might be nice if my browser remembered the public key of a site I visit, like
HN, and let me know if it changed. Two issues are a naive implementation would
also serve as a great tracker for every site I've visited, and how do I know
if when I get a warning, it's a _real attack_ and not just an expiring
certificate rotating out? Now we would need a way for sites to indicate, by
signing with their old key, that indeed they are switching to a new key, and
complexity explodes from there.

[1] - [http://blog.cryptographyengineering.com/2012/11/lets-talk-
ab...](http://blog.cryptographyengineering.com/2012/11/lets-talk-about-
zrtp.html)

[2] - [https://whispersystems.org/blog/advanced-
ratcheting/](https://whispersystems.org/blog/advanced-ratcheting/)

~~~
itistoday2
> _It 's the golden unsolved, perhaps unsolvable problem in crypto._

I think this problem was solved fairly well by Namecoin back in 2011. Software
like DNSChain [1] then makes it possible to securely access blockchains like
Namecoin without having to run a full node on your phone or other device.

If you can't run your own DNSChain server (or don't have a friend's you can
use), you can query two or more independent servers and make sure the
responses match.

Dionysis Zyndros recently came up with a mechanism whereby you can even query
a single DNSChain server (that you might not trust), and still be assured of
correct replies if you received an accurate key once (we'll be publishing info
on this technique soon over at blog.okturtles.com; it's somewhat similar to
what you're talking about with ratcheting keys).

We maintain a comparison of various approaches here:

[1]
[https://github.com/okTurtles/dnschain/blob/master/docs/Compa...](https://github.com/okTurtles/dnschain/blob/master/docs/Comparison.md)

~~~
zaroth
Of course how could I have not mentioned the blockchain? Thank you!

Part of the trick with blockchain is validation. Everyone is not going to keep
a full node, not even close, and just delegating trust is not the answer. You
want to trust but verify.

I'm not sure what the state-of-the-art is these days for SPV-type
verification, but I don't see anything in the current DNSChains response which
would allow any kind of independent verification of the returned data.

Edit, also see:
[https://en.bitcoin.it/wiki/User:Gmaxwell/namecoin_that_sucks...](https://en.bitcoin.it/wiki/User:Gmaxwell/namecoin_that_sucks_less)

~~~
itistoday2
> _Part of the trick with blockchain is validation. Everyone is not going to
> keep a full node, not even close, and just delegating trust is not the
> answer. You want to trust but verify._

Right, so hence the two techniques I mentioned in my reply: query more than
one server, and/or use Dionysis' "proof of transition" (for lack of a better
name).

------
Stefan-H
At this point I feel like we need to simply remove Chinese root CAs from trust
stores and have user's opt-in to allowing certificates issued from china. I
realize that any CA can be mismanaged, but the risk of Chinese government
hands in things like this seem too high to me.

Edit: I have no delusions that this is not happening in the US, it is simply
that as someone in the US, I don't have any options to lop off CAs that the US
could influence. I can however make the decision to not trust some foreign CAs
entirelly.

~~~
mike_hearn
You can always remove CNNIC from your own trust store. Saying they should be
removed from _all_ trust stores would rather annoy people actually in China,
I'd assume.

I wonder if certificate transparency could be mandated for intermediate
certificates sooner than a full DV rollout could. It seems some CAs can't
quite resist bending the rules when a sweet contract is dangled in front of
their faces. It makes me wonder how much CNNIC was being paid to do this.
Given that MCS Holdings sells "security products" it makes me wonder if this
was an attempt to do or prepare to do bulk SSL stripping. I guess the blog
post says there was no evidence of abuse though, so I guess not.

~~~
itistoday2
> _I wonder if certificate transparency could be mandated for intermediate
> certificates sooner than a full DV rollout could._

It should be mentioned that Certificate Transparency would not have prevented
this attack (nor any other such attack).

Google has nothing to gain from CT beyond where they are right now: knowing
who issued the cert.

Details: [https://blog.okturtles.com/2014/09/the-trouble-with-
certific...](https://blog.okturtles.com/2014/09/the-trouble-with-certificate-
transparency/)

TLDR:
[https://github.com/okTurtles/dnschain/blob/master/docs/Compa...](https://github.com/okTurtles/dnschain/blob/master/docs/Comparison.md#certificate-
transparency)

~~~
yuhong
Not this particular attack, as this was a test intermediate only valid for 2
weeks, but the attack was limited to an internal corporate network. For other
cases it would allow browser vendor to demand audit reports for example.

~~~
itistoday2
So, as mentioned in the first link, client audits via the browser would do
absolutely nothing during an attack:

"None of CT’s proofs (audit or consistency proofs) will detect mis-issuance of
a certificate by a rogue CA, not even if gossip of STHs (signed-tree-heads)
successfully occurs [1]"

And that's for today's attacks. In the section before that paragraph, another
attack is demonstrated that also cannot be prevented by CT's audit proofs.

[1] [https://moderncrypto.org/mail-
archive/messaging/2014/000873....](https://moderncrypto.org/mail-
archive/messaging/2014/000873.html)

~~~
yuhong
And the point is that logging intermediates only does not directly prevent the
attacks but it is still useful.

------
qeorge
Honest question: as a United States internet user, is there any practical
reason I need to have a root certificate from the Chinese national Internet
authority installed?

Corollary, is there a short list of CAs that folks around here trust more than
average? Is there any value in such a whitelist, or are all CAs so rotten it
doesn't much matter?

~~~
kjs3
If you regularly visit Chinese sites that use HTTPS.

~~~
lucaspiller
...that use this CA. I regularly use Alibaba, but their certificates are
signed by "VeriSign Class 3 Secure Server CA - G3".

------
0x0
How can they possibly defend not removing CNNIC from the roots after this? SSL
is broken and nobody is lifting a finger :(

~~~
Buge
Untrusting CNNIC wouldn't really "fix" it. There are hundreds of trusted CAs,
and any of them could do something like this.

~~~
dragonwriter
Adopting a zero-tolerance policy for CAs that are bad actors (including those
that allow others to have their full power who themselves act as bad actors)
and removing their root certificates from trust stores would create a
substantial disincentive for CAs to be bad actors.

~~~
PhantomGremlin
Yeah, I can't believe the "oh, that's OK, a silly bureaucratic snafu, boys
will be boys" response from Google. But at least they told us, they didn't
sweep it under the rug.

I would have preferred the Pulp Fiction version. Google should have instead
said to CNNIC:

    
    
       You hear me talkin', hillbilly boy? I ain't
       through with you by a damn sight. I'ma get
       medieval on your ass.

------
mcherm
So, Google's page on this promotes a project for certificate transparency. I
am not familiar with this project; does anyone here know more about it and if
so can you comment on whether you think it's a good idea for the overall
ecosystem.

~~~
mike_hearn
CT is a simple idea. Currently, it's possible for certificates to be issued
privately. The PKI was designed to scale (and scale it does), so there is no
requirement that a certificate be downloaded from some trusted source: an SSL
server can provide the client with a certificate chain that acts as a proof
that a public key is owned by a particular named entity.

That has some advantages, most obviously, scalability and robustness. It also
has one giant disadvantage: the only way to catch misbehaviour is to actually
find a bogus certificate being used in the wild.

Certificate transparency is Google's plan to fix this. The idea is to evolve
the PKI in a backwards compatible way. It creates public logs in which every
certificate is meant to be registered. The certificates (or SSL handshakes, or
a few other things) can then have a short mathematical proof embedded in them
that the certificate was logged.

If the log proof isn't present then browsers remove the security indicators in
order to apply pressure to people to get their certificates logged. It's
supposed to be done by CAs so most SSL users should never notice any of this
is happening.

Once certificates are being logged publicly the idea is anyone can do data
mining over the log, for example to find certificates issued for their own
website that they know they didn't request. Thus it allows crowdsourced
policing of the CA system. Violations of the rules could be detected much
faster.

Currently however only Chrome implements CT, and only for EV certs (the ones
that make the address bar green), and the majority of CAs have been ignoring
it, although the big fish are taking part. The customers of the smaller CAs
that are pretending CT isn't happening will get a nasty surprise once Chrome
stops treating their certificate as EV.

~~~
iancarroll
Small nitpick: Chrome implements CT for all certificates and shows its status,
however they only currently plan to downgrade an EV certificate to a normal
certificate.

Firefox has an open bug for implementation[1] but it's inactive for whatever
reason.

[1]
[https://bugzilla.mozilla.org/show_bug.cgi?id=944175](https://bugzilla.mozilla.org/show_bug.cgi?id=944175)

~~~
gcp
_but it 's inactive for whatever reason_

Not hard to see why from your explanation.

You don't need implementation in the browser. You need the CAs to provide the
public audit logs and all HTTPS domain owners to check them for unexpected
issuance.

The browser is just a political tool to enforce the CAs to provide the logs,
for example by no longer marking their certs as trusted unless they do so.

~~~
nickodell
If the browser trusts certificates that aren't in the log, then what's the
point of having the log at all?

~~~
gcp
There is none, which is why I said the browser is just a tool in a politics
game. It enforces the existence of the log. The security doesn't come from
checking whether the cert is in the log!

------
jlgaddis

      # remove-cnnic-root-ca-certificate.pp (only tested on ubuntu 14.04)
      file { 'CNNIC_ROOT.crt':
        path    => '/usr/share/ca-certificates/mozilla/CNNIC_ROOT.crt',
        ensure  => absent,
      }
    
      file { '895cad1a.0':
        path    => '/etc/ssl/certs/895cad1a.0',
        ensure  => absent,
      }
    
      file { 'bd1910d4.0':
        path    => '/etc/ssl/certs/bd1910d4.0',
        ensure  => absent,
      }
    
      file { 'CNNIC_ROOT.pem':
        path    => '/etc/ssl/certs/CNNIC_ROOT.pem',
        ensure  => absent,
      }
    
    

(N.B.: Yes, I know that doesn't completely take care of the problem. I
manually "distrusted" it in Chromium and Firefox as well.)

~~~
tveita
If correctly disabled [https://www1.cnnic.cn/](https://www1.cnnic.cn/) should
give a certificate error.

------
iancarroll
This is actually solid grounds for removal in all trust stores, honestly. They
did numerous things wrong (from what I am reading here):

\- The CA must have had some warning that it wasn't being loaded onto a HSM

\- It was never verified the CSR/key was generated on a HSM (!!!)

\- The auditors did not oversee the key being generated (this is typical for
roots, although not for intermediaries)

\- If this subordinate was in operation for >1yr, how was this not caught in
an audit?

and you can't load a certificate off of a HSM, so I'd argue the CA is entirely
at fault here.

~~~
yuhong
The fourth point is not true, I looked at the intermediate myself. In fact the
test intermediate is only days old at the time of the writing and last less
than a month before it expires.

------
colinbartlett
What can a site administrator do today to combat these kinds of flaws? Is
there some certificate pinning technology (I don't fully understand what that
is) I can use on my own sites now to push in the right direction?

I try to be an early adopter of such practices such as using SSL all the time
on all my sites.

------
click170
Is anyone else frustrated after trying to load this page on a mobile device?

I zoom in to read the text and when I try to slide the screen over, it
interprets that as me wanting to go to the next page. No, I wanted to read the
text on THIS page.

------
yuhong
Fortunately this is only a test CA that will expire at beginning of April.

