
Microsoft quietly pushes 18 new trusted root certificates - svenfaw
http://hexatomium.github.io/2015/06/26/ms-very-quietly-adds-18-new-trusted-root-certs/
======
Mojah
I'm glad someone noticed, and at the same time it's a shame it took a month
before the news actually came out.

I think this demonstrates 2 very major problems with SSL Certificates we have
today:

1\. Nobody checks which root certificates are currently trusted on your
machine(s).

2\. Our software vendors can push new Root Certificates in automated updates
without anyone knowing about it.

More content on this rant: [https://ma.ttias.be/the-broken-state-of-trust-in-
root-certif...](https://ma.ttias.be/the-broken-state-of-trust-in-root-
certificates/)

~~~
agwa
Root certificates are just one manifestation of a much larger problem, which
could be described as follows:

1\. Nobody checks the source code of the software installed on their machines
(or that the binaries were actually built from the purported source code).

2\. Our software vendors can push new software in automated updates without
anyone knowing about it.

Suppose that the CA system were replaced with a PGP-style web-of-trust or SSH-
style trust-on-first-use system. How would you know that your software vendor
has supplied you with a TLS implementation that's correctly and faithfully
implemented? Just as they can push out new root CAs, they can push out a new
TLS implementation that introduces a bug or backdoor that bypasses all trust
checks.

So why single out root certificates?

~~~
dpacmittal
If you use Linux, both issues are pretty much sorted. Repositories provide a
great way to install trusted software, if you're careful about which
repositories you install on your system.

~~~
andrewstuart2
Well, the issue of "nobody checks the source" is not necessarily solved. Just
because anyone _can_ check the source doesn't mean anyone actually does.
Additionally, just because a repository has been historically trustworthy
never means it can't be corrupted.

There are real people behind all levels of these projects, and people are
vulnerable to corruption, coercion, etc.

~~~
nickpsecurity
Exactly. I'll add that we keep seeing obvious vulnerabilities in open source
code that go back years. Hence my essay on different types of Source Sharing
and Review that shows the _actual_ assurance is in the review not source
sharing agreement. Hard to assess how much review any given FOSS got and
obviously harder for most proprietary. Sometimes impossible for both.

[https://www.schneier.com/blog/archives/2014/05/friday_squid_...](https://www.schneier.com/blog/archives/2014/05/friday_squid_bl_424.html#c6051639)

~~~
walterbell
Tangent: is there an easy way to find/download all the comments you have
posted to Schneier's blog? They would be more accessible in a github Jekyll
repo, or any source format which could be converted to a single PDF for
offline reading.

~~~
nickpsecurity
Haven't gotten around to doing that since I've been so busy past few years
and... the posts added up to a lot of work. Call it my technical debt. ;)
Hadn't thought of PDF. Nice idea. Right now I have two things: textfile with
links to many key posts there with headings; a zip file with a good chunk of
those in local text copies. I've always used text because it's the safest and
most portable format (except on modern devices lol).

I can give you a pastebin with the links or a link to the zip with containing
the subset I've downloaded so far. Whatever you prefer. Eventually I'll have
one link to an actual web site haha.

~~~
walterbell
Zip of local text copies would be great, thanks!

~~~
nickpsecurity
Below is the link to the zip. I included the two indexes that have the links.
Most designs are local already but the essays folder has only a tiny amount of
my essays. So, look at the essays txt file because there's quite a few great
ones (including OPSEC) that I haven't transcribed yet. Download it quick
because I take it down in a few days.

