15

So a Certificate Authority certifies that a website corresponds to a given organization. Why is this necessary?

When I interact with a business or organization, I do it one of a couple ways:

  • I interact with them physically in real life, or through mail, or what have you. I can just get their public key when I meet with them.
  • I interact with them solely digitally. I start with no reason to trust them, but gain trust over time. I only really need to make sure someone doesn't impersonate them, so I just check that it is the same key each time.
  • A friend refers me to a site. I can get the key from them.

So why do we need the CA? How does a website having a CA certificate make me trust it more than if it doesn't?

  • 29
    Because have fun teaching your grandma to exchange public keys with businesses. – immibis Mar 17 '16 at 6:36
  • 1
    How do you know that the box of flash drives out the counter that say "Here's our public key, take one!" is really from the business and that someone didn't just dump some of their own keys in there? Likewise, even if the guy behind the counter gives it to you, how do you know that what he gave you is the real key and that he wasn't paid to hand out fake ones? – Johnny Mar 17 '16 at 16:57
  • 1
    I'm not sure the current duplicate target question "How does SSL/TLS work?" really is a duplicate of this question. This question is quite specifically about CAs (which may or may not have anything to do with SSL/TLS, e.g. S/MIME or code signing). That said, there are already a few other questions that would be quite close to the topic of this question, e.g. here, here (just a few I can remember, I'm sure there's more). – Bruno Mar 17 '16 at 20:03
25

What you are describing sounds a lot like how I share PGP keys with my friends. It works fine when we're all nerds and adding keys manually and are chatting on the phone while we do it, but this approach doesn't scale very well.

CAs solve your second bullet in cases where you need to trust the connection the first time, in an automated way - which turns out to be absolutely essential more often than you might think. This is generally referred to as the bootstrapping problem - or "...but how do we do it the first time?"

Scenario 1: I'm at a friend's house and want to check my gmail. My friend uses hotmail and so her computer has no prior trust with gmail.com. How do I know it's the real gmail.com and not a phishing site made to look like gmail.com? How do I "build trust" enough to give it my user name and password? CAs solve this problem because the CA's cert is pinned in the browser, and the site presents a certificate signed by a CA, now the browser trusts that this is the real gmail.com.

Scenario 2: consider a CA in the context of a corporate VPN. The company hires a new person who will work remotely from a different country. You want to make sure that the very first time they connect to the corporate network, they can authenticate the server and didn't just give credentials to your corporate network to some hackers. CAs solve this problem because you can embed (or "pin") the CA's cert into the VPN client executable, and have the VPN server present a cert signed by this CA.

Scenario 3: Email. Something goes wrong on my server. I call up some contractors that I've been referred to and they say "Send us the log files for your firewall and we'll figure out what went wrong". I've never met these guys, how do I get their public key? I suppose they could read me the SHA2 hash over the phone for confirmation, but that's a HUGE hassle. CAs solve this problem because (assuming my IT dept has set up Outlook in some complex ways) Outlook will verify their certificate back to a trusted root.

Scenario 4: Bank transfers. I ask my bank to wire money to my friend who uses some small, unknown bank - maybe overseas. You can bet the bank won't just send money off to some server it doesn't trust. You can also bet that with the sheer number of banks on the planet, a bank will not mail out USB sticks to every other bank every time they need to stand up a new server (which may be an automated stand-up in response to a traffic spike). CAs solve this problem. In reality, the banking network SWIFT uses a complex hierarchy of CAs to secure the world's inter-bank transactions.

In addition to the technical scenarios above there's also the usability issue: in the current model, TLS is protecting your data and your connections whether or not you know it's there, which is great news for my grandmother. Being able to verify all certificates back to a trusted root CA is something that's easy for your browser to do behind the scenes. So even if a more manual system of importing / trusting keys worked, even I would find it unusably inconvenient, and I'm part of the 1% who does this for a living. My grandmother would...well, be in trouble.

  • 1
    You have a private CA for your website? – immibis Mar 17 '16 at 6:40
  • 1
    You've said what the problem is, but you haven't elaborated how CAs solve it. (I think I know the answer, but for completeness I would recommend making it more explicit.) – PyRulez Mar 17 '16 at 9:28
  • @immibis Good point, that doesn't really make sense. I couldn't find a simple way to make that example work, so I removed it. – Mike Ounsworth Mar 17 '16 at 12:02
  • 1
    ...I'm not sure that solves the real problem. What about #firstWorldProblems and people who don't have gazoodles of personal devices? What about wanting to check from work, or some other closed network? And besides, the shift towards 2-Factor is (at least trying) to make this a moot point. – Mike Ounsworth Mar 17 '16 at 15:18
  • 2
    Keylogging is not the problem certificates solve anyway. – immibis Mar 17 '16 at 18:31
12

