None of them appear in my Windows PC (Windows 7)…A Windows 7 PC has 38 Certificate Authority certificates installed. My Mac OS X Yosemite has 217 Certificate Authority certificates installed.
This is a poorly-reseasrched comparison, because Windows downloads root certificates when they are first encountered (see http://support.microsoft.com/kb/931125).
"When a user goes to a secure website (by using HTTPS SSL), reads a secure email message (S/MIME), or downloads an ActiveX control that is signed (code signing), and then encounters a new root certificate, the Windows certificate chain verification software checks Microsoft Update for the root certificate. If the software finds the root certificate, the software downloads the current Certificate Trust List (CTL). The CTL contains the list of all trusted root certificates in the program and verifies that the root certificate is listed there. Then, it downloads the specified root certificate to the system and installs the certificate in the Windows Trusted Root Certification Authorities Store. If the root certificate is not found, the certificate chain is not completed, and the system returns an error. "
This means that Microsoft can add a new root certificate to a user's system at will.
I'd argue that this is actually much less secure, given that by default a Windows machine has an unauditable list of root certs, which change based on what Microsoft supplies. That means that a third-party (let's say a government) can force Microsoft to add an arbitrary root cert to the list, and a user's machine will blindly accept certificates signed by it!
Of course the entire model is broken, if you are looking for un-crackable end-to-end security.
The list of root certs is distributed as an update through Windows update. It is not just an on-demand root cert. An organization that vets updates before applying them to production systems will also need to vet such an update.
The updates are indeed very auditable. Any organization who chooses to selectively apply updates will not have new root certs appear out of channel.
Of course Microsoft needs to be able to update the root cert list. It has been used to remove certs as well (Diginotar). However, when they do so, it needs to be transparent. Windows Update is transparent. The very article you linked even goes into details about this.
Which means that your claim that "Microsoft can add a new root certificate to a user's system at will" is false. If you do not automatically install all updates or if you use WSUS, root certs will only be updates if you allow the update through.
The process outlined in your linked article describes how Windows will attempt to find and install the Windows Update package from the cert chain. This does NOT bypass the Windows Update mechanism; it merely looks for a package in the catalog with the root cert that was requested by following the chain.
So can Microsoft. The difference between Microsoft's "Search and pull" means that Apple needs to bump OS X's revision number or apply a Security Update, both which are visible as a red badge on the "Updates" tab of the Mac App Store. Microsoft doesn't need to even apply a super generic KB update.
To my best knowledge, activists from China did plead to remove CNNIC (China Internet Network Information Center) root cert from Mozilla Firefox but failed.
I'm not sure that this is particularly interesting news. For starters, when "the government" wants to spy on you, they generally want to do so in such a way as to not reveal that they are doing so - using their own CA is a big tell that something fishy is going on (yes, only if you have the know-how and inclination to do so, but I'm thinking that this is probably the case for most people trying to keep secrets from the government).
No, if they want to hack your SSL comms, they aren't going to do it by using a MITM attack backed by a government-issued root CA, they are going to do it by gaining access to a "neutral" CA (such as Verisign), and obtaining the root certificate's private key. Now you would have a much harder time of figuring out that something has gone wrong, but then, if you're paranoid of the government spying on you, and you are using a CA other than one you own yourself, you've already lost the battle.
Trust is a Hard Problem(tm) to solve. Without using Certificate Authorities that you don't personally know, it is difficult to create a sufficiently trusted network. I think the best attempt at a description of such a system that I have seen is in Cory Doctorow's "Little Brother" (http://craphound.com/littlebrother/download/), but even there it seems to me that there were numerous problems for scaling, or even just avoiding invaders.
All of which is to say that certificate-based technology couple with CAs that you don't control is not a solution against state-level adversaries. Which in turn makes this entire article fear-mongering rather than a real discovery of a potential threat. In a more cynical mood, I might wonder about the author's motives, was this an attempt to distract away from the fact that the main CAs are not secure against state actors?
I agree, this is not really breaking news. The reality is that any company that wants to operate within the confines of the law can be compelled to work against its purported customers -- no one wants to go to jail because of your website.
One nit to pick: obtaining Verisign's root CA key isn't enough to decrypt traffic over the wire. That would just allow Uncle Sam to issue fake certs that appear to be from Verisign. I think that savvy users might still notice that their cert looks different now (fingerprint, expiration, other details), and put the pieces together. Maybe you use a CA whose root key hasn't been obtained yet. I highly doubt the NSA or whomever would let a fake but validly signed cert into the wild where it can be captured and used to prove their capabilities once and for all.
They might use such a cert in a controlled environment where they are going to seize the target's system in a few minutes, I suppose. Instead, what they really need is either a way to break 2048-bit RSA (not inconceivable) or a way to get your real cert's private key.
To your point about trust and CAs: I don't think it's truly a matter of trust. Verisign, GlobalSign, Digicert, Entrust, et. al. are all businesses. They are not inherently untrustworthy (nor trustworthy), they do what they must to be profitable and stay in business. It turns out that end user trust is substantially less important to that equation than remaining in compliance with the government of their host country.
I don't know how you solve that problem. The best thing about the early Internet was that, while heavily US-centric, it was often able to fly under the radar of government oversight and, to an extent, the rule of unpleasant laws. That's no longer possible. The Internet is a source of power and money, and now it has to contend with the oversight and regulation of thousands of governments doing what they do.
There isn't any way to solve it. People's fears about the PKI boil down to "if I trust anyone else at all, they might betray me". And yet using encryption without trusting other people is impossible. You aren't going to build your own computer from scratch, for example.
I think our industry needs to collectively move beyond "zomg CA's are pwned by governments". It's just unhelpful. Firstly there's no evidence it's true. A bogus cert would be strong evidence, documents from the Snowden archive talking about compromising CA's would be evidence ..... so far we have zilch.
But even if one day it does happen - what next? You end up down the "what if my CPU is backdoored" rabbit hole. Ultimately you have to ignore adversaries that have unlimited power and focus on the ones that do have limits. There's no other way to stay sane.
I agree with you, from a day-to-day standpoint there really is nothing to be done and little point in worrying about it. The only solution is to stop using technology, and that proposition isn't very attractive.
While the ideal solution is technical -- no one can see or interfere your stuff without your permission -- it isn't practical. Solving the problem with laws and societal pressure is more realistic, although still verging on impossible.
"You think your HTTPS connection is securely encrypted, but wait, couldn’t the U.S. government generate a brand new fake certificate, give it to the NSA, and then serve that to you? Your web browser won’t raise any alarm bells. The SSL certificate is valid, and it is signed by a Certificate Authority that is trusted by your computer."
I think it's highly unlikely that they'd do that, as there's a chance that the fake certificate could be used as evidence against them later. A valid certificate for google.com signed by the US Govt CA would raise a few eyebrows.
If the NSA really wants to MitM you, it wouldn't surprise me if they had backdoor access to the real GeoTrust Global CA, either by bribery, National Security Letter or even "dark arts" that the real GeoTrust knows nothing about.
Bear in mind they don't actually need to hack or coerce a CA to get them to issue a fake cert. CAs check ownership of a website by either sending an email or doing a regular HTTP request to the website i.e. doing the sort of request that QUANTUM is very good at intercepting and redirecting.
In other words the NSA could MITM the CA<->website connection and get themselves a cert issued in the regular manner.
However I do not believe they are doing this at any meaningful scale, and possibly not at all. It's clear from the Snowden archives that they focus almost exclusively on malware. That has a lot of advantages for them over creating fake SSL certs.
Also bear in mind that certificate transparency is a multi-year plan to prevent secret issuance of certificates. So there is effort being done to reveal such attacks even before they are happening. Not too shabby!
> I’ve been sitting on this information for some time, waiting to get more research done before I publish a post.
You've been sitting on common knowledge for some time? Research into what?
Sorry but this is a very well known issue with HTTPS that has been discussed in depth for the last few years, in particular with people suggesting alternatives and improvements to HTTPS (like certificate pinning, Convergence[0], etc).
The fact the author thinks they have found some type of unknown or smoking gun says more about the author than anything. I mean heck you can go back and find tons of examples of root CAs "mistakenly" generating fake certificates for things like Google or Windows Update. You can also read about entire countries being victim of it [1].
I don't think that's a very helpful way to look at it though. The PKI system has been around for 20 years, was designed to stop credit card theft, and we can sum up the number of times it's been seriously breached on the fingers of one hand.
Many other security systems have failure rates measured in percent, so I don't think it's doing so badly.
We keep a running comparison of one such solution (DNSChain) to many other proposals folks have made (including Convergence, Perspectives, Certificate Transparency, DNSSEC, TACK, HPKP):
We should come up with a scheme where certificates are signed by multiple CAs (or you have several cross-linked certificates). If one signature changes but not the others, you know something is wrong [1]. It would be beneficial to use CAs from different political blocks, like one from the US, one from China, and one from the EU, to reduce the risk of collaboration.
Of course, a MITM attacker would just strip all certificates and send only theirs along, so you have to have a way to enforce multiple signatures from different blocks. Maybe a httpss url scheme or something.
Let's encrypt is the exact same trust model as conventional CAs selling you a DV certificate. Apart from that, the trust model in the public CA system does not and cannot vary by CA: you trust them all, equally, all the time.
Sorry, I meant the nature of the CA as a public benefits corporation that is more open than conventional CAs. Meaning maybe I personally trust them a bit more than Verisign -- although I haven't decided if I do, and really any CA will betray you rather than go to jail on your behalf.
Their certs are indeed the same DV type as always.
Makes sense to me, and I think this is the future of the web. HTTP will simply cease to be a viable option in the next 3-4 years if cert prices are reduced (or eliminated) and SNI becomes widely available.
Good for Let's Encrypt in taking the initiative to make this happen sooner rather than later.
This is not news. The CA system is broken by design. It's been this way from the start. Not just on OSX but on all platforms.
Your browser blindly trusts a list of a few hundred CA's, any of which can impersonate any SSL site you visit at any time (except for the chosen few that use certificate pinning)
Many of the biggest CA's (e.g. Verisign) are under government control.
The browsers could start not trusting those CAs, and not allowing them to impersonate any SSL site you visit, and they are making steps towards this with measures like pinning aren't they?
Measures like that just need to be made the default, and if companies want the ability to MITM they should have to adjust settings to make that happen, but consumers should not be vulnerable to that by default and browser vendors could work towards that future. At least people are now more aware of these issues, and that a green lock really doesn't signify much if a government takes an interest in your communications.
The classic manual method of cert pinning is not feasible for more than a handful of large sites, because each browser that supports it has to update its own pin list.
Google adds a whitelist of public keys to Chrome upon request, only for high impact sites. Firefox does the same, with a different list. Safari doesn't support it at all. IE supports it in a useless fashion.
This is totally unworkable in the long term. Broader support also opens it up to smaller (less savvy) sites who will inevitably get bitten by a lack of foresight. "Oh, I only authorized GoDaddy and now I use Entrust...". However, set too broad a list and you've just given an attacker a list of targets to pick the weakest link from, possibly not dissimilar from choosing a target amongst "all CAs clients support".
The manual method is not the only way, and it's always been apparent that it was not the end game. HSTS and HPKP are important steps forward, and support is decent. As always though, IE is a useless impediment to progress.
To give a real example, CryptoCat managed to commit pinning suicide recently. They requested a pin in Chrome and then their CA's intermediate expired, meaning they had to reissue the cert .... but failed, because Chrome rejected the new cert. They had to wait for the next Chrome version to recover and basically had a multi-week outage because of it.
Pinning eliminates CA's by eliminating the agility they provide. Not inherently an awesome deal.
You really need at least one alternate (from a different company!), even though that reduces security. 2 is still better than 150. I'm surprised that Google would accept a one hash pin, but I guess they'll let you shoot your own foot off if you want to.
The other side of that is you must actually be able to issue certs from that other CA. If you have to wait for your account to get set up and verified, you've lost.
Browsers shouldn't be making the decision of who to trust or not trust. They should be presenting the information for the user to decide. If the user decides to trust the US government more, that is their choice. The browser should inform, but not make that decision for the user. The only thing the browser should be doing is making it as difficult as possible for that decision to be subverted.
When scanning through the list of CAs on my machine, so many of them sound like unknown entities who I have no idea whether or not to trust. So it's difficult deciding whether I should remove any of them or not.
What would really help in this would be to know if any of these CAs have signed certificates for popular websites. Rightly or wrongly, I'd trust a CA who has certificates in active use by many sites over an obscure foreign (or not?) government CA who doesn't seem to sign any certificates that I'd normally interact with. After all, if suddenly one day ycombinator.com's site appears to be now signed by an obscure CA, I should probably be worried.
So, is there any way to map a given CA to the subset of the top 1000/10000/whatever number of websites that have certificates signed by it? Surely some webcrawlers must have indexed a large number of site certificates and have the data to build such a database.
However, in any case, there are already so many CAs, that I am wondering what is preventing governments of forcing one of them to provide a fake certificate that suits their needs for national security reasons...
What "stops" them (to the extent that anything stops a government that is ignoring their own laws) is that the agreements CAs sign with browser/OS makers don't have any provision for issuing fake certs just because a government requested it or compromised the key.
That means if anyone found evidence that a CA was issuing bogus certs (such as one of those certs), that CA would be revoked and bankruptcy would follow soon after. The fact that they were just obeying a court order wouldn't be considered relevant by the browser makers, especially if it's an obscure and little used one.
There are other forms of punishment beyond outright revocation. A CA owned by the French government did something bad at some point (I forgot what), and instead of total revocation they were name constrained to .fr
But basically, forcing CAs to co-operate with you against the contracts they've signed is a very limited strategy. Most governments outside the US government can only do it once or twice before there are no more CAs left in their jurisdiction. Not to mention the legal mess that would result from a company beyond forced to commit suicide to help an intercept operation.
ANSSI if I remember correctly, and one of their intermediate CAs issued an intermediate that was installed in a MITM device. They seems to be phasing out the root now BTW.
There's not much to protect against that. But looking for 'perfect' CA protection is hopeless. At least by eliminating the more untrustworthy CAs you can protect against some attacks.
Certificate Transparency does little to solve this problem. It doesn't stop MITM attacks. It might have a chance of helping a small number of companies that have the resources to monitor all logs, but that's after the attack and only if all relevant CAs are participating in the system. It gives ordinary users nothing and requires sysadmins to go to extreme lengths. Most websites are unlikely to benefit:
We've been working very hard on an alternative proposal that prevents MITM attacks called DNSChain, and we keep a running comparison of it with other proposals folks have made here:
The problem is trust and given the current SSL authority scheme, can not be solved.
It's a choice that users must do, not the OS. I don't blame computer manufacturers for adding these certs to their systems, they try to make browsing as easy as it gets. Theoretically speaking, the government is your friend. Practically speaking, if you're into any business that requires extra security, you need to take control of your OS at much deeper level, which probably means running something Open Source and manually checking the certificates that came along with your system and your browsers.
I could see another weaker but immediately implementable approach to just issueing a list of domain-root certificate maps that someone would have to manage :
Why couldn't browser issue a warning whenever the root CA for a known domain has changed compared to previous browsing sessions ?
I suppose MITM attack are targeted and probably depends on the network you're using. If there's a difference between the root certificate for google.com when surfing with your laptop at home or from the office, then there's probably something wrong.
It's a bit similar to what ssh is doing with cert/ip associations.
That's what certificate pinning is for. And of course, Chrome already refuses to connect to Google if the certificate doesn't match what Chrome expects.
Pinning has a lot of problems. Copied from our Comparison [1] docs:
Both TACK and HPKP are mechanisms for doing public key pinning for individual websites.
These mechanisms are similar to how SSH uses a known_hosts file to store the fingerprints of public keys it encounters on a "Trust-On-First-Use" ("TOFU") basis.
The problem with these mechanisms is:
* They don't protect on first visit.
* They break websites when the public key needs to legitimately change.
* In the case of TACK, the TACK public key needs to change very frequently (at least every 30 days). This defeats the purpose of pinning, as a MITM does not need to wait long before they can present a fraudulent key that the user has no way to know is legitimate.
* These mechanisms assume that client software has its current time set properly, and they break when that's not true.
While DNSChain does use public key pinning, it doesn't have these problems because there is only one pin that is ever required: the pin to DNSChain itself, which is easily verified once only at setup.
I love the concept of certificate pinning, but I don't see how it solves the core problem:
User: Why should I trust this root CA to secure this domain?
Domain Owner: How can I specify which root CA should be trusted to secure this domain?
If neither of these parties are significantly involved in the trust decision, how can it be said that trust has been established at all?
Most pinning implementations seem to either delegate the trust to someone else (browsers, OS, libraries, etc.) or blindly trust the information presented in the first encounter. This is no different than the historical model. There's nothing preventing any application from presenting a warning when a known certificate changes or a new one is encountered, so what does pinning offer other than extra complexity?
Locally cached relationships aren't any more viable than using an /etc/hosts file for the whole Internet (and pose additional privacy concerns). Leveraging DNS is a worthy goal, but if it was secure enough for this purpose, it would eliminate the need for pinning because a domain owner could confidently present its public key via DNS.
I believe in defense in depth, and this work is important, but we seem to be making little progress in solving the fundamental problem of establishing trust. Maybe it's as unsolvable on the Internet as it is in the real world.
The biggest problem with MITM is not interception it is potential manipulation. Despite being a clear violation of your constitutional rights we must look beyond this at what is clearly the bigger issue: can we trust the legitimacy of any information encoded into a digital form when organizations such as the NSA and FBI have immense amounts of power to tamper with connections. Evidence can clearly be misrepresented, manipulated, or even planted on unsuspecting Americans by our government or other foreign governments.
It's technically illegal for the NSA to intercept the Internet traffic of American citizens, but that doesn't mean the US Government can't supply certificates to GCHQ and company.
If American values are so great, why do they stop at American borders?
Ok, I know why. But it's infuriating to watch the U.S Government throw it's weight around in other countries under the guise of spreading democracy or "cooperation", but then operating like a totalitarian police state anywhere it sees fit.
It's not O.K. that Americans get a better deal than everyone else when it comes to privacy and security. Especially not when the U.S government acts like the World Government in real terms.
I really don't have a problem with the U.S running things. I have a problem with the U.S. running things for the the exclusive benefit of America... whatever America is these days. It's certainly not the American people anymore.
EDIT to add, I'm not attacking your comment by the way. I'm jumping on the "illegal to spy on American citizens" bit, which we also know is untrue in real life.
Perspectives is a new approach to helping computers communicate securely on the Internet. With Perspectives, public “network notary” servers regularly monitor the SSL certificates used by 100,000s+ websites to help your browser detect “man-in-the-middle” attacks without relying on certificate authorities.
Why doesn't the browsers collect information from its users (if they agree to it) about which CAs are used by which domains - and display a strong warning if a different CA than the norm tries to issue a certificate?
Because the m/billions of users bar a few thousand will have no idea what to make of the warning. I mean I don't even know what constitutes a "normal" CA.
And to be honest who really cares. Countries increasingly are mandating invasive spying through legislation. Arguing over CAs is like rearranging deckchairs on the titanic.
It wouldn't be much different than certificate pinning is today, just a crowdsourced version.
Sure, the CA system should be replaced altogether, but that's going to take quite some time. In the mean time I think the idea I mentioned could be useful to avoid invisible man-in-the-middle attacks by the CAs. It only requires work by the browser developers, while changing from CAs to something else will take a major effort by everyone who's running a part of the web.
Users don't react well to such warnings, but on the software side there is the emergent concept of certificate pinning -- Chrome, for instance, reports to the mothership if an unexpected CA is found to have generated a Google certificate (it simply flags on an unexpected certificate, though usually that means an untrusted CA). Not sure about the scalability of the solution, but ultimately domains should be able to securely delegate authoritative CAs.
However then you get to the same market issue that allowed the whole Superfish and related debacles -- Enterprises require the ability to self-CA everyone else given that they demand the right to MITM.
The article is somewhat wrong in that for google.com in particular the browser would show an HSTS warning and disallow access completely, as it is a pinned cert.
These problems in SSL and the kludges in HTTP/2 to avoid connection overhead would be greatly reduced by moving to a proper dnssec, ipsec, and tcp reimplementation.
> Sidenote: A Windows 7 PC has 38 Certificate Authority certificates installed. My Mac OS X Yosemite has 217 Certificate Authority certificates installed.
Windows 7 was released 5 years ago. Might be more relevant to compare to Windows 10 given that Yosemite is updated quite regularly.
This is a poorly-reseasrched comparison, because Windows downloads root certificates when they are first encountered (see http://support.microsoft.com/kb/931125).
"When a user goes to a secure website (by using HTTPS SSL), reads a secure email message (S/MIME), or downloads an ActiveX control that is signed (code signing), and then encounters a new root certificate, the Windows certificate chain verification software checks Microsoft Update for the root certificate. If the software finds the root certificate, the software downloads the current Certificate Trust List (CTL). The CTL contains the list of all trusted root certificates in the program and verifies that the root certificate is listed there. Then, it downloads the specified root certificate to the system and installs the certificate in the Windows Trusted Root Certification Authorities Store. If the root certificate is not found, the certificate chain is not completed, and the system returns an error. "
This means that Microsoft can add a new root certificate to a user's system at will.
I'd argue that this is actually much less secure, given that by default a Windows machine has an unauditable list of root certs, which change based on what Microsoft supplies. That means that a third-party (let's say a government) can force Microsoft to add an arbitrary root cert to the list, and a user's machine will blindly accept certificates signed by it!
Of course the entire model is broken, if you are looking for un-crackable end-to-end security.