[http://www.adrive.com/public/uxCBKn/select%20schneier%20post...](http://www.adrive.com/public/uxCBKn/select%20schneier%20posts.zip)

~~~
walterbell
Got it, thanks very much for uploading. I discovered some of your security
essays a few months ago but couldn't find a way to search by poster name on
the Schneier blog.

~~~
nickpsecurity
Ive posted too much for that to even help lol. But ill share some Google Fu to
help you in future:

site:schneier.com "nick p"

First limits to domain. Using quotes limits to results containing that phrase.
A -name removes results containing the name. Can use multiple quoted and minus
terms. Main two tricks I use to get good results.

------
TazeTSchnitzel
Hmm. Are these actually new? Did the OP look at Microsoft's full certificate
store and notice some additions, or did they look at their local machine?
Because in the latter case, Windows does not include a full certificate store.
Rather, it fetches them on demand.

EDIT: I googled the first two. "GDCA TrustAUTH R5 ROOT" and "S-Trust Universal
Root CA" are both new certificates (~Novemeber 2014). The latter is in Firefox
already, and is a new SHA-256 root certificate to eventually replace a SHA-1
certificate for an existing CA.

------
0x0
The CA system is so broken. Letting a vendor decide who you should trust to
issue intermediate certificates that your software will automatically trust to
not issue illegitimate certificates doesn't make the system particularly
trustworthy, especially seeing as they are still adding new root CAs for
entities with unknown agendas (governmental agencies etc).

Maybe the system could be changed to one where domains can only be signed by
the DNS registrar, or something.

It's pretty crazy that any CA can issue a certificate for any domain. And
paying for more validation doesn't help you at all, since it won't keep the
"bad guys" from getting an illegitimate one from a cheaper/lazier CA.

~~~
ajross
> Letting a vendor decide

The problem with the root of trust problem is that you have to trust
_someone_. Who is your preference? The government? The registries? ICANN? The
hardware vendor? Those are all suspect too, and most have been historically
compromised.

The only thing I can see that helps is "community" auditing -- things like
Chrome's pinning and ... the action that discovered these new certs. So, as
much as it sucks, we're sort of doing the right thing already.

~~~
voidz
> Who is your preference? The government? The registries? ICANN?

No, silly: the domain owner! Something that's already possible with DANE: the
domain owner gets to decide, as it should be, by publishing information about
valid certification into the DNS.

Of ALL options this one is the least crappy IMO.

~~~
ajross
And who authenticates the domain owners? Your solution is basically "trust the
registries" then. OK, fine. But they've screwed up in the past and they will
in the future.

~~~
voidz
huh? No, for DANE it is required to have DNSSEC in place. Also read the last
sentence of my previous statement again.

~~~
realityking
And now you're trusting the registrar, the registry and ICANN. It's always
pick a poison.

Also, DNSSEC still has some severe issues in practice. I'd be glad if we could
get DANE widely deployed for mail servers.

Edit: Oh, and if you're not using a validating resolver yourself you're also
trusting that you're ISP is using one and not manipulating the responses.

~~~
marcosdumay
> Oh, and if you're not using a validating resolver yourself you're also
> trusting that you're ISP is using one and not manipulating the responses.

I really don't understand why people keep repeating that complaint. Of course,
if you don't check the keys you don't get any security.

How is that a problem of the algorithm? And how is that a problem on practice?
If you want some real amount of security you check the keys, being them SSL
certificates, DNSSEC signatures, or whatever else encryption system people put
on place.

~~~
realityking
You're speaking from the perspective of somebody who could set this up for
himself. "Normal" people don't know stuff like this, but we can't leave them
unprotected.

That's why DANE for mailserver is such an attractive target. They're usually
run by people who know what they're doing and it helps bring a lot of
infrastructure into place.

~~~
marcosdumay
The point is that there's nothing for normal people to setup (or, at least, it
does not have to be). Your email software should verify DANE keys, just like
your browser verifies TLS keys.

The fact that current software is hard of configure is just a symptom that
it's badly designed. The only inherently hard thing in DNSSEC is distributing
your domain data (not really harder than setting our server for TLS), and
normal people do not do that.

------
userbinator
It's good that someone noticed... if you have automatic updates enabled, you
have implicitly consented to giving Microsoft what is essentially a root
account on your system. They can modify it to both fix - and break - things
just as easily.

~~~
x5n1
if you deploy an os from a company, consider your box belongs to them.

~~~
themartorana
Let's be honest - if you don't vet every single line of code in your OS and
software toolset, you run the risk of exposing yourself. There are levels of
trust to be sure, but there is always trust.

~~~
x5n1
Honest is that if all the source code that is compiled is available as open
source and a binary with the same signature can be built using that code then
the chances that the code acts against your interests is much less than binary
blob that you can not vet... etc.

