Slashdot Mirror

From https://en.wikipedia.org/wiki/Convergence_%28SSL%29:

With Convergence, however, there is a level of redundancy, and no single point of failure. Several notaries can vouch for a single site. A user can choose to trust several notaries, most of which will vouch for the same sites. If the notaries disagree on whether a site's identity is correct, the user can choose to go with the majority vote, or err on the side of caution and demand that all notaries agree, or be content with a single notary (the voting method is controlled with a setting in the browser addon). If a user chooses to distrust a certain notary, a non-malicious site can still be trusted as long as the remaining trusted notaries trust it; thus there is no longer a single point of failure.

The Monkeysphere Project tries to solve the same problem by using the PGP web of trust model to assess the authenticity of https certificates.[8]

Now, everyone, let's use the tools available!

DNSSEC makes exactly the same amount of sense as the current SSL CA system. "Too big to fail" entities controlling identity, authenticity and trust is never going to work. I suggest you read this article and take a look at the Monkeysphere project:

http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/
http://web.monkeysphere.info/

Monkeysphere

There is a project called Monkeysphere which have been working on doing this and much more with PGP for a while. They support SSL certificates in the browser (with some difficulty) and SSH host keys authentication, and generally aim to bridge the PGP web of trust with other tools to decentralize the work of certification authorities.

How does Convergence compare with Monkeysphere? Why didn't you collaborate with the Monkeysphere project instead of starting your own?

I just came accross http://web.monkeysphere.info/why/, which looks to me like an interesting idea: delegate the trust issue to the PGP web of trust. Maybe this would be a sane alternative?

Check out Monkeysphere, it does just that. It even has a Firefox plugin.

"The Monkeysphere project's goal is to extend OpenPGP's web of trust to new areas of the Internet to help us securely identify servers we connect to, as well as each other while we work online. The suite of Monkeysphere utilities provides a framework to transparently leverage the web of trust for authentication of TLS/SSL communications through the normal use of tools you are familiar with, such as your web browser0 or secure shell." See: http://web.monkeysphere.info/

Much like the SSL cert ecosystem today provides a means of merchant identification, without there either being a single point of failure or sinister government control.

Actually, as it's currently implemented, the SSL cert ecosystem today provides many points of failure and sinister government control that compromise the whole system. Count the number of "trusted" root CAs in your web browser -- any one of them can be evil, compromised by crackers, or agree to government intrusion in order to compromise any your web-based communications. Here's a more in-depth analysis of the problem. Even worse, these "trusted" roots can create subordinate CAs, which can in turn compromise all of your X.509-secured communications. You might also be interested in the EFF's SSL Observatory, along with their analysis of the abysmal state of today's X.509 certificate infrastructure.

To solve this properly, we'll probably need to do at least the following:

• enable multiple paths of certification for any certificate -- X.509 only allows one issuer per certificate (OpenPGP allows an arbitrary number).
• provide tools to let users indicate scoped reliance on certifying authorities. For example, you might be fine with using the US Government's certifying authority to identify https://www.irs.gov/ (note: the IRS currently uses akamai's CDN, so TLS is entirely broken for it). But you might not want to accept their certifications for https://slashdot.org/ (note: slashdot doesn't currently use TLS properly site-wide either, even though it should) or any other site that is frequently critical of the US government.

I agree that we need work on distributed trust infrastructure. That's why i contribute to the monkeysphere project -- we're pushing OpenPGP-style multi-party, user-centric certification into SSH, the web, and everywhere else we can.

I'm just not convinced that the US Government is likely do this the right way. It seems probable that they'll be happy with centrally-controlled, single-trust-path certification. Or that they'll botch it in the same way that X.509 is currently botched.

The scheme you're proposing is open to a replay attack by a man-in-the-middle. The MITM simply requests the randomly-generated string from the server, forwards it verbatim to the client, and passes along the client's response as well.

To do this right, you'd need to have the thing being signed/decrypted/passed around (the nonce) embed some unimpeachable detail about the established channel that should be visible to both sides of the transaction without being controllable by either (e.g. start by negotiating an anonymous DH key exchange, then embed the negotiated DH key in the nonce). Then both parties need to:

• generate and sign their own nonce,
• verify the other party's signature over the received nonce
• verify that the key the other party is using does in fact belong to the expected party
• inspect the received nonce to ensure that it is bound to the established channel

This sort of asymmetric-key authentication scheme is already implemented bi-directionally in two different widely-deployed stream-based connections: SSH and TLS. Please don't try to propose a third protocol, it's hard enough to get right in these two already :)

The asymmetric keys in question can be wrapped in whatever sort of packaging you like -- raw pubkey material (commonly used for SSH), X.509 certificates (commonly used for TLS), OpenPGP certificates, or some mixture of the above. See the monkeysphere project if you want to use OpenPGP certification with SSH and TLS connections.

Enter the Monkeysphere, a project that leverages the GPG web of trust to build trust paths for secure browsing (among other uses). From the site:

When you direct the browser to an https site using the Monkeysphere plugin and validation agent, if the certificate presented by the site does not pass the default browser validation (using standard, hierarchical X.509), the certificate and site URL are passed to the validation agent. The agent then checks the public keyservers for keys with UIDs matching the site url (e.g. https://zimmermann.mayfirst.org./ If there is a trust path to that key, according to your own OpenPGP trust designations, the certificate is considered valid, and a browser 'security exception' is put in place to allow connections to the site.