Microsoft quietly pushes 18 new trusted root certificates

http://hexatomium.github.io/2015/06/26/ms-very-quietly-adds-18-new-trusted-root-certs/

by svenfaw • 11 years ago

286 136 11 years ago

hexatomium.github.io

caf• 11 years ago

"RXC-R2" is certainly insufficiently verbose.

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

gnoway2• 11 years ago

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

http://www.cisco.com/security/pki/policies/CiscoRXC-CP.pdf

They should know better.

joosters• 11 years ago

From that document:

3.1.2 Need for Names to Be Meaningful

The Issuing CA shall ensure that the subject name listed in all certificates has a reasonable association with the authenticated information of the subscriber.

The hypocrites can't even manage that with their own 'RXC' CA name.

boardwaalk• 11 years ago

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

chinathrow4• 11 years ago

Quick question: How did you find that document? It's not even indexed in Google so far.

castillar76• 11 years ago

One might gently point out that the SubjectName in that cert is "C=US, O=Cisco Systems, CN=Cisco RXC-R2". Microsoft just seems to have abbreviated it to "RXC-R2".

jbarciauskas• 11 years ago

I saw that and was wondering what he was thinking of. I had to double check to make sure the most recent parliament hadn't been up to any shenanigans, but seems like everything is on the up and up politically there. The ISIS situation is scary, but that's a whole other ball of wax.

userbinator3• 11 years ago

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.

x5n12• 11 years ago

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

themartorana• 11 years ago

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.

paulkon• 11 years ago

If only NCC/OCAP would audit Windows.

Lennie3• 11 years ago

Let's be very clear: if you still think you are 'buying' software from a company like Microsoft you are just fooling yourself. You are paying for a license to use the software. That company still owns the software.

TazeTSchnitzel2• 11 years ago

I don't think automatic updates are used for the root certificate store. They're fetched on demand.

Lennie3• 11 years ago

Yes they are fetched on demand, but that doesn't mean they have a way to update the root-CA list through Windows updates.

For example Windows Updates is used to blacklist CAs certs (like in the case of DigiNotar). The step to adding CAs certs over Windows Updates is really small.

0x04• 11 years ago

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.

hmottestad2• 11 years ago

It still works to hinder that guy who sits at the coffee shop trying to man-in-the-middle attack people connected to hit fake wifi.

If you want a system that can hinder a government doing that, or a large organisation, or a corporation. Then look elsewhere.

Do you remember to wipe your hard drive when you get your computer back from the repair shop? They could very well have installed a new root CA without you noticing....

tokenizerrr• 11 years ago

I always recommend people to take out the hard drive before sending it in. This has caused some small issues, but most stores don't seem to mind as long as you are very explicit about telling them.

0x04• 11 years ago

I wipe before AND after, if I have to hand the computer in for repairs. :)

snowy• 11 years ago

I agree it works against most adversary's.

Wiping your HDD might not be enough: https://blog.kaspersky.com/equation-hdd-malware/

Theoretically you could hide malware in your GPU, USB, FireWire, webcam, NIC, baseband, Bluetooth, where ever.

No matter who you are or how smart you think you are if your adversary is determined and has the required resources they are going to get you.

anonbanker2• 11 years ago

SSL: Even in 2015, still more concerned with the local neighborhood boogeyman then Government intrusion.

sigsergv• 11 years ago

You're absolutely right, and situation is much worse actually. Some time ago another “feature” was introduced — “key pinning”, for some reason it's compared to standard ssh client behaviour (explicit key for given address). But it's nothing similar actually. If MITM have access to any of root certificates installed on your device then he/she could create “valid” certificates that won't raise any warnings in the browser.

There is some addon (if I remember correctly) for Firefox that binds specific key to specific domain and raises warning if certificate changes.

mattkrea• 11 years ago

