"Web of trust" for self-signed SSL certificates?

Question

SSL certificates, generally speaking, use a "chain of trust" model - a trusted certificate authority (CA) gets proof that a company such as Amazon owns amazon.com and issues an SSL certificate.

However, certs can be expensive - and it doesn't make sense to spend that kind of money for example on a personal website. But more and more people have been arguing that web traffic should always be encrypted because computers can handle it and it protects you over public wifi networks e.g. starbucks. So you can use SSL with a "self signed" certificate but users will get a nasty message saying that the certificate is not trusted since it is "self signed" and not by a "trusted" authority. The problem is that there have been numerous cases of the "trusted" authorities making mistakes and giving SSL certs to "bad guys" so to speak. But in reality, a self-signed cert is not significantly less secure than a cert signed by a CA - in the sense that your traffic is encrypted and sent to the web server and decrypted there. It just means that no one "trusted" checked the identity of the webserver in question.

Is there a way to do a "web of trust" model with SSL certificates similar to PGP keys? I.e. if I know someone personally and know that they are the administrator of website www.example.com, and they have a self-signed certificate, I can "sign" the certificate to say that I trust them. Then when users go to a self-signed website it will say that the person can be trusted based on their place in the 'web of trust'.

Answer 1

... But in reality, a self-signed cert is not significantly less secure than a cert signed by a CA - in the sense that your traffic is encrypted and sent to the web server and decrypted there. It just means that no one "trusted" checked the identity of the webserver in question.

This just is a very important part. If you don't verify, that the peer you talk to is the expected peer, than it could just be somebody else. E.g. if Alice wants to talk to Bob and does not check, that it is actually talking to Bob, than it might talk to Mallory claiming to be Bob. Mallory might then relay the messages to Bob and the connection would still look encrypted, but it would be encrypted from Alice to Mallory and again from Mallory to Bob. Mallory would have access to the plain text of the message and could also modify it.

In theory you could do your own web of trust with self-signed certificates. But, I don't think many of the current users of https would understand the concept and its implications, e.g. how to apply trust to another party, how not to trust just some stranger, how trust weakens the longer the trust chain is and how much trust they need when accessing a site (which might be different from site to site).

Which means, that at the end you might get a trust network which is too complex for most people to understand and thus they don't trust it. Or you might get a trust network with some well known and thus trusted players in it which offer to verify you and then add you to the network for some money - which is more or less what you have today.

While nobody really likes a central authority, having such thing greatly simplifies to apply trust in real life. I.e. most people don't put they money into a small bank unless they are known to be backed by a larger bank or insurance etc.

DANE might be a better way to go. It still requires a central trust network, but it does not create a new one just for SSL, but instead reuses the existing one created for DNSSec. This might be both cheaper and easier to understand - and thus more trusted.

Answer 2

"Web of Trust" in X.509 formats have been occasionally tried. For instance, Thawte tried it but gave up.

For a Web of Trust to "work", you need two things:

• "Relying parties" (in the HTTPS case, this means Web browsers) must implement the verification protocol which checks the WoT relations.
• Sufficiently many participants must join the system. A WoT provides verifications which are worth that name only through accumulation of paths. It is not sufficient for the WoT graph to be simply connected; the WoT strength relies on the ability of any verifier to find many paths between itself and the certificate that is to be verified.

Thawte solved the first point by putting themselves as intermediary (so, from the point of view of browsers, it was just a plain certificate chain), but could not overcome the second point.

This is a critical issue, and it also applies to PGP: the system is very hard to bootstrap. During the deployment phase, the WoT does not provide any kind of decent guarantee, so there is little incentive for people to actually join it. Either clients are configured to a "trust by default" setting where they trust a certificate based on a single path; in which case some successful attacks can be expected, and will severely damage the system reputation, discouraging people from using it. Or clients have a stricter configuration, and the WoT won't be usable until a large subset of server owners participate to it; and they have no reason to do so, especially if that means that their self-signed certificates, in the meantime, trigger scary warnings.

---

Note that while HTTPS-with-a-self-signed-certificate provides strong protection against passive attackers (the data really gets encrypted), it is weak against active attackers (who try to run fake servers, e.g. for a Man-in-the-Middle attack). It so happens that most attackers who can go passive can also go active: for a cheap, lone attacker, the realistic attack scenarios for eavesdropping imply setting a rogue open WiFi access point (e.g. in a restaurant) or some DNS poisoning. Both contexts inherently allow for active attacks as well, with no extra work for the attacker.

Therefore, HTTPS with self-signed certificates is not, in fact, that much better than plain HTTP. It used to be much better, in older times, when the attacker/target context was that of a workstation room in some university, with students trying to spy on each other: at these times (in the 1990s), the "attackers" were mostly passive, and encryption defeated them (that context explains authentication protocols like "HTTP digest", which make sense, from a security point of view, only against passive attackers).

Answer 3

This reminds me of the web-rings which used to be popular. If you can create a reputation-based system, you can start your own CA.

The thing is, even the CA's today don't check much. You can have a malicious website with a CA signed certificate. So, it doesn't seem implausible. You could create a CA system based on website reputation. For instance, having a two-tiered certificate authorization system based on website trust/reputation would be a good way. You can require a prompt or an option to report the site during phase 1, which would be an initiation period. After the website develops a high enough reputation and checks out according to a trusted majority of authoritative organizations/people, you can sign their certificate with the second tier, indicating that the website has been shown to be trustworthy. If you still require the report icon/window on the page, in a visible manner, you can actually create a more secure, decentralized, reputation/trust-based CA. It's a good idea. I would participate.