0

This article got me thinking: would the following alternative (using self-signed certs and a third party service) be less secure than the current CA hierarchy trusted by browsers? I quote:

The really depressing part is that it would be trivial to set up a simple service where users could upload their domain certificates to a site (after proving ownership of the domain by placing a file in the domain web root), and browsers could automatically check for the files there as a safeguard against this attack vector. The files are typically ~1KiB in size per domain.

This basically would prove that the certificate received from the website W was really made by the owner of W's (sub)domain, and that the visitor is not being victim to a MITM attack. Of course, this looks like a CA's job, but as CAs either can't restrain themselves from demanding absurd amounts of money (yearly or monthly) for such a simple service, or can (e.g. CACert) but won't be accepted by browser vendors in their lists of trusted CAs, an alternative should be found...

This trusted service could be handled by a not for profit foundation backed by the main browser vendors, and would really democratise the access to strong encryption and web browsing safety.

Is there a security flaw in this simple scheme? or are the browser vendors too interested in the CA cash machines?...

a25bedc5-3d09-41b8-82fb-ea6c353d75ae
  • 228
  • 1
  • 6

3 Answers3

2

Here is what I think.

Imagine a rogue attacker uploading certificate for google.com to this central website. Now, on poisoning DNS records, it can redirect clients to a rogue server and capture all encrypted transactions. This attack would fail with the current scheme because the certificate presented by the rogue server (as google.com) would not match that in the trusted store.

sandyp
  • 1,146
  • 1
  • 9
  • 17
1

... for such a simple service, or can (e.g. CACert) but won't be accepted by browser vendors in their lists of trusted CAs

There is a reason that CAcert was never accepted: because they never completed the required audit. While you might think that running a CA service is just putting together some openssl scripts ("... such a simple service") in practice it is way more complex. CA's are a highly attractive target to compromise which means that you have to secure your operations so that no hacker can get access to the CA's private keys or is able to create arbitrary certificates. You also have to run a reliable infrastructure for OCSP queries, nobody should be able to trick you into issuing a certificate he should not own ...

And the same security and reliability problems will be faced by your proposal. And it will be a very attractive targets for attacks too. This means somebody has to take care of this which costs money and somebody needs to pay for it. And of course browser vendors would only add this mechanism to the browsers if regular audits are done which also cost money. This situation thus is not better than with the current CA system.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • So security wise, it would be similar to the current trusted CA system right? As this service would be much more simpler than CAs intricate systems, I think it would cost only a tiny fraction of what the CA have to spend for their security. – a25bedc5-3d09-41b8-82fb-ea6c353d75ae Sep 11 '16 at 09:13
  • 1
    @a25bedc5-3d09-41b8-82fb-ea6c353d75ae: If you add the security measures needed to protect the service against hacking and misuse and to provide the needed reliability it would be no less complex and not cheaper to maintain than the current CA system. It would probably be even more expensive because to verify a certificate currently you don't need to be the CA always online but for your proposal that service has to be always online and reachable from all over the world. This makes it an attractive target for DOS attacks. – Steffen Ullrich Sep 11 '16 at 09:25
  • It's true this system would be weak against DOS attack, power outage, ... But as for security, this would be a web service with only two entries (for users: one request to register a cert ; for browsers : one request to check a cert), plus an SSH access for the admin, no email, no complicated payment system, ... the code for the web service would be small enough to even get formally proven. – a25bedc5-3d09-41b8-82fb-ea6c353d75ae Sep 12 '16 at 00:39
  • 1
    @a25bedc5-3d09-41b8-82fb-ea6c353d75ae: "...would be small enough to even get formally proven..." - I very much doubt that. And then only if you blindly assume that the platform where the service is running on is secure. Because this platform is complex enough that formal verification is not possible. And we have so many attacks against such platforms, OS, ... that you cannot just assume that it is secure. Again, in theory a CA is also just a bunch of simple openssl commands, in practice it is way more complex too keep all this secure. – Steffen Ullrich Sep 12 '16 at 03:36
0

That's an impressive single point of failure you've created there. If this one website goes down, whether for technical or commercial reasons, a large part of the Internet stops working because no one can load any SSL web page. If it was because the foundation has gone out of business, then the outage lasts for months, until all the browser vendors can distribute new versions to all their users. That's just one reason why it's a bad idea.

Mike Scott
  • 10,118
  • 1
  • 27
  • 35
  • True, but this wouldn't prevent the traditional trusted CA from functioning, and I guess bigger enterprises will still want to pay big money if it's more secure for them. Also, it would cost less to keep such a simple foundation up and running than paying the current CA fares. Anyway, I know that I would take the risk for my private server, and even donate a few euros a year if they are in trouble... but the question remains, would it be secure enough? Are their security flaws in this scheme? – a25bedc5-3d09-41b8-82fb-ea6c353d75ae Sep 11 '16 at 09:08
  • 1
    @a25bedc5-3d09-41b8-82fb-ea6c353d75ae Current CA fees are zero, with letsencrypt.org. It doesn't get cheaper than that. And potential loss of availability _is_ a security issue, as it lays you open to a denial of service attack. – Mike Scott Sep 11 '16 at 09:55
  • ... but without wildcard cert and you have to install a software as root on all your servers (upon further research, there are non root alternatives like acme-tiny). It sure looks like the better alternative! Last year I took the trouble to create a cert with StartSSL but now that it's expiring I'll use the simpler option of Let's Encrypt. – a25bedc5-3d09-41b8-82fb-ea6c353d75ae Sep 12 '16 at 01:09
  • `That's an impressive single point of failure you've created there` One of the same size as ajax.googleapis.com; without it, this site doesn't work. – jornane May 10 '19 at 15:06
  • @jornane No, the ajax.googleapis.com one is much smaller, because it can be fixed by hosting the Javascript files somewhere else and then pushing a code update. It would take hours, not months. – Mike Scott May 10 '19 at 15:15
  • The proposed service is then not problematic either, because sites can simply get a certificate from a CA or disable HTTPS. – jornane May 10 '19 at 15:17