~~~
Lennie
I'm a Debian user:
[https://reproducible.debian.net/reproducible.html](https://reproducible.debian.net/reproducible.html)

Partly because they do care about these things and they are sending patches
upstream as well so as many as possible applications in Debian can eventually
be build reproducible.

I hadn't seen it before, but even better they added this piece of text on that
page: "we care about free software in general, so if you are an upstream
developer or working on another distribution, we'd love to hear from you! Just
now we've started to programatically test coreboot and OpenWrt - and there are
plans to test Fedora, FreeBSD and NetBSD too."

------
pdkl95
We need _dynamically selectable trust_.

I don't mean the simple ability exposed in most browsers to add/remove certs.
That still assumes one _set_ of trust that used globally, which is completely
incorrect.

Maybe I don't trust $COUNTRY to handle their root certificate for most uses.
Currently we handle that case by removing the cert completely. Trust, however,
is _not_ a simple boolean value, and maybe I do trust that certificate for
$COUNTRY's official government pages. I should be able to specify that I trust
some certificate for some domain (or other, non-domain based use!), but not
for others.

As another example, consider a local Web Of Trust. whenever Web Of Trust is
brought up, people complain about the difficulty of key exchange. Well yes,
that's a difficult problem, but there is no reason that it has to be solved
for _all_ use-cases before anybody starts using it. Maybe a circle of (usually
physically local) local friends want to have secure communications. They can
share a key in person easily, and so it should be easy to give access to a
private forum by simply sharing a key/cert on a USB disk.

We can currently _approximate_ those cases, but it is not well supported, and
is certainly not something that most users would be expected to be able to do.
We can fix some of that with a better UI, but I'm suggesting a far more
fundamental change, because actually solving problems like key sharing will
not be easy, and I suspect they will only be solved once we have
_infrastructure_ in place. HTTP was successful because it did _not_ require
that everybody implements the full, fairly complex specification. Instead, we
had a fluid, extensible protocol that allowed _anybody_ to extend it, and that
allowed for the development of a wide variety of software.

The problem with traditional PKI (at least as implemented) is that it assumes
that we can assign an absolute trust value to _anything_. In reality, trust is
relative, and may in fact have multiple values at the same time. Until
software is designed around those realities, it will always be inflexible and
insecure for any use case where the needed trust assumptions do not reflect
the assumptions made by the authors the software.

Unfortunately, I'm a old-style UNIX nerd who is fine with using GPG, and I'm
not sure what the UI for a dynamic-trust system would even look like. _sigh_

~~~
userbinator
_They can share a key in person easily, and so it should be easy to give
access to a private forum by simply sharing a key /cert on a USB disk_

The truly paranoid would probably prefer a printout on paper; I've actually
done this before with HTTPS self-signing.

------
mythz
Douglas Crockford has an interesting video on why CA system is broken and how
it can be fixed in his recent "upgrading the web" talk at:
[https://angularu.com/VideoSession/2015sf/upgrading-the-
web](https://angularu.com/VideoSession/2015sf/upgrading-the-web)

Essentially he's proposing side-loading a new application under a custom url
scheme so that the browsers will launch a helper app that's used to handle web
applications with the following url format:

    
    
        web: publickey @ ipaddress / capability
    

The url contains servers ECC521 public key as part of the url so that it gets
around the CA System and clients can just encrypt requests with the servers
published public key directly.

He's planning on developing the helper app that's based on a sand-boxed
node.js and QT application which just uses a TCP session to communicate with
the server.

~~~
throwaway5435
Problem with 'ECC521' is that Google have all but killed P-521 support in
Chrome.
[https://code.google.com/p/chromium/issues/detail?id=478225](https://code.google.com/p/chromium/issues/detail?id=478225)

Mozilla are considering doing this also.
[https://bugzilla.mozilla.org/show_bug.cgi?id=1128792](https://bugzilla.mozilla.org/show_bug.cgi?id=1128792)

This is not just browser support -- its TLS library support.

------
caf
"RXC-R2" is certainly insufficiently verbose.

I think the author might be a bit behind the news on Tunisia, though.

~~~
gnoway
For anyone wondering, it's the Cisco CA/B-F Root CA:

[http://www.cisco.com/security/pki/policies/CiscoRXC-
CP.pdf](http://www.cisco.com/security/pki/policies/CiscoRXC-CP.pdf)

They should know better.

~~~
boardwaalk
Does anyone know why Cisco would need a root CA on Windows machines...?

~~~
MichaelGG
Maybe as part of a way to secure the connection to their appliances? They
could auto issue certs after verifying ownership. Maybe they're gonna give
appliances a name off their own DNS <whatever>.mycloud.cisco? Hell maybe
they're becoming a real CA and gonna sell trust services.

Dunno how MS's process is, but with Firefox there's a nice application process
that's very open and you can see their claims.

~~~
chinathrow
Indeed.
[https://wiki.mozilla.org/CA:How_to_apply](https://wiki.mozilla.org/CA:How_to_apply)

However, nothing to bee seen in bugzilla about Cisco regarding their new CA. I
wonder if it is MS only?

[https://bugzilla.mozilla.org/buglist.cgi?quicksearch=cisco](https://bugzilla.mozilla.org/buglist.cgi?quicksearch=cisco)

~~~
e12e
Requiring Internet Explorer for switch management sounds like exactly the kind
of stupid Cisco might go for.

These days Chrome/chromium uses the system store AFAIK, so at least you can
get surprising breakage in your management tool that isn't due to TLS, but
rather some kind of IE compatibility hack... ;-)

------
facepalm
They silently installed all the previously existing ones on my system, too. So
did Apple on my Mac, and Ubuntu on my old notebook.

Maybe I should, but I am not going to individually double check every root
certificate. I don't think I have the means to do so either.

------
Hello71
Everything you Need to Know about HTTP Public Key Pinning (HPKP):
[http://blog.rlove.org/2015/01/public-key-pinning-
hpkp.html](http://blog.rlove.org/2015/01/public-key-pinning-hpkp.html)

> A flaw in this system is that any compromised root certificate can in turn
> subvert the entire identity model. If I steal the Crap Authority's private
> key and your browser trusts their certificate, I can forge valid
> certificates for any website. In fact, I could execute this on a large
> scale, performing a man-in-the-middle (MITM) attack against every website
> that every user on my network visits. Indeed, this happens.

> HPKP is a draft IETF standard that implements a public key pinning mechanism
> via HTTP header, instructing browsers to require a whitelisted certificate
> for all subsequent connections to that website. This can greatly reduce the
> surface area for an MITM attack: Down from any root certificate to requiring
> a specific root, intermediate certificate, or even your exact public key.

related previous articles:

Firefox 32 Supports Public Key Pinning (188 points by jonchang 304 days ago |
100 comments):
[https://news.ycombinator.com/item?id=8230690](https://news.ycombinator.com/item?id=8230690)

About Public Key Pinning (72 points by tptacek 43 days ago | 5 comments):
[https://news.ycombinator.com/item?id=9548602](https://news.ycombinator.com/item?id=9548602)

Public Key Pinning Extension for HTTP (70 points by hepha1979 242 days ago |
28 comments):
[https://news.ycombinator.com/item?id=8520812](https://news.ycombinator.com/item?id=8520812)

------
chinathrow
It's easy to call the CA system broken (and I think it really is), but other,
better solutions are not that easy currently.

We want an open, yet secure web, anonymous at best. With the current setup,
that is not so easily possible. Letsencrypt might help, but even with that,
there is still someone you need to beg for a signed cert.

Maybe we need to think ahead.

------
cabirum
@svenfaw, your RCC scanner says "Exiting... [Reason: signature database
appears to be out of date.]", why is that?

~~~
svenfaw
Sorry about that, the website still had an old RCC build. If you download it
again, you should get the current version (1.49).

------
nicolas314
For information: OpenTrust (3 roots) is just the new name of the entity that
was once Certplus (1 renewed cert).

------
mkramlich
one word. or 4 letters. understand them and you understand everything else
about this issue:

MITM

------
sneak
It's okay, most apps don't bother checking certificate validity anyway.