It's not about the trust in the certificate itself, but about the process of verification.

First: feasibility. If a certificate is renewed/compromised would you expect the for example a bank to launch worldwide ad campaign "we have just changed our certificate, please update your smartphones, browsers, etc."? It's impossible to achieve on a massive scale.

Or should the company close the business and start gaining trust for the new certificate?

Second: security of the process. Whatever channel you use it might be compromised. You would have to secure communication with the organization or the intermediary. And that again is not feasible on a customer-level scale.

And would you really trust any intermediary? A low-paid bank clerk who gave you a certificate and instructions how to access the website (with a domain name just one character off the real one) that you would later use for years?

  • 3
    I don't think that CAs protect against people accessing the wrong URL. – Neil Smithline Mar 17 '16 at 5:28
  • It does ensure that the details of a certificate are unique and legitimate. If you received connection details with a corresponding certificate, you would have no means to verify its validity. – techraf Mar 17 '16 at 7:06
  • @NeilSmithline If you're referring to typosquatting (e.g. bankofamerrica.com), that's what organization-validated and Extended Validation assurance levels are for. – Damian Yerrick Mar 17 '16 at 14:53
7

The certification says nothing about the trustworthiness of the organisation running the website. It only says that the certificate was issued to the right people.

This is to prevent man in the middle attacks, and attacks that are possible with DNS poisoning or otherwise changing where a request for a particular hostname is routed to.

The out-of-band certification mechanisms that you talk of are less convenient, and ssh-style "stapling" is vulnerable to attacks that can catch you the first time you connect to it. It also makes it very hard to ever change and revoke keys: you need a mechanism to notify everyone what the new key is and that the old one is invalid.

  • That's why SSH servers tells you the certificate fingerprint the first time you connect to a new server and asks whether it's correct. If you skip through that fingerprint matching, an attacker can MITM themself into your SSH connection. – Lie Ryan Apr 27 '16 at 2:06
2

It's trust delegation.

You could manually exchange and verify encryption keys with every host you wanted to. But that's time expensive for both you and (moreso) the other party. They don't want to manually verify who they are out-of-band every time somebody accesses their website.

So your browser and OS trust "root" CAs. In many cases these CAs trust other CAs. Intermediate CAs are usually the ones who deal with the people buying certificates. It's their job to verify that the person requesting the certificate controls the domain.

So by trusting a browser's trusted root certificates, you get a chain of trust down to the organisation you're connecting to. The encryption stuff just proves that they have the private key (something nobody else should) and that means you can verify you're connecting to the right computer and the data is unmolested.

Of course, how do you know a CA is doing its job and actually verifying that somebody owns/controls the domain names it's issuing certificates for? Well this is a problem. There are certain things that upstreams like (open accounting, public certificate logs, etc) and this is occasionally a point of contention.

After some illicit certificates were generated by Symantec, Google threatened to remove their certificate from Chrome. That would render any certificates solely signed by theirs as invalid. DigiNotar famously issued illicit certificates and was mass-removed, leading to a quick collapse.

It's in the interest of every level of CA to thoroughly verify what they're signing.

