19

I looked at other Stack Exchange posts explaining why self-signed certificates are not as secure as CA-issued certificates, and most of these pages say the same thing:

If it's self-signed, and the 1st client-server handshake is intercepted, the man-in-the-middle could receive the encrypted data from the server, decrypt it, do bad things with it (change it or send it to the hacker who now has your password), and encrypt it again with the fake certificate.

But this system is based on the fact that the CA makes sure that you actually own the domain. The way CAs check that is by sending you an email with a verification code. Everyone on this website knows that email is very insecure. It seems very strange that SSL certificates, which are all about security rely on such an insecure system. Why don't they use stronger verification methods, such as adding a piece of code to the homepage or create a DNS record?

elipoultorak
  • 291
  • 1
  • 5
  • 2
    I'm not aware of any browser that trusts self-signed certificates by default. [Related question and answer](http://security.stackexchange.com/questions/87564/how-does-ssl-tls-pki-work) – RoraΖ Aug 19 '15 at 12:36
  • 3
    That wasn't my question. My question is why are CAs more secure than self-signed. – elipoultorak Aug 19 '15 at 12:38
  • 1
    @M'vy - I disagree with the dup suggestion. This question is implying (though awkwardly worded) that perhaps the minimum standards for a CA signed cert are so low that it isn't much better than a self-signed cert. – TTT Aug 19 '15 at 14:34
  • I removed it. What I meant was if the browser trusts this certificate, we could have this potential man-in-middle scenario attack. – elipoultorak Aug 19 '15 at 17:45
  • Because until this year, DNS tampering could be done with absolute certainty by someone who is MITMing the connection. – Joshua Aug 19 '15 at 23:20
  • @Joshua - *"Because until this year, DNS tampering could be done ..."* What is different about "before this year" and "from this year onwards". – Kevin Fegan Aug 20 '15 at 03:48
  • SSL Certificates were created with the primary purpose of authenticating the correct server. With today's DNSSEC, TLS is starting to look a bit long in the tooth as DNSSEC fixes the key distribution problem of IPSEC. Incidentally, IPSEC is not considered optional in IPv6. There is no reason in principal now we cannot switch over ti DNSSEC/IPSEC and be rid of having the primary problem of untrustworthy issuers. There's no good reason why we allow China to issue certificates that affect US holders or vice versa. CA Certs are only the least bit more secure because too many cert issues WOULD NOT D – Joshua Aug 19 '15 at 23:24
  • "_Why don't they use stronger verification methods, such as adding a piece of code to the homepage or create a DNS record?_" Because they do! I passed verification for my very first publicly-trusted certificate by adding TXT record to DNS. For Comodo certificates I use HTTP validation. – Adm Selec Aug 20 '15 at 07:23
  • @AdmSelec It's very good that Comodo does that. Everybody else should do the same, but they don't. – elipoultorak Aug 20 '15 at 07:32
  • @Kevin Fegan: DNSSEC rollout reached the reliable point early this year. – Joshua Aug 20 '15 at 17:16

3 Answers3

20

CA signed certs are not actually more secure than self-signed certs, in the sense that the level of encryption is the same. But there is a big difference in the level of trust between the two. Visitors to a site using a self-signed cert have to trust that the cert was generated by the site owner, simply because the site says it is. There is no easy way to discern if there is currently a man-in-the-middle attack happening. With a CA signed cert, now the user can trust that both the site and a 3rd party are in agreement that the cert was generated by the site owner, so a man-in-the-middle attack would be much more difficult to pull off.

Note: the original question has since been edited; the following statement applies to the previous wording but I'm leaving it here because it is still informative:

In your question you claim that some CAs will issue a signed cert without making sure you own the domain. If that were true, then perhaps there would be some validity to your assumption that certain CA certs are not more trustworthy than self-signed. Fortunately though, it is not true that any widely trusted CAs will issue a signed cert without verifying you own the domain. In your comment you mention that the verification may be as simple as receiving an email, and you question the security of that.

