
Improved Digital Certificate Security - mikecarlton
http://googleonlinesecurity.blogspot.com/2015/09/improved-digital-certificate-security.html?m=1
======
gleenn
What is a "Symantec-internal testing process" that leads to Google certs being
leaked outside of Symantec? Is some engineer poking around and just used
"google.com" as an example? Seems like a pretty serious wtf moment. If I was
Google I would be pissed.

~~~
wmt
The kind where they used Chrome to browse to an internal testing website?
Though using a real website, like Google, instead of a mock is quite wtf. What
I'm curious about is whether the fired* Symanted engineers were just
scapegoats or had they actually been reckless and unprofessional.

* [http://www.symantec.com/connect/blogs/tough-day-leaders](http://www.symantec.com/connect/blogs/tough-day-leaders)

~~~
Pyxl101
> In addition, we discovered that a few outstanding employees, who had
> successfully undergone our stringent on-boarding and security trainings,
> failed to follow our policies. Despite their best intentions, this failure
> to follow policies has led to their termination after a thoughtful review
> process. Because you rely on us to protect the digital world, we hold
> ourselves to a “no compromise” bar for such breaches. As a result, it was
> the only call we could make.

> As much as we hate to lose valuable colleagues, we are the industry leader
> in online safety and security, and it is imperative that we maintain the
> absolute highest standards. At the end of day, we hang our hats on trust,
> and that trust is built by doing what we say we’re going to do.

Wow.

I have to say that I respect that decision. Without knowing the circumstances,
I have to say that willful disregard for security policy while handling
materials as sensitive as a CA cert is indeed not something I'd want to see
from employees at a CA.

~~~
deepdiver16
Agreed that the steps taken vis-a-vis these employees may have been the right
one if they indeed breached company policy. But I do have an issue with
publicizing this so openly, and using this to showoff of how serious "we" are.
Even with the best intentions, you will run into bad apples. You still need to
have the right controls, preferably automated, to avoid sensitive material to
be used for internal purposes. Blogging on how they terminated employees
doesn't help to showcase their leadership imho.

------
fulafel
One has to wonder how much of these CA shenanigans have been going on before
these news sytems were put in place systems to catch the rogue certificates.

It would stand to reason that people are more wary of it now that there is a
high risk of getting caught.

~~~
avar
And furthermore, how many CAs have "solved" the issue by outlawing all use of
Google Chrome by their staff anywhere near their systems.

------
vonklaus
After reading DrDuh's guide to install yosemite, I thought a bit more about
the ~200+ trusted CAs on my computer. I removed about ~50 using various
heuristics, mostly arbitrary stuff like removing goverment agencies, and
international CAs that I was skeptical of or otherwise assumed I would not
need.

To get to my question though, how many CAs does one need to trust for the
safest browsing experience? What CAs should be trusted and how can they be
evaluated? How many-ish are you guys trusting?

~~~
multibear
Interesting; have you had issues loading any popular websites?

~~~
vonklaus
Funnily enough, I must have dropped the certificate for bing somehow. It
hasn't affected any popular sites yet though.

------
tomfitz
[https://api.ctwatch.net/domain/ycombinator.com](https://api.ctwatch.net/domain/ycombinator.com)
is an RSS feed of all issued certificates for ycombinator.com and its
subdomains.

Feel free to use that to check your own site's certificates!

(It's possible to directly query the multiple Certificate Transparency log
servers for your site's certs, but non-trivial, hence why I implemented the
above functionality.)

Code: [https://github.com/certificate-transparency-
watch/](https://github.com/certificate-transparency-watch/)

~~~
QUFB
It looks like you're using CloudFlare.

This RSS service is useless to all Tor users, as CloudFlare attempts to serve
up a catpcha here. Serving a captcha on an RSS feed defeats the purpose of RSS
automation.

~~~
tomfitz
Thanks for letting me know.

Yes, I'm using CloudFlare, for its trivial SSL, DDOS protection, and caching.

I have CloudFlare's DDOS protection (the thing that causes captchas) set to
"Essentially Off", the lowest available setting on their free plan.

I just tried to query
[https://api.ctwatch.net/domain/ycombinator.com](https://api.ctwatch.net/domain/ycombinator.com)
multiple times, each on multiple Tor circuits, but was unable to trigger the
CloudFlare captcha.

Did you see the captcha on my site, or is it just that you've noticed captchas
on some other CloudFlare sites?

I can look into setting up a Tor hidden service, which'll allow Tor users to
bypass CloudFlare, if CloudFlare is actually causing issues.

~~~
QUFB
I had issues with newsbeuter retrieving your feed with Tor.

Regardless, CloudFlare shows such disregard and contempt for privacy and
anonymity that I'm not comfortable using services that use CloudFlare (Hacker
News excepted!).

------
lisper
Wtf is a "pre-certificate"?

~~~
geofft
Certificate Transparency is a (mostly Google-developed) program which aims to
require that certificates be publicized to some third party, so that mis-
issuance (just like this one!) can be detected. You do this by telling a
third-party log server that you're issuing a certificate for a domain, and the
log server gives you back a proof (essentially a countersignature) saying
"Yes, I am a third-party log and I've seen this certificate and I'm
publicizing its existence."

You can submit the actual certificate to the Certificate Transparency log, but
then you don't have that proof immediately, so the certificate isn't usable
until after it exists. (And the easiest way to send the proof to a client is
to embed it in the cert itself.) So instead, the CT protocol allows you to
generate a "pre-certificate", a modified certificate with a special X.509
extension poisoning it from actually being used as a certificate. It is a
promise that you are willing to issue this certificate, but cannot be used to
authenticate.

Since it can be exchanged for a CT log proof, just like an actual certificate
can, it has exactly the same verification / trust requirements as actually
issuing a cert. However, it cannot be used as a certificate.

Chrome now requires Certificate Transparency for all CAs that it has
authorized to sign extended validation (EV, green bar with the company name)
certificates, as those are held to a higher standard than the rest of the CA
system is (currently) held. While Google also operates the logs, they
shouldn't have needed any special access: any website operator can ask the
logs "Hey, what proofs have you issued recently," and cross-check those
against the certificates they actually intended to get signed.

------
rspeer
This article was already posted, without the mobile formatting.

~~~
jffry
Link:
[https://news.ycombinator.com/item?id=10242987](https://news.ycombinator.com/item?id=10242987)

------
sgentle
Is this a different situation to the CNNIC Google cert issued earlier in the
year? If so, how?

~~~
geofft
CNNIC issued the intermediate to someone who was doing non-consensual, large-
scale SSL MITM. CNNIC evidently didn't realize that's what they were doing,
and _possibly_ the company didn't either (and just accidentally MITM'd their
own technician's connection to Google during testing -- not that this makes
the story better), but in either case CNNIC should not have issued a non-HSM
cert and they should have vetted the technical competence and goodheartedness
of the customer. Furthermore, they said they were not issuing intermediates,
and had not updated their certification practices statements before entering
this "experimental" business.

In the Symantec case, the private key in question remained with Symantec at
all times, with employees who legitimately had access to the EV certificate
authority as part of their job, in the course of testing. It was never exposed
to anyone outside the CA.

CNNIC sold a valid, unconstrained intermediate private key to a completely
unqualified customer and had organizational troubles at all levels. We were
lucky that the customer was _also_ incompetent, and just got caught. Symantec
had a few employees make a mistake internally, and at no point could anyone
malicious (other than potential malicious employees) threaten internet
security. And those specific employees got fired.

~~~
MichaelGG
> non-consensual, large-scale SSL MITM

Link to this? The story was that they issued it to some v Egyptian company
that wanted to run a CA. This company was incompetent and didn't have an HSM.
They did have a Palo Alto MITM box that had "CA capabilities", so they used
that. Then an engineer at this company plugged his machine into the MITM port,
loaded Chrome and tada.

Utterly incompetent and against the CA rules. But not large scale or non-
consenual MITM right?

~~~
geofft
Oh, yeah, you're right. They put their globally valid, unconstrained
intermediate cert in a device whose primary purpose is large-scale SSL MITM,
and they MITM'd themselves without realizing it, but yes, they weren't
_intending_ to do large-scale non-consensual SSL MITM. I'd forgotten the part
where they were planning on using the device as a way to issue normal certs
and ignoring the MITM capabilities.

~~~
MichaelGG
Seeing as how using a trusted CA to do MITM isn't even remotely a valid
business plan or idea, I think it's quite possible that they were incompetent
enough to use any piece of hardware, yes. It's actually better for the world
if they were planning to do MITM, as they'd have been caught so fast and their
plans killed so quickly itd be funny. As-is it's just luck that they messed
up.

------
blueflow
This is not a "improvement", they just fixed something going really wrong.

------
sidcool
One has to commend Google on its transparency on the matter.

------
mmaunder
That's the problem with TLS trust: All it does is tell a browser that a CA
trusts the certificate. The process to verify site ownership varies and is
error prone.

