Richard, Honestly, I think you need to just buy on book on this. I think I explained things pretty clearly, and your confusion now seems to be based more on a lack of trusting my explanation more than anything. I can't imagine how you could still be this confused.
I will try to explain once more for the benefit of readers who may be wondering if anything you said is true. Richard Lynch wrote: >No, the *TRANSMISSION* is just as secure from snooping. It's the >*RECIPIENT* whom you trust, or not. Maybe they've hijacked DNS records and >are masquereding. Maybe they just didn't pay the $200. Maybe they paid >$200 and are crooks. > >Do you really believe that for $200 (or $119, or $500) that they "proven" >themselves trustworthy? > 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? Hopefully it is clear that the trust in SSL relies on the trust of the certificate which relies on the trust of the root CA that issued that certificate. Trusting a domain name makes absolutely no sense. >>>Yes, the basic model for the security of all eCommerce is: >>> >>>"You pay some large corporation $200, and they trust you." >>> >>> >>> >>No, you pay some large corporation money, because the majority of >>browsers currently in use trust certificates issued by that corporation. >>They've had to undergo extensive C&A processes to ensure the integrity >>of their operation, and they've also had to shell out some big money to >>Microsoft and Netscape to have their root certificates installed and >>trusted into their browsers. >> >> > >And for the $200, they do a background check on everybody, or what? > >What's to stop a criminal from getting a $200 certificate? Nothing. > >How do you *KNOW* that web-site isn't run by a criminal? How do you know >they aren't collecting credit-card numbers? How do you *KNOW* they aren't >storing them insecurely? > >Fact is: All you *KNOW* is that they paid Thawte, Microsoft, or some other >large corporation $200. You don't know *anything* else about them. > This, I believe, is where your largest confusion lies. Read my first response to this again (quoted above). Did you read it? Read it again. The C&A process is what someone like VeriSign undergoes, not the guy buying a certificate for evilcriminal.org. >>The browser *should* issue a warning when the identity of the Web server >>it is about to communicate with cannot be guaranteed. You seem to be >>confused about where the trust lies. If I trust the Web site >>http://www.mybuddy.org/ (hypothetical best friend's Web site), does that >>mean I should trust any certificate that is issued to www.mybuddy.org? >>What if the certificate's root CA was a criminal's PC? Are you *sure* >>that's your friend's Web site that you are communicating with? >> >> > >If I *TRUST* mybuddy.org, the I *TRUST* them not to install a Certificate >from a criminal's PC !!! > >I *TRUST* them not to have non-repudiated Certificates floating around out >there. > >Conversely, if I don't know squat about mybuddy.org, all I know is they paid >somebody else I don't trust $200. > >Maybe you just trust big corporations more than I do. I dunno. > >All I know is, the "Trust Model" *IS* > >Somebody I don't trust pays somebody else I don't trust $200. Period. > >Doesn't instill a lot of faith in the system for *ME*. Might be enough for >you to have Faith, but not me. > Alright, I'm starting to think you're trolling now. That might be funny on Slashdot, but it doesn't belong on this mailing list. I will clarify for those who need this information. Here you are trusting a domain name again. That's a risky business, and luckily you didn't create a security model that anyone would implement on the Web. The same question arises yet again. How do you know that's the real mybuddy.org? Because it has a certificate from a CA that is not from a criminal's PC, right? How can you tell the difference between a CA from a criminal's PC and one from a place like VeriSign? Do you think it's just name recognition? Surely not. When you click past the warning that you seem to think shouldn't be there, do you check the fingerprint of the root CA first? If you do, and you trust it, just import the root certificate into your browser and trust it. Then you will have no more warnings from that certificate. Luckily, a certificate from a non-trusted CA issued to mybuddy.org will still display a warning. Your browser has a default list of root CAs that it trusts. You can go look through them if you like. A certificate issued by a trusted CA to mybuddy.org is infinitely more secure than a certificate claiming to be issued to mybuddy.org from an unknown CA. If the browser treated both the same (which you seem to be suggesting), then no one would have any confidence in the identity of the Web server they are communicating with. >>ver, if you do trust a certain CA (perhaps your own), you can import >>your root certificate into your browser and check some boxes to trust >>it. Luckily, browsers don't even allow a method for you to "trust" a >>domain name. >> >>It is quite trivial to generate a certificate for www.amazon.com. It >>isn't too terribly difficult to make someone's computer think >>www.amazon.com is your Web site. Here come the encrypted credit card >>numbers. Good thing they're secure. :) >> >>The point is, PKI isn't about encryption alone. In fact, the "textbook" >>answer to the question of what services PKI provides is: >> >>1. Identification >>2. Authentication >>3. Authorization >>4. Integrity >>5. Confidentiality >>6. Non-Repudiation >> >>If it only provided confidentiality, quite honestly, PKI would be >>useless as it is implemented today. >> >> > >Do *YOU* trust the CA people to have thoroughly researched joesbotique.com >when you give them your credit card? > >How do you know it's not a scam? > >How do you know their certificate hasn't been stolen, and they haven't even >figured it out yet? How do you know they were trustworthy people in the >first place? > >You only *KNOW* that somebody, somewhere, at some time, paid $200 for that >"Certificate" and that nobody has noticed something skanky about it -- at >least not yet. > >The more I think about this, the more I agree with people who just won't do >eCommerce at all... > It's your job to trust joesboutique.com or not. How is any technology supposed to help you there? You want me to write a program to let you know which friends to trust, too? The CA simply assures you that it really is joesboutique.com and not some rogue Web site dressed up like joesboutique.com with his own SSL certificate trying to coerce you into "buying" things from his site. As for stealing a certificate, how do you propose to do that? If you've ever installed an SSL certificate, you should be well aware that you must generate the request using your Web server. If anyone can install your SSL certificate on any Web server, why would this step be necessary? Think about it. I think SSL was a truly revolutionary idea that is extremely secure. It irritates me to see such misinformation thrown around on a developer's mailing list like this just to get a few laughs. Troll somewhere else. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
