Further improving digital certificate security
googleonlinesecurity.blogspot.com
googleonlinesecurity.blogspot.com
This type of "pinning" is the only technique that we know of which has actually detected a CA-assisted MITM attack in the wild (a few times now). So it works really well, but only if you're running Chrome, and only if you're connecting to Google (or the few other pinned sites hardcoded in Chrome).
It doesn't scale well because not every website can (or is willing to) hardcode their CA information in browser binaries, the pinned information has to expire at some point (otherwise you can never change your CA), sites are still vulnerable to their own CAs, and it only works in browsers which are willing to maintain this hardcoded list of pins in their client binaries.
Trevor Perrin and I developed a dynamic certificate pinning solution called TACK (http://tack.io) that is designed to address all of those issues. It's a fully specified TLS extension; all we need are browsers to support it.
If you're interested in whats been going on with the CA system, "SSL And The Future Of Authenticity" is a Defcon talk where I discuss some of the problems with CAs, and even interview the original SSL protocol author about them: https://www.youtube.com/watch?v=8N4sb-SEpcg
all we need are browsers to support it
So why isn't it already? Does it need public support? If so, is there a coordinated way we can encourage the vendors to acknowledge it?
My experience thus far is that most browser vendors only have one or two people working in this area of their code base, and those people are so overwhelmed that they spend most of their time just treading water. SSL cipher suite problems seem to be absorbing most of their time lately.
Google has a larger set of really good engineers working in this area, so for the most part they seem to take the lead. Right now, my impression is that they're pretty all-in on Certificate Transparency. The major roadblock with CT is that it requires all CAs to willingly participate. If that's even possible, my sense is that it's a long road, so I would love to see Chrome incorporate TACK in the mean time (and Trevor has even written the patch) while they try to drive CA adoption.
But ultimately, how they decide to spend their time is up to them.
EDIT: Nevermind, I think I understand why it wouldn't work: independently verifying customers is hard, so they would either have to trust each other or spend a nontrivial amount of money verifying each customer. If they trusted each other, the additional security would be worthless, since the host country of the principal CA could just order them to lie. If they each verified the customer independently, they would each incur the usual amount of fixed cost, so they couldn't offer much of a discount.
The UX for certificate trust on the Internet is dreadful and essentially hasn't evolved since the late 1990s. It is badly due for an overhaul. But we can get TACK working today; UX changes could take years.
This makes it sound easy: after all, there aren't many browsers, but really the problem is that everything that talks SSL needs to support it. Browsers are the starting point, after that I guess the OS-level libraries, then everything else.
If you haven't heard about it, it basically requires that a certificate be observed in a central database for the browser to accept it. The server provides a proof (signature) of it being in the database when it passes the cert to the client so no extra connections are required.
This makes it immediately known when another cert is issued for a site.
https://groups.google.com/forum/#!msg/certificate-transparen...
(Symantec is VeriSign)
The efficacy of CT will largely hinge on whether Google can get CAs to participate. Even if they can, it'll be a long road (it already has been), and TACK is immediately deployable in the short term.
"Google is currently operating a Certificate Transparency log, and we are filling the log with certificates that we retrieve while crawling the web. We are also actively working on monitoring and auditing software."
Also, a client can submit their cert to the log regardless of CA support. The only thing CA support is needed for is automated submissions.
A great add-on for Firefox that helps you to detect any possible MITM is Certificate Patrol (https://addons.mozilla.org/en-US/firefox/addon/certificate-p...), it may be a bit annoying for some people though.
X.509 is broken, it only protects you against casual script kiddies on Starbucks. I know about people who deleted the CA directory from their systems, in my case I prefer to use Certificate Patrol (both in Firefox and Thunderbird) or use self-signed certs and then pgp sign the fingerprint.
How does the latter work? Is that possible with Firefox?
Good for you for doing the work, though. You rock.
The problem with PKI is that there's no collision detection. e.g. Under the same PKI same CN should only have exactly one cert.
http://www.ssi.gouv.fr/fr/anssi/presentation/ "The agency is attached to the secretary general of defence and national security".
What is the CA hierarchy "linking back to ANSSI" that chrome is/was trusting? Is the root of that hierarchy still trusted by chrome?
Edit: following link from seszett's post below, hierarchy is at: http://www.ssi.gouv.fr/fr/anssi/services-securises/igc-a/ and the IGC/A certificate is under PM/SGDN in Chrome's authority store.
Chrome gets the list of root certificates from the underlying operating system. Since ANSSI is in the Mozilla root set, it is quite widely distributed.
(Although note that it may be listed under ANSSI's old name: DCSSI, or as "IGC/A".)
I'm amazed that they can run a CA and that nobody find this odd.
The (small) good news is that these delegations aren't intended to compromise the TLS PKI (for instance, to enable dragnet surveillance). Instead, they're a part of the normal security regime within large IT departments. Network security teams want to be able to monitor comms in and out of their networks. Most large enterprise networks require users to navigate through a proxy to get to the Internet, and block direct access. The CA certificate delegation is simply an act of laziness: rather than push a custom certificate to all their endpoints, a big-enough organization might simply buy a CA certificate that will work by default.
The bad news, of course, is that this activity is extraordinarily dangerous to the rest of the Internet. If a delegated CA=YES cert is stolen, the thief can silently MITM connections across the world.
The fix for this problem is straightforward, and already in process. Chrome pins certificates: it hardcodes the relationships between certain sites and their place in the TLS PKI. When users at at networks with delegated ANSSI (or Trustwave or whoever) certs hit Google, the Chrome security team can detect the bullshit cert. This needs to (a) happen in all the browsers, not just Chrome, and (b) incur a CA death penalty in all but the most extraordinary circumstances.
Chrome's ca-chain pinning is only available for a selected group of sites, e.g. google, twitter, tor2web while everyone can get their properties into the HSTS list (doesn't help if any CA goes bad).
This hard-coded, limited list does not scale. We need a bottom-up model, that allows something like pinning or "per-certificate" trust instead of recursive CA trust. This should not only work for things like TLS but also for S/MIME.
In addition, OS and browser vendors should ask the user before some certs are trusted or at least make it very easy to untrust a lot. On OS X it's a PITA to double click every CA cert and untrust it manually.
Anyway, here is the answer of the French Ministry of Finance, who was issuing the certificate (or more exactly, by the ANSSI, but the cert for the the Ministry of Finance):
http://www.ssi.gouv.fr/en/the-anssi/events/revocation-of-an-...
Wrong. It had huge consequences. Users within the French administration lost their ability to securely communicate with Google and who knows what other sites. Additionally, the overall network security was hit by another blow against the SSL trust infrastructure.
This is a seriously bad issue and downplaying hopefully won't do them any good. "We only spied in a very sneaky way on our employees, undermining the trust given us by all browser and OS vendors. Don't worry. Nothing to see here. Too bad we got caught - if we hadn't, we'd just continue".
By having their root accepted into the browsers stores, they took on a huge responsibility which they have now betrayed and IMHO it doesn't matter whether that was the root or one of their intermediates: if they can't control them, they never should have issued these intermediate certificates.
Browser vendors need to set an example and do a Diginotar here: remove that root from the stores. There are already too many supposedly trusted and hopefully competent ones in there, no need for the devious or incompetent ones.
Unfortunately, if the answer to that question is "yes", and the offense triggering removal is "improperly delegated a CA certificate for internal network use", precedent dictates that the CA will not be removed. See: Trustwave.
I don't like it any more than you do, but it's helpful to know what reality looks like.
I just found Diginotar certificates in FF 25.0.1. So no "Diginotar" has been done in FF. At least not what I'd call a "Diginotar": Remove all certs of that organization.
Have you manually added Diginotar back? Has some malware added Diginotar back?
[1]: https://wiki.mozilla.org/CA:Communications
"2) Review your CA operations and customers to ensure that there are no certificates chaining up to your trust anchors that are included in Mozilla’s program that may be used for MITM or “traffic management” of domain names or IP addresses that the certificate holder does not own or control. Mozilla’s CA Certificate Enforcement Policy has been updated to make it clear that Mozilla will not tolerate this use of publicly trusted certificates."
I'd prefer trusting a much more limited (i.e., specifically excluding 99% of national government CAs) set of CAs; and for the major providers that hold my data, including Google, I'd only trust a chain where they themselves are at the top, i.e., where companies such as Equifax and Geotrust (who currently sign google.com certificate) and anyone else is physically unable to issue new certificates for google sites.
A more subtle solution to the CA mess is needed.
The same is for www.thatserviceIreallytrust.com. There should be a trivial, accessible by default way to whitelist them in a way that noone else can make a new 'valid' certificate for them.
https://bugzilla.mozilla.org/show_bug.cgi?id=477147
the CA cert is in the firefox cert store under the name PM / SGDN. Delete at will!
DCSSI, the party discussed in that thread, was re-titled ANSSI in July 2009
CT is a great idea, and the CAs really must pull their collective fingers out and support it, but only works to detect screw ups after the fact.
Meet User B. User B has the same basic computer skills as User A, but User B uses the Chrome browser. Thanks to "certificate pinning", User B cannot monitor what is being sent from her computer to Google.
User B wants to see what is being sent to and from her computer by Google. Can she do this and still use Chrome?
https://isc.sans.edu/forums/diary/Psst+Your+Browser+Knows+Al...
If yes, how would the NSS solution work if the user is browsing from a device that hides and even tries to deny the user access to the filesystem, like one of today's smartphones or tablets?
See Adam Langley's blog about this here: https://www.imperialviolet.org/2011/05/04/pinning.html
This is the answer I was seeking. Thank you!
Government has to go. We gave it a good few hundred years to prove itself, and it can't.
We need massive reform, we should be very careful about calling for revolution, but life without government in some form or other is next to impossible. It's like asking people not to be people any more.
There's even economic models of this. I can't be bothered finding the citations though, apologies.
Actual revolutions seem to involve many years of misery for everyone, and often end up in worse places than where they began.
It may be better than what we have now though.
You could implement a weighted trust system where you're more trusted the more people trust you, and consequently if you "issue" trust it's counted as more trustworthy than issuing trust to yourself.
So you could have the equivalent of CA's in a system like that, but the list could be dynamic based on total trust on the network, instead of being issued by a static list of 100% trusted parties like the system we have now.
This is largely a matter of the game theory dynamics behind this, but if one of them does something bad are the other parties more or less likely to revoke trust? If they easily revoke trust they're creating a dynamic where if they mess up in "minor" ways their whole business could get destroyed. The penalty for not revoking trust soon enough might be much too small to create a system better than what we have now.
I don't know, and I wonder if there's been any research on the various aspects of replacing the CA system with a trust-based system.
The main point is that each user should have their own trust graph, not that there is any single trust network that we all use. Individuals are the entities that make decisions, and any emergent authority that violates the trust of those individuals gets booted by enough they cease to be an authority.
The fundamental problem here is that most individuals don't want anything to do with managing trust. In fact it's not even that, it's that they don't know what trust means, they have no interest in learning and many of them are not even capable of doing so.
The problem that TLS and the authority system try to solve is "how do I set up a secure, trusted connection between two parties who have never met, one of whom has probably never even heard of a key pair". Individually managed trust graphs don't really help there. AFAICT.
>> any emergent authority that violates the trust of those individuals gets booted by enough they cease to be an authority.
Absolutely. But any system should be examined with game theory in mind, and I don't see that web-of-trust is necessarily immune, nor do I see that it pre-empts the kind of problem we see here - trusted parties acting badly for money/legal/government reasons.
I may be wrong, and would actually quite like to be.
Nice try, but now write up your defense against a Sybil attack. Someone could play a long con, gain a lot of trust, and then cause a lot of damage.
Ultimately I think we need something like the blockchain publicly associating a domain with a private key. Namecoins I guess.
Chrome's popularity and Google's use of pinning to their own properties is a pretty powerful combination to detect MITM.
Plus the fact that Chrome reports back to Google when it finds a valid certificate that's not the pinned one.
Dumb question, why then does Chrome on my computer show "Google Chrome is up to date."? Shouldn't there be an update ready? Or is there a different (silent) way to update certificates?
[1] http://en.wikipedia.org/wiki/Online_Certificate_Status_Proto...