Convergence - Possible Replacement Certification Authority System

Good all the time of day!



Immediately I would like to give two links to the materials on the basis of which this note was compiled. You can familiarize yourself with the sources and not read the topic, which is only my free translation, a retelling of the main points with a small amount of ad-libbing.

BlackHat USA 2011: SSL And The Future Of Authenticity

Moxie Marlinspike :: Blog - SSL And The Future Of Authenticity

')

Introductory

A couple of days ago, there was an article in Habré devoted to obtaining an SSL / TLS certificate. But my attention was attracted not so much by the article itself, as by the comments on it, the very discussion of this subject area, or rather, by and large, its absence. I did not begin to expand the discussion on the spot and decided that it would make sense to create a separate topic in which I could highlight the problem along with the options for solving it, and also discuss the whole matter in the comments.



Let me quote a couple of comments from the above article:

Certificates are a great example of air trading. And for quite real money you get a set of bytes, which does not guarantee anything and does not protect from anything. ... (c) angry_elf

and the answer to it:

Offer your MiM protection option! Then you will trade in air or become so rich and popular that you don’t need to do anything at all. (c) okazymyrov.

There are also a number of comments from which it is clear that people still care about the following topics, problems and questions:

• Trade in certificates - air trade? What do we pay money for?
• Do certifying centers (CAs) cope with the responsibilities assigned to them and can we assume that they provide real protection, or can this be questioned?
• What do Alice and Bob do to protect themselves from the cunning Man-In the Middle?

These are only questions that are really on the surface, deeper - more. Let's review and discuss.

A bit of theory

Secure data transmission between nodes on the Internet occurs via the HTTPS protocol (HTTP extension), in which the transmitted data is encapsulated in the SSL / TLS cryptographic protocol (TLS is an SSL 3.0 standard), which in turn is based on the use of an asymmetric algorithm public key encryption - RSA. And the common problem of all asymmetric cryptography is the difficulty of verifying the authenticity of public keys. Therefore, in all cryptographic protocols based on algorithms with a public key, the question of trust is of fundamental importance. Namely, how to be sure that the public key received from the server is really the key that the server with which you want to establish a secure communication channel is used, and not the key located in your Man-In-The-Middle network segment, which wraps all your HTTPS traffic to your sslsniff . There is a problem of trust.

Verification Centers

Historically, the problem of trust began to be solved using an authentication technology like PKI (Public Key Infrastructure). This is a comprehensive system of measures that associates the public keys with the identity of the user through the CA. PKI is based on the use of a public key cryptographic system and a few basic principles:

1. The private key is known only to its owner.
2. CA creates a public key certificate, thus certifying this key.
3. Nobody trusts each other, but everyone trusts TC.
4. The CA confirms or denies that the public key belongs to the given person who owns the corresponding private key.

In fact, PKI is a system, the main component of which is a CA and users interacting with each other through a CA.

It works like this: Bob wants to allow Alice and his other girlfriends to establish secure connections with him. He comes to the TC with his public key, as well as other data (name, address, etc. - all that will be in the certificate), one way or another verifies his identity (many do it just by e-mail) and register his key. CA issues him a certificate. Then Bob passes it to his girlfriends, who can be convinced that he really belongs to Bob, checking the digital signature of the CA, which they fully trust.

Problem

