Microsoft silently adds Amazon root certificates to its CTL | Hacker News Reader

Microsoft silently adds Amazon root certificates to its CTL

hexatomium.github.io

166 pointssvenfaw64 comments

All Amazon roots are cross-signed by other trusted roots, so they were already trusted by all systems, including Microsoft: https://www.amazontrust.com/repository/

They are also on their way to be added natively to the Firefox root store: https://bugzilla.mozilla.org/show_bug.cgi?id=1172401

Indeed they are cross-signed with a Starfield root, so I wonder, what would be the point of adding them natively? Are there any benefits to that?

Eventually, once the roots are trusted natively in enough systems, dropping the cross-signed root, making handshakes smaller and path-building simpler. Also some of their roots are stronger than the cross-signer, so when/if the cross-signer becomes too weak and gets dropped, the better Amazon roots will stay.

And I guess being a first class citizen of the CA space, which is good because it brings audits, participation and accountability.

>And I guess being a first class citizen of the CA space, which is good because it brings audits, participation and accountability.

Just to clarify on your last point. If Amazon wants to issue certificates it has to conform to industry regulations and undergo audits regardless of if its using another companies' roots.

Is it cross-signed by the CIA, too, though? (one of Amazon's largest customers)

Also, what is it with Microsoft that it keeps "silently" adding root certs to its operating system or other services? Does it really not understand that's highly suspicious? Why not publicly announce it?

This isn't the first time it has done this. It makes matters worse in light of all the "silent" upgrades they are doing to Windows 10, many of them about bypassing tools that are stopping its invasive privacy "features".

>Is it cross-signed by the CIA, too, though?

By design, the CIA cross-signing the cert wouldn't constitute a vulnerability. With that in mind, why would they sign it in the first place?

>Also, what is it with Microsoft that it keeps "silently" adding root certs to its operating system or other services? Does it really not understand that's highly suspicious? Why not publicly announce it?

While I do agree that Microsoft should make some kind of public statement (hopefully still forthcoming), maybe they kept it under wraps until now because Amazon didn't want their new service being revealed before they rolled it out?

I'm not trying to defend Microsoft, or Amazon, or the CIA for that matter, but this article's fairly biased. Hinting at "Amazon is reported to have some very close ties to spy agencies" without expanding on that, seems almost like a clickbait tactic.

AWS just announced Amazon Certificate Manager service, free SSL/TLS certs for assets hosted on AWS[1]. It makes sense to ask trust roots to add Amazon own certs.

[1] https://aws.amazon.com/blogs/aws/new-aws-certificate-manager...

BTW if you request a ACM cert for <domain>, make sure you set up one of the admin@, administrator@, hostmaster@, postmaster@, webmaster@ email addresses for <domain>, as the ACM verification email is sent to these addresses, in addition to the WHOIS registered for <domain>.

The ACM certs cannot be used with an EC2 hosted site.

> The ACM certs cannot be used with an EC2 hosted site.

For clarity, ACM's certs don't come with access to the private key, so you can't install them yourself directly on an EC2 instance. You can easily and fairly cheaply put an ELB or CloudFront in front of that EC2, though.

To be even more pedantic, it's the hostname not the domain. If you request www.example.com you need to have a working MX for www.example.com if you don't have access to the email for the domain's technical contact.

"Amazon is reported to have some very close ties to spy agencies." Why would we trust that any of the other providers would not co-operate with the CIA? Wouldn't they have to under the law?

Do you wonder why the European Data Protection Agencies are getting ready to block all EU-US data transfer soon?

and create their own "security" certificates?

That's probably still better then tolerating economic espionage. But since this very dreaming, I personally still hope for the new Audit of CAcert end of this month. The CAcert root certificate would be a reason for me to use letsencrypt only as a fallback for HPKP.

Didn't realize they were still moving forward with that (despite using CAcerts myself). Thanks for the heads up. I suppose that's as good an excuse as any to hold off a bit on moving to letsencrypt (To be clear, with CAcert not being in any of the default cert-stores, I wouldn't recommend avoiding letsencrypt in favour of CAcert to the casual user -- but I don't (currently) need a widely trusted anchor for what I use CAcert for. Even if it would've been nice if it was widely trusted out of the box).

Why the scare quotes? Some EU countries have a better record than the US on bulk surveillance of their own citizens. It is perfectly natural that if the US won't respect their citizens basic human rights then those countries will have to place restrictions on the US.

EDIT Not to say that all EU countries have a better record. The UK performs bulk surveillance on a huge scale.

It's just an attempt to add a salacious element to an otherwise dry story.

It's like taking the Chevy Bolt announcement and adding "General Motors, owners of the Hummer brand and makers of black SUVs, is known to have long standing business relationships with military and intelligence services."

That analogy is actually pretty weak.

When you buy Chevy Bolt, your not expecting to use TLS to securely lock your doors.

However, if ACM is compromised by a "spy agency" — then anything you intended to be protected by a secure HTTPS transport is now logged, and easily decrypt-able by the "spy agency" at their convenience.

When you buy a Chevy Bolt, you may not realize that a) the government knows everywhere you drive, and b) law enforcement can remotely disable your car via OnStar.