Is it bullet-proof? Of course not. Governments can do a lot in the name of national security and I have no problem believing that includes forcing CAs to issue fake certificates (if they don't have a CA of their own that can do the same job)... So if you're an international terrorist, perhaps make your own trust chain, but for everybody else, root certificates make things much easier.

1

It's mainly about being able to verify an entity's identity without any prior interaction.

One of the main purposes of a CA is to assert certain pieces of information about one entity, in such a way that another entity that trusts this CA can trust this information, even though the two entities do not need to have been in contact ever before.

It is effectively trusted party that lets you check the identity (generally, but also possibly other attributes) about an entity you need to interact with, but may never have met.

You can compare this to a passport issuing authority (i.e. generally speaking, a country). Even if you have never met a person, if someone comes to you with a passport (from a country you deem responsible enough in its passport administration), you can trust the binding between picture, name (and other properties), and attach a name to the person in front of you with reasonable certainty.

The applies to Public Key Certificates: the issuing CA allows you to trust the binding between the public key and the identity. For an SSL/TLS server, the identity is its host name (see RFC 6125), and the public key is the one used during the SSL/TLS handshake.

So a Certificate Authority certifies that a website corresponds to a given organization. Why is this necessary?

Linking a website to an organisation isn't strictly necessary. It's mostly the aim of Extended Validation certificates. It just makes some people feel more confident about the website they are visiting. It is generally useful against attackers who control host names with names similar to legitimate websites you would visit.

I interact with them physically in real life, or through mail, or what have you. I can just get their public key when I meet with them.

Certainly, but there's a few problems with that:

  • Bootstrapping: if you've never met that person, the fact that they're giving you their public key the first time you meet them doesn't make them who they say they are. This is very much a problem on the web, since there's always a first time you go to a website, without having visited it before on this machine. Even with notary systems like the Perspectives Project, you need a first visitor.

  • You can't always interact with websites in a physical manner.

  • Even if you somehow manage to interact with the website in a physical manner, most people will have no idea what you are talking about when you ask for their public key. Try asking your bank's public key next time you walk into a branch...

  • Managing a handful a public keys of people you've met is possible, but there's generally a large amount of websites you can visit. There's a point where you wouldn't want to manage a list, especially when using multiple machines, for example.

  • On top of this, you generally remember someone's face when you see them later. In contrast, a website can change its public key (typically every year, but sometimes much more often). You'd still have a to find a way for them to tell you about this change in a manner you can trust.

I interact with them solely digitally. I start with no reason to trust them, but gain trust over time. I only really need to make sure someone doesn't impersonate them, so I just check that it is the same key each time.

Trusting a website is unfortunately much more binary than progressively building trust with someone. There's an expectation of wanting every interaction, even the first one, not to have been intercepted and altered by a MITM attack.

A friend refers me to a site. I can get the key from them.

The CA system is very hierarchical. To some extent, it's a particular case of the Web-of-Trust system, where you can delegate trust to people you know, who in turn will delegate trust in people they know, and so on.

WoT is a valid system, but it comes with its own problems:

  • Trusting someone's identity is real doesn't imply that this person is generally trustworthy: it's not because you know someone's real name that they're not going to lie about someone else's identity.
  • As you said, you'd solve that problem by getting the key from someone you know to be a friend, but how would you know this friend has made the relevant identity checks rigorously?

Essentially, the set of people whose identity I know is a superset of the people I generally trust to have good intentions, which is itself a superset of the people I believe to be sufficiently competent to check other people's identity too. Modelling trust and trust delegation can get complex very quickly when you take these parameters into account.

The purpose of the CA is to be an entity that you can trust have vetted what they put in their certificates properly. Of course, they fail at their job once in a while, but it's a reasonable compromise in order to make it sufficiently simple to be widely usable. More complex models would require much more complex user interfaces and explanation to the users. I think many of users would find the complexity overwhelming, and end up discarding any warnings (which would be worse in the end).

Of course, there are ways to mitigate some of the problems with CAs (e.g. intermediate notary systems), but there ultimately needs to be a judgement call by the user. The CA system is far from perfect.

How does a website having a CA certificate make me trust it more than if it doesn't?

The website itself doesn't have a CA certificate as such, it has a certificate issued by a CA. It's not about trusting the website itself, but it's about trusting that the website's identity is who it says it is (and that it's the hostname you are looking for).


Of course this only moves the bootstrapping one step further: why would you trust the CA certificates bundled with your browser or OS?

0

We're actually don't need CAs nowdays : they're an anachronysm. Take a look at Perspectives Project. CA's job consists of three main things :

  • Signing the keys
  • Revoking the keys and maintaining CRL of them
  • Verifying the keys as an authority that ensures that the key is signed by it and not included to CRL, i.e. it's "OK" and "Valid"

First two tasks are kept in CA's duties nowdays, but the third one is not - even with a forged/cloned/side-issued CA root certificate the maximum impact is that the certificate/key can be marked as revoked, but it's integrity is intact and a malicious key with the same info fields can not be injected, because a network-wide quorum will flag the forgery.

Of course, the CA's are not doomed, but some part of their functionality is obsolete now and it's too insecure to trust them in full scale as we safely did it ten years ago.

  • 4
    While this seems like a useful addition to the current model, it's completely useless for corporate security. It also strips away the ability to revoke known-compromised certificates, and I question how well it would work when a cert expires and needs to be updated. And, it doesn't handle the "first connection" issue - if your first connection to a server is over a compromised network, that network can MitM all the Perspectives responses. In other words, it's not a replacement. – Bobson Mar 17 '16 at 11:40
  • @Bobson it does not. CA is not needed as the only authority, but the CRL's and so forth are not eliminated, of course. CA's must be used in addition with distributed key verification – Alexey Vesnin Mar 17 '16 at 12:49
  • 2
    @AlexeyVesnin - If you say that "CA's must be used in addition", then that's the complete opposite of this answer, which is that CAs are unnecessary. – Bobson Mar 17 '16 at 15:17
  • 1
    @Bobson thanks for a constructive comments and discussion - I've updated my answer to make it more clear. – Alexey Vesnin Mar 17 '16 at 16:15
  • 1
    @AlexeyVesnin: good thing your client moved. With SNI being as widely supported as it is now, there's really no excuse for not supporting it, especially as there are many cheap, professionally managed shared hosting providers. Who knows what other obsolete, buggy, vulnerable software that such obsolete host is running. – Lie Ryan Apr 27 '16 at 16:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.