I think you may be referring to Certificate Patrol (https://addons.mozilla.org/en-US/firefox/addon/certificate-p...)

CyberDildonics• 11 years ago

I still don't understand why there isn't a public private key for each connection. We seem to accept this broken style of encryption instead of pushing for real encryption.

jlgaddis• 11 years ago

Like session keys and PFS?

ajross2• 11 years ago

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.

pdkl954• 11 years ago

You let the USER decide who to trust, as they are the only person who has enough information to do so. Maybe they trust the community for some things, maybe they trust a government for a different set of use cases, and maybe they trust their nerd friend for other stuff.

voidz3• 11 years ago

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.

aeijdenberg• 11 years ago

See also Certificate Transparency (RFC6962) which I haven't seen mentioned in this thread yet - the goals of which are to require all certificates be written to publicly auditable, tamper-proof logs in order to be considered secure by clients. In such a manner certificate mis-issuance will be easy to detect for interested parties. As of earlier this year Chrome is already requiring Signed Certificate Timestamps for new EV certificates in order to display the EV indicator.

https://tools.ietf.org/html/rfc6962 http://www.certificate-transparency.org/

(disclaimer: I work on this project)

wtbob• 11 years ago

ICANN's the obvious choice since they are in charge of assigned names and numbers. They are controlled by a board, who could use a k-of-n signing scheme to sign off on their decisions, to include delegation, and their successors.

Mojah• 11 years ago

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

Teapot• 11 years ago

I trust Mozilla more than Microsoft. Is there any way to simply purge all Windows certs and import everything from cert8.db?

jahnu• 11 years ago

I don't think we can really trust anyone more than anyone else any more. I think it would be trivial for any three letter agency to insert, blackmail and/or buy employees anywhere they want.

Maarten88• 11 years ago

Making a utility for that would not be too hard. But it would probably kill things like the Windows Update process. The Windows certificate store is system wide, and is used for other things besides http.

throwaway54352• 11 years ago

The Microsoft Root CA cert is not included in the NSS trust store. This would break Windows Update (something that Samsung has recently been accused of breaking). So you have to trust the Microsoft CA Root Cert; And if you trust that, you trust they won' sign a SubCA cert, which they could do.

If you don't trust your trust provider, don't use their software?

wglb• 11 years ago

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

False. See slide 73 and forward in http://www.slideshare.net/zanelackey/attackdriven-defense

e12e9• 11 years ago

I did nuke most certs on my Android/Cyanogen-mod phone at one point, and then added back a few at a time. Their list, while I can't speak for the concrete CAs, looks about the right length to me (slieds 75-76):

http://www.slideshare.net/zanelackey/attackdriven-defense

agwa• 11 years ago

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?

javajosh• 11 years ago

So why single out root certificates?

Because you can only solve one problem at a time.

dpacmittal• 11 years ago

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.

ised• 11 years ago

"2. Our software vendors can push new software in automated updates..."

Question: Why does the software need to be updated?

Vendor: "Bug fixes."

Question: Can I look at the source code?

Vendor: No.

I agree with agwa that this phenomenon of "automatic updates" goes well beyond root certificates and browser authors such as Microsoft. It is pervasive and seems to be growing.

Perhaps a related line of thought, I find it interesting that we are seeing some again pushing for enabling browsers to have more control over the user's computer. Simply put, as I see it, a user visits a webpage and someone else gets to run their code on the user's computer.

Why stop there? Why not have email attachments that open and execute automatically?

Originally there was the "Java applet" idea in the early days of the www. Then there was Adobe Flash. These days the idea it has several different working names. Obviously neither Java nor Flash is the language of choice. And the browser authors have something to try to put users' minds at ease: "sandboxing". But I see no difference in the issues this raises for users.

Is there any "sandboxing" for the browser itself? The browser and its authors are inherently trusted?

In the same way that root certificates installed on users' computers are "pre-approved"? Who approved them? Are users involved in that approval process?

If the certificate/code in question comes from the browser authors then it must be both necessary for and desired by each and every user?

The problem with automated updates from my perspective is that there are very few software authors who will not try to give me more than I actually need; if I am not careful I end up with the "kitchen sink". Without user intervention, software is like a gas: it will expand to fill space.

As for the CA system, I am my own CA root. The openssl binary is the antithesis of the so-called UNIX philosophy. How many things does it do? Perfect for an example program to include for "testing". This goes to agwa's comment. I use this software but I know it is quality control disaster. Keep those updates coming.

In any event, the only certificates I "trust" are ones which I did not obtain over an untrustworthy network, i.e., the internet. That number is of course zero.

I will sign a certificate to satisfy a browser, but that does not mean I "trust" any part of the process. In practice, outside of organizational use, I see the whole CA scheme as a joke. (But not that its implementation has impeded the success of e-commerce.)

As a user, I play along with SSL/TLS and certificates only to get today's software to work. That's it. A nuisance more than anything else.

mythz• 11 years ago

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

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.

deckar01• 11 years ago

I had an interview with Douglas Crockford 2 years ago to work on a project that sounded a lot like this. I'm glad to hear it is out in the open.

throwaway54352• 11 years ago

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

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

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

TazeTSchnitzel2• 11 years ago

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.

facepalm• 11 years ago

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.

pdkl954• 11 years ago

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

calgoo• 11 years ago

I agree with you on this. The only way we can trust, is if we know thee people. And even then it's normally not 100%.

For example, if you want to take someone out to a nice restaurant. You might ask friends and colleagues, but some might have different tastes or some might just have an incentive for you to go there. So once you have a few options, you can then Google those choices to see if they match what you are looking for.

So for something as simple as a dinner, we are already doing several checks to validate the place and comments that people have made.

The issue comes when the web is involved, as we expect instant reaction and response. We also hate having to answer repeated question as it interrupts our though process. So we need a web of trust, but also with the option of sharing in you personal web of trust. So for an example, I want to go to page: newcorp.com, but the certificate warns me it's not allowed by my chosen web of trust. So I query so see if anyone on my local web of trust has an allowed setting for this page. It finds that Bob does, but I have set Bob as a low trust setting so it won't allow me to go there, but it will say that Bob's web of trust does. Do you trust Bob's choices to allow access?

This would at least allow people to make choices of trust that they understand. As humans we thrive in groups, as long as they are not to big, and the Internet is a huge group of people. It's a lot easier to choose if I trust Bob from the office then for example Google, ICAN or even Mozilla.

That way, the non-tech people can see the web of trust of their tech friends and make a choice on what they have set.

It's a thought, but I think we need to bring trust and security back to our local, controllable environment. The Internet will keep on integrating with our every day life's in ways that are hard the even think about now. So we need to figure out security and trust now, not once my jacket is talking to the street lamp telling it that the light should be lower because I had eye surgery yesterday and should not have strong lights around me. How the hell do we add security to all those types of functions that will come.

Sorry for the long rant, but it's something that worries me about the future.

userbinator3• 11 years ago

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.

e12e9• 11 years ago

One idea that might be both workable, and possible would be to a) have reasonable way to choose CAs (not just, oh this, XYX corp sounds trustworthy, I'll let them in), and b) have a capabilities system that's not entirely embedded in the CA system.

So, I could have my own CA, or GNU/Debian could have their own CA -- and I/they could sign a capabilites document allowing NORID to sign off on .no-domains, but not on any other TLDs. Or I could trust Microsoft and Google with their own domains (a whitelist), and nothing else.

Such lists could be distributed in a similar way to certs and revocation lists -- and might take us from a 100% broken system, to a 80% working system -- which is probably as good as automated(ish) trust is going to get anyway.

[edit: I don't think delegating trust is completely wrong. It's insane to think that 10 billion people will get the required knowledge to make good trust decision for software etc. Most people can't even do that for normal stuff like money.

Anyone remember nt-bugtraq? I loved that. I still can't read official MS security bulletins. I usually only see that there's a patch, rated at some comically low importance, and usually have no idea if I really need the patch or not. And I consider myself rather technical, and while windows isn't my prime platform, it's not completely alien either.

The summaries on nt-bugtraq was gold. "This is remote root in default install of IIS". Ok, I don't run IIS. Note-to-self, make sure this patch is installed if I do. "This is local login bypass in GINA". Ok, lets install that, prioritize public facing machines. Etc.

That is why I'd like the ability to trust third-parties to help manage trust. I don't think MS is maliciously complicating their security bulletins, I just think they're trapped in an obscure dialect of Coroporatese that I don't speak, and really have no desire to learn.

Maybe I should order a few copies of "On Writing Well" and ship them to Seattle, att: MS security team.]

[ed2: Actually:

https://technet.microsoft.com/en-us/library/security/ms15-ju...

is better than what I remember. Note that the page doesn't mention certificates, and the new update doesn't appear to be mentioned on: https://technet.microsoft.com/en-us/security/advisory

either.]

chinathrow4• 11 years ago

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.

nicolas314• 11 years ago

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

cabirum• 11 years ago

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

svenfaw• 11 years ago

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

sneak• 11 years ago

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

Hello71• 11 years ago

Everything you Need to Know about HTTP Public Key Pinning (HPKP): 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.

Microsoft quietly pushes 18 new trusted root certificates

Related Stories