Not a problem unless your a criminal.

With foresight like this, who needs to worry?

Chelsea Manning is a criminal.

Not only that, they can listen to your in-car conversations: http://www.zdnet.com/article/fbi-taps-cell-phone-mic-as-eave...

Why is the key to my car less important than the key to my website?

It's highly likely that my car has a lot of where I go, what I listen to, how long I idle, etc.

If you're really worried about spy agencies tracking you, your car is a much riper target. LPRs are everywhere.

In what scenario is ACM compromised but the spy agency cannot compel Amazon to grant access to any other service?

Changing which private key your ELB used doesn't change the fact that you were already trusting Amazon to operate it.

But with OnStar services, they can unlock your car without your knowledge to do who knows what, and track your vehicle's movements without your knowledge... so, it's not THAT much of a difference.

Isn't SSL/TLS certificates broken when all you have to do is to add one root certificate to MITM everyone else's SSL/TSL?

Yes it is, and we all know it, but we are apparently unable to fix it.

Is it broken when a CA can be compromised without consequence? Is it broken when bad actors can have root certs installed in most browsers?

Yes, it's broken. It's been broken for a very long time.

but all decentralised proposals I've ever seen fall over at scale, or become basically the CA system when applied at a big enough scale.

I would like to be pointed out to be wrong here, though. the current CA system bugs me for the "one CA compromised" aspect.

What about DANE? I would imagine it has potential to do away with CA...

https://www.imperialviolet.org/2015/01/17/notdane.html

Well that definitely answers my question. Thank you. What about something like certificate blockchain?

e.g. https://github.com/okTurtles/dnschain

It already exists and is called Certificate Transparency: https://www.certificate-transparency.org/

holy sh*t it's learning day today! Thanks!

In a way it's broken for the same reason than the banking system was: too big to fail. So many websites rely on a few CA that we can't allow to fail, otherwise we break the internet.

I wonder if we shouldn't adopt a solution similar to what was adopted for banks: a plan for orderly failure. Having a protocole, at least for DV certificates, to easily switch all your website to another CA. All CA would have to implement the same API, and all web servers would be able to consume that API. The same API would be used for auto-renewing certificates. Effectively generalising let's encrypt for commercial certificates.

A protocol should definitely be in place for that, all the updates I do are handled just by using apt-get except for certificates. Like I don't want to handle myself anything related to certificates (including the list of ciphers, the generation of new certificates, the compromised CAs ...), the current certificate system feels like the equivalent of installing updates with .tar.gz archives.

I think that's one of the goals of Let's Encrypt, by developing the ACME protocol, which will be submitted as a standard RFC: https://ietf-wg-acme.github.io/acme/

Well there's public key pinning which helps.

Which is by itself broken. Large websites exchange certificates very often, rendering pinning useless. Unless you are talking not about pinning but about pinning by external actor, such as Google. And that is just moving your own security from hands of CA to hands of Google.

You can pin a certificate higher in the chain, like the root cert of your CA. That way, you can still rotate your own cert, but an attacker couldn't just install a new root cert in the machine, they would have to get a cert from the same CA as your own.

Do any of the publicly available CAs provide a guarantee that you can pin them? I remember there was at least one case of someone pinning a CA and making the news because the page could not load anymore.

I can't say I know, but I don't think they can simply replace them at will, otherwise wouldn't existing certs just stop working?

The intermediates can be replaced without issues, as long as they link to the same root certificates. That's the standard way to rotate them when they expire, or get compromised.

Ah, yes, but my suggestion was to pin the root.