I think it is good to question how secure receiving an email is, but you must admit that receiving an email is entirely different than no verification at all. You do have a point in implying that the trustworthiness of those cheaper certs may not be as high as other validation levels, (which might include installing a code on the web server), and that's why there are different levels of validation. Arguably though, since most visitors do not inspect the certs, perhaps the more expensive certs are really not much better than the cheapest ones, with the exception of the most expensive "green bar" EV certs.

So, in a sense, I agree with your implication that perhaps the minimum standard for obtaining a CA signed cert should be raised to beyond simply receiving an email, but as it stands today, this is what we have, and it's still much better than nothing.

TTT
  • 9,132
  • 4
  • 19
  • 32
7

Any CA which allowed you to buy certs for any domain would likely get their trusted status in common browsers revoked pretty quickly. There have been flaws and bugs which have allowed for this in the past, but they generally get closed when discovered (N.B. this doesn't include nation state level players, who doubtless can abuse the CA model in this way).

The main benefits for browser users of a CA system is that they don't have to try to determine whether to trust each certificate individually. Trusted root certificates are distributed with the browsers and this allows users to easily determine whether to trust a given certificate.

Without this users would have to look at each cert. as they got it to try and determine whether it was legitimate or not, and this isn't really a tenable model.

That's not to say that the CA model doesn't have a wide range of flaws, but that for most users it's a better solution than self-signed certificates.

Rory McCune
  • 61,541
  • 14
  • 140
  • 221
4

Certificates are not about Security at all! Certificates are about Authenticity!

The Key inside the Certificate is for the security! The certificate is a way to add some metadata to this key.

You can have the same public key in a self signed or in a CA certificate. The security of the encryption will be exactly the same. It's just that with a self signed certificate you are anyone, and with a CA certificate you are at least "the owner of xyz.domain, according to CA".

Think about a person standing at your front door. This person tells you some information. The certificate would be any ID this person shows you, because a ID is metadata about this person.

Of course, any person can just go to your door and show you some paper, hand drawn with crayon, that says they are a police officer. But would you leave your house if this person tells you so? It could be, that they are really a police officer and have to evacuate you, but with only the hand drawn crayon ID you might wonder if that's legit.

If this person stands in front of your house with a proper police ID, maybe with some hologram or whatever they use to make is harder to fake, a police car is parked behind him and inside sits another person in police uniform, you most likely believe this person is more authentically a policeman!

Of course, you still can fake a police ID, get a police uniform and paint a car to look like a police car, but it is way more work than painting an ID with crayon. Saying "It's possible to fake a police ID, so we should just accept crayon IDs, this way the police can create the IDs cheaper" is not the solution.

A self signed certificate is like a guy showing you an ID painted with crayon. Everyone can do that in seconds and it really has no value. That's why browsers don't accept them.

Now to your email question: What makes you believe email is in any way less insecure than DNS or http? If you want to receive the email from the CA, you have to either MITM the connection between CA and email server of you have to change the DNS/MITM the DNS query between CA and DNS server. If you can change/MITM the DNS server, you can also create any DNS record or change the A record and thus add code to the http site! So email is only less secure if you can MITM the connection between the CA and the email server but not the connection between DNS or web server and CA. That's very unlikely IMO.

It is trivial to MITM a public wifi network. So if browsers would accept self signed certificates, one could automatically log and change any websites anyone in this network accesses. There are many tools which do just that. Redirect any traffic to this tool, it will automatically create a new certificate for any domain asked, forward the traffic to the real server and log it. Not much work at all. If you want to do that with CA certificates, you would need to verify each requested domains on the fly with the CA and basically hack the CA or their upstream provider.

Eavesdropping or (wo)man-in-the-middle is very easy in a public wifi in a cafe or a related setting. Eavesdropping fibre cables between data centres of CAs and webhosters is a totally different magnitude.

Josef
  • 5,933
  • 26
  • 34
  • With your police badge analogy, I'd add an additional point - if you didn't trust that the person with the police like badge, and the police uniform, and the police car was, in fact, a police officer, the badge would have an identifier on it that you can use if you, say, call up the police headquarters and ask them if the police badge you have been presented with is legitimate. Though much easier to do the CA version than actually calling the police headquarters about a specific badge. – Alexander The 1st Jan 06 '22 at 02:17