What is the problem? The problem is that for you decide who to trust you. At the very moment when the owner of the resource decides that he will receive a certificate, say, from Comodo - he decides for whom you will have to trust. Someone might say that his resource is for him to decide from whom he will receive a certificate. Yes, but the data is (for example, credit card data) this resource processes yours! And that, her mother, is a problem! It would have been nothing if no one questioned the reliability of the existing system of certification centers and they would perfectly carry out their work, but this is not so. CAs are private companies, they employ living unknown people who can pursue their vested interests, can be bribed, intimidated, blackmailed. CA can be compromised by third-party attackers (aka hakirs). We can recall a rather noisy story with Comodo CA, which happened this spring ( link ), during which it was liquidly compromised by intruders and just the other day happened to happen with DigiNotar CA ( link1 , link2 ). With DigiNotar, we somehow somehow solved the problem - to hell, cut them out of the list of root certificates in browsers and deal with the end ( we’re releasing the version of the firefox) trust in the DigiNotar root ). But Comodo is not DigiNotar, the bigger fish. What happened to Comodo? Everyone grumbled, grumbled and forgotten. As Comodo was in the list of root browser network settings, it remained the same as selling certificates and selling. You can sleep peacefully, continue to trust those who you have registered in the Certificate Authority sheet of your browser. And these are only those cases that were covered in the press, and how many were those that were not told to everyone, those that were not even known themselves, how many at the moment are formally valid in fact but left-handed certificates? And even if we exclude the factor of unknown attackers who compromise the work of certifying certification centers from outside, what about what is happening behind the scenes of these centers themselves? What about representatives specials. services? Brad paranoid? Take a look at this article and the materials on the links in it - Devices of the security forces undermine SSL . In general, small problems like it or not, but there are, only the blind can not see them.

Decision

As you know, there are two models of the organization of the infrastructure of certificates: centralized (PKI) and decentralized (implemented on the basis of the so-called trust networks - web of trust), which is currently most prevalent in PGP / GPG networks. About all the charms of the centralized model mentioned above. Let us dwell on a distributed system, in which there is no single source of certification, on the contrary, each user independently decides whom he trusts and who does not trust in verifying other public keys, thereby creating a personal network of trust. This approach provides the flexibility and resilience of the system to any malicious effect: you can affect one node of the distributed system (in this case, exclude it from the network of trust), but the rest will remain reliable.



You can revise the centralized model, on the basis of which the trust relationship initiates the resource itself, requesting a certificate in a particular CA, thereby obliging all its clients to interact with this CA to verify their authenticity and apply a decentralized approach, during which the trust relationship between the client and server initiates the client itself and the interaction is as follows:

1. The client wants to establish a secure communication channel with a certain site. He accesses this site and receives an SSL certificate from it. The question is - is it really a certificate of this site or a certificate that slipped Man-In-the-Middle? Need to check.
2. The client refers to the list of certifying servers formed by him and asks each of them - “what certificate do you see on this site?”.
3. In response to a request from the server, they access the specified site and also receive a certificate from it, and then send them to the requesting client, verifying with their signature.
4. The client compares the certificate it received directly from the server with the certificates received from the certifying servers.
5. If the certificates are the same, everything is fine, we are working. They do not coincide - somewhere near Man-In-the-Middle and it is possible to be in trouble.

Implementation

At the conventionally held at the beginning of last month in Las Vegas, the BlackHat conference, notorious in the research circles of security specialists, Moxie Marlinspike presented a project called Convergence (An agile distributed to the Certificate Authority system) in which he implemented . Within the framework of the project, the certifying servers were called Notary.



We roam and install the FireFox plugin - onvergence :





Form the notary-list. To do this, you can use the list of existing servers - Notary list , you can raise your Notary-servers - Running-a-Notary , you can do the first and second.







Of the features of the system settings - you can adjust the paranoid threshold by changing the Verification Treshold option.





Previously, when using the traditional Certification Authority System was:





Activate the plugin, go to Convergence:





Pleasant trifles:

• Site administrators do not need to do anything on the server side. There is no need to arrange the migration of the Internet to a new authentication system. Everything is already working, it remains only to implement plug-ins for all major browsers.
• There are no more warnings about self-signed certificates, since the client doesn’t care who signed it, it’s important for the client to be sure that he uses the certificate provided by the server and not by Man-In-the-Middle.

Conclusion

Who do I have to trust?

... and for how long?

Prescribed set of people forver,

Or time to try Convergence?