CAs will not arbitrarily throw out their root certificates (they're quite expensive and valuable), so you'll be fine pinning to a root. I'd advise against it when you use OV or EV certificates though, as it'd allow for a DV certificate to still work.

When are you talking about them being replaced? Because I thought website certificates embed the signature of the signer (the intermediate), so if the intermediate is revoked, my website's certificate won't work anymore. If that's the case I should be fairly safe pinning the intermediate for as long as my website certificate is valid.

You can pin (multiple) private keys. Usually, you don't have to change your private key when getting a new certificate (for example, with Lets Encrypt).

If you do want to change private keys regularly, generate them beforehand and pin them.

Isn't adding new root certificates basically the same attack vector as just turning off or routing around your SSL? Who can mess with your certificate store who can't also just run whatever code on your machine?

Dan Kaminsky had a good talk[1] regarding this on 26c3, where he essentially argued that the only reason we have TLS at all is because companies selling stuff over the Internet wants to make it seem secure for the customer. State actors or large companies interested in data mining are not that interested in committing credit card fraud, so every one just accepts the PKI status quo more or less.

Or that was what I took away from what he said. I havn't seen the complete talk since he held it.

[1] https://events.ccc.de/congress/2009/Fahrplan/events/3658.en....

That may have been true with the original SSL, but consider all the B2B APIs, VPNs, and other critical stuff happening over TLS these days.

The problem is the PKI. For your own services, you can have your own PKI, and the issue of "trust one, trust all" is not really an issue anymore because you would only trust your own certificates for your own services.

The problem is that pretty much any CA trusted by your OS/browser can issue certificates that allows anyone who can control your network to MITM you.

A solution for this would be DNSSEC, where only .com would be able to sign foo.com, bar.com and other .com domains. But still, would you trust the issuer of .com certificates?

Yup. What's really, really sad (and an indictment of our entire industry) is that RFCs 2692[1] & 2693[2] provided a mechanism to address exactly this point, but were completely ignored despite being correct.

XPKI attempted to bind a server private key and some sort of global identity, but that only really makes sense with some sort of global identity root. Not wanting to trust all identities to a single CA, we instead … trust all identities to all CAs, which seems a strictly worse situation.

And it turns out that we don't particularly want to bind servers to public identities most of the time, anyway: essentially no-one ever opens a certificate to see what it actually certifies. Amazon is amazon.com; Google is google.com; what people care about is if the server they are visiting is indeed the one they care about visiting — which means that all they really want is a binding of a server to a DNS name.

The way this should work is that (ultimately) the IETF should issue a certificate to each domain holder, valid for the lifetime of that domain's registration. The domain holder would then be able to issue certificates to any subdomain of the domain he holds (e.g. the U.S. government could issue a certificate to va.us, which could then turn around and issue a certificate to fairfax.va.us).

The CA business is a racket. XPKI is fundamentally broken, and no-one cares. We've had a solution for twenty years, and no-one has deployed it.

[1] https://tools.ietf.org/html/rfc2692 [2] https://www.ietf.org/rfc/rfc2693.txt

P.s.: Funny how a Google search can return such different URLs for the same RFCs…

See the info repo provided by amazon: https://www.amazontrust.com/repository/

If there's an issue here, it's not that the root stores adding Amazon's root certs are doing anything nefarious: it's simply that Microsoft should improve their communication.

Could it be they were not provided that option?

Microsoft published their updated list of CAs on their website today, and Amazon is there. http://social.technet.microsoft.com/wiki/contents/articles/3...

IIRC Chrome uses or at least used to use the Windows certificate store. So will it trust these automatically?

Yes, Firefox ships it's own package of trusted roots.

Can someone explain this like I'm 5? I'm not sure what this means and why it matters.

(maybe I got a bit carried away with 'like I am 5' :P)

1. When you type an address in the address bar, (say, www.mybank.com) it is possible for the network infrastructure to take you to mybank.com, but also possible for it to take you to evilsite.com

2. To prevent this, browsers check that mybank.com has a secret number[0]. If not, they tell you the infrastructure is messing with you.

3. To know the correct secret number to mybank.com, you "consult" some other "sites"[1]

4. But how can you tell if those sites are OK? Checking some other site? At some point, you need numbers that your browser knows since installation

5. Amazon just got one of their numbers into the 'internet explorer' browser

6. The author of the article is afraid amazon uses their numbers to 'vouch' for evilsite.com rather than mybank.com (every number in your browser can vouch for any number for any site -- which is kind of dumb)

6a. Also, author notes that, while adding numbers to a browser is usually a big deal, microsoft has not told anyone that they are adding amazon's number

[0] technically correct, but a bit misleading [1] technically wrong, but hey, you are 5

CTL???

Certificate Trust List [1].

> A CTL is a predefined list of items signed by a trusted entity. ... The primary use of CTLs is to verify signed Messages, using the CTL as a source of trusted root certificates.

[1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

Thanks.

Reply on news.ycombinator.com