Alberto Serra wrote: > Привет!
I've always wondered what this is exactly. I'm going to assume it's a friendly greeting. :) > Chris Shiflett wrote: > >> Richard, >> >>> Do you really believe that for $200 (or $119, or $500) that they >>> "proven" >>> themselves trustworthy? >> > > LOL no, I don't. As a matter of fact crooks usually have more money in > their pockets than honest people do, so it's highly possible that a > crook will pay the money while the innocent will save his last cent :)) Please watch the attribution here. I never posed that question (Do you really believe ...), as it is very misleading and would indicate that I have very little knowledge about PKI systems, which is not the case. I know that the purchase of a certificate from a trusted Certificate Authority is a very important part of the security that SSL provides, and I would not pose a rhetorical question in a weak attempt at trivializing this. >> Now you've changed from "secure" to "secure from snooping." Notice >> the difference? It is significant. Like I said before, encrypting the >> transmission is useless by itself. To put it plainly: >> >> encryption != security >> >> What if you trust your friend who owns safeplace.org, and you want to >> do business with him? Maybe you visit his site and enter a credit >> card number somewhere. Thankfully, you notice that the lock icon is >> showing, and that he is using SSL. With this warped idea of SSL where >> encryption is all that counts, what if you find out that you're not >> really on safeplace.org? You're really at evilcriminal.org, and he >> has a virtual domain setup for safeplace.org. Also, he generated his >> own certificate for safeplace.org using his own CA (good thing there >> was not C&A process to undergo). So you have now sent the evil >> criminal your credit card number because you trusted his domain name. >> Good thing it's secure, right? > > > So, let's see if I got you right: > > 1) SSL just says we our packets are difficult to open, that is, > they are encrypted. Nothing more NO! :) That's what some other guy was trying to say. He is wrong. SSL does much more than encrypt the communication. Part of my response was a bit satirical in a weak attempt at pointing out how ridiculous a notion this is. I guess it didn't help very much. :) Note the use of the phrase, "With this warped idea of SSL where encryption is all that counts...." I apologize for adding to the confusion there. I was trying to point out how insecure this model would be if encryption were all that SSL provided and the only trust involved was the trust of a domain name. > 2) Our packets are difficult to open but they are totally open > to Uncle Sam's control software, as the RSA thingy cannot > shield them from "governmental inspection", which makes sense > if you are writing software for an american citizen but > it's pretty annoying if your customer is from somewhere else. No government, as far as I know, can break the public key cryptography currently being used by most SSL-enabled sites (using the strong security - 128 bit certificates). This includes the United States. Now, SSL only encrypts your communication in transit, of course. I'm sure your local government could find a way to make the entity you are communicating with release the information in the communication to them. This is, of course, outside the scope of SSL. > 3) A key is nothing more than a negotiation token, a mere building > brick that is used to fire the process. A key, when spoken of as one entity, is a key pair. It contains both the public and private keys. The use of these in cryptography is called asymmetric cryptography. To understand asymmetric cryptography, it is helpful to first explain what symmetric cryptography is. Symmetric cryptography is basically the use of a single key for the encryption and decryption. Most two-way encryption algorithms you are probably familiar with use this approach. For two people to effectively encrypt their communication with this approach, it is necessary for both parties to have the same key. To submit this key over the Internet would be a poor idea, because it could be intercepted, right? Ironically, most keys for use with symmetric cryptography are distributed over the Internet using asymmetric crptography. :) Others use some sort of physical transfer, like meeting each other on a dark street corner with a briefcase. :) The problem with trying to use this type of approach to encrypt communication between a Web client and a Web server is pretty clear. If your customers can be anyone, then anyone must have access to the key. Thus, all of your customers would be able to decrypt communication from all of your other customers. Otherwise, if each client's communication was encrypted using a different key, you would have to have a separate key for each client, *plus* you would have to have a secure way to receive these keys on the initial transaction in a timely manner. This poses a real challenge. The solution is asymmetric cryptography (public key cryptography). With this approach, each party has a key pair. The cryptography is quite advanced, and I've only begun to comprehend the generation of the keys myself. However, it is adequate to know that one key is used to do the encrypting, while the other is used for the decrypting. These are generally referred to as public and private keys, because one is made available to the public while the other is kept safely stored (in the case of Web browsers, it is stored in the certificate repository of the browser). To see how this helps solve the problem of securing Web transactions, remember that both the Web client and the Web server possess a key pair. Thus, we have four keys: 1. Web server's public key 2. Web server's private key 3. Web client's public key 4. Web client's private key Items 1 and 3 are exchanged in the initial SSL handshake. This takes place prior to the HTTP request being transmitted. Because information encrypted with the public key can only be decrypted with the corresponding private key, the basic exchange works like this: 1. All HTTP requests are encrypted with item 1, so that only item 2 can be used to decrypt them. 2. All HTTP responses are encrypted with item 3, so that only item 4 can be used to decrypt them. With this method, the only entity that can decrypt the HTTP request is the Web server receiving the request, and the only entity that can decrypt the HTTP response is the Web client that sent the original request. This overview only covers how the cryptography is made secure. Remember, PKI provides the following assurances: 1. Identification 2. Authentication 3. Authorization 4. Integrity 5. Confidentiality 6. Non-repudiation So, we have effectively only described how item 5 is achieved. I do not have the time to explain each of these items in as much detail, but the most important topic of the things left is item 1, identification, which is alluded to in your next question. > 4) the "trust" you buy is something like a fixed IP number, that is > the guys in the major do certify that you *are* who you pretend > to be. The trust I spoke of in my earlier response dealt with identification. If you cannot guarantee the identity of the entity with which you are communicating (whether the communication is encrypted or not), then your communication is very insecure. Digital certificates solve this problem. A digital certificate, as RSA describes it, is a document that says: "I guarantee that this particular public key is associated with this particular user; Trust me!" So, assuming for the moment that we trust the certificate, we can assume that a particular public key belongs to a particular user. For example, you can be guaranteed that a public key belongs to me (Chris Shiflett) and thus, only Chris Shiflett will be able to decrypt the communication. If someone is trying to pose as me, you may send them encrypted communication, but they won't be able to decrypt it. > 5) If the one I am pretending to be is a criminal, being trusted by > Verisign (or whoever in their place) won't make any difference. > Their "license" just means that you are really dealing with those > you think you are dealing with and that they do bear legal > responsibility for whatever will happen in the transaction. > Again, legal action will eventually have different > results depending on where the trusted company is based, since > not all countries have the same normative set. But that has > nothing to do with the SSL protocol in itself. Well, I disagree that this has nothing to do with the SSL protocol itself. Identification is a very important part of enabling secure transactions to take place over the Web. Without this, there would be no "ecommerce" as it has been dubbed. The role companies like VeriSign play goes back to the assumption we made above, where we assumed the digital certificate to be trustworthy. Since a digital certificate guarantees us that a specific person is associated with a specific public key, we must trust this certificate in order to trust the association. In the case of HTTP transactions, the entity that needs to trust the (SSL) certificate is the browser. Browsers come with a whole group of Root certificates that are trusted by default, and any digital certificate issued by these CAs are thus trusted. Any certificate issued by a trusted CA is going to claim something like the following: "I guarantee that this particular public key is associated with this particular domain name; Trust me!" So, when our browser communicates with goodguy.org, it uses this guarantee to make sure that only the *real* goodguy.org can decrypt the communication. If someone at badguy.org tries to impersonate goodguy.org, this guarantees us that they will not be able to encrypt the communication. Of course, as users of Web browsers such as Netscape and Internet Explorer, we have to trust AOL/Time Warner and Microsoft, respectively, (yeah, scary thought) to only trust CAs that have high integrity, security, etc. An extensive C&A (Certification and Accredidation) process is used to make this guarantee. > Now, there's a question regarding point 4). What if someone from > www.goodguys.com > gets the certified key pair and hands it over to some crook outside > the company? I hope this is not just as easy as it sounds (the key > pairs will probably check something in the environment before starting > to shout "YEAAAH!! IT'S MEEE!!!") but still... This would be a scary thought. Luckily it's not possible. A key pair is unique per Web server, right? Well, recall that the digital certificate only guarantees that a certain public key belong to a certain entity (in this case, a Web server). In order to make this association in the first, a request for an SSL certificate must be created by the Web server intended to be used to service that particular domain name, and adequate proof that you are the rightful owner of the domain name is also required. Without this, the CA wouldn't know which public key was *definitely* yours, so it couldn't, in good faith, create the digital certificate. So, for your above scenario to work, the crook outside the company would have to be handed the actual Web server software as it is currently compiled (for example, hand him the whole physical server) to be able to use that digital certificate. In addition to this, the crook would also need to trick someone's computer into resolving the domain name to be *his* IP address rather than the real one. With all of these things in place, the browser connecting to the crook's site with SSL would not issue a warning. In practice, however, not only is this extremely hypothetical, but the people at www.goodguys.com would surely have found out about this (their Web site is gone, all of a sudden) and notified the CA. The digital certificate would be revoked, so it would no longer be valid. Why does revoking it do any good? Remember, there is a chain of trust. To trust a digital certificate requires that you trust the CA from which it was generated. When done with software rather than people, a check is made with the CA to make sure this certificate is still valid. > As for point 2), please get me right. I have my own political opinions > as anybody > else, but my concern here is a professional one, since my customers > are 99% > not americans. Small-mid sized companies (including mine) usually do > not give a > damn about having their messages read by american eyes (we are simply > not worth the trouble of looking in our archives) but large companies > and Govt. organizations are *much* less indifferent to the subject, > and I guess it's understandable, they want their privacy to be for real. I understand the concern. However, like I said, regardless of political policies, you can be assured that the communication cannot be decrypted, tampered with, etc. Political entities could put pressure on the recipient of the communication to reveal it, but that is all. Of course, the US government may have figured out how to break 128 bit public key cryptography, but I seriously doubt it. This just skims the surface on PKI and SSL. I hope it at least clarifies a few things, because there was a lot of misinformation being thrown around earlier. Happy hacking. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
