>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.
What I can't imagine is how confused you must think I am -- Since I'm not AT ALL confused. >I will try to explain once more for the benefit of readers who may be >wondering if anything you said is true. A great deal, nay all, of what I said was true. Unfortunately, what you understood of it, was not true -- But that's not what I typed. >>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: Notice how I first said *IN* *TRANSMISSION*. Now, apparently, to *YOU* that wasn't sufficient to indicate: "while the packets are travelling from your browser to their destination". When I first said "in transmission": I did not mean "reaching the right destination" I did not mean "the destination was worthy of trust" I did not mean "reaching any destination at all" I just meant "while the packets are travelling from your browser to their destination" (whatever that destination might be). Somehow, you read that as "Definitely reaching the intended party, and the intended party being trusted" Thus, I intentionally *ADDED* "secure from snooping" in my later post to clarify what *I* mean when I say "in transmission". I just mean "in transmission". Not reaching any particularly good nor bad end-point for that transmission. I think we both agree that any old certificate is secure from snooping, right? Now, since the only way I can see for it to be transmitted to the wrong party at all would be for the evil-doer to hijack the domain name as well as the SSL cert, I kinda figured it was a foregone conclusion the it was not the "transmission" at issue -- It's the *DESTINATION* at risk. Apparently I should have spelled that out from the beginning, since you obviously misunderstood (and *still* misunderstand) my point. >encryption != security Obviously, since they aren't spelled the same way. C&A SSL != security either. "More" secure than just encryption? I suppose... But not really enough more to inspire any real confidence in a C&A Signed Certificate. >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? What if evilcriminal.org *STOLE* the C&A signed certificate from safeplace.org as well as hijacked their domain name? What if evilcriminal.org set up safeplace.org and just *PAID* friggin' Microsoft for a C&A signed certificate in the *FIRST* place. Yes, a C&A signed certificate is nominally "better" than a non-signed one, since you know that at some point, somebody paid somebody at least $119 (US), and that the certificate has the same domain name as the domain name of the computer you are now surfing to. You don't know it's the same computer, though, right? It could easily be a stolen Cert and hijacked domain. For that matter, you don't know that a CRIMINAL purchased the C&A signed Certificate in the first place. I say again -- Do you *REALLY* believe that for $119, or even $500, that a complete background check is run on the people running all those web-sites with perfectly valid SSL Certificates that make the pretty lock icon close? I sure don't. I consider a C&A Signed Certificate not significantly more reliable, trustworthy, nor "safe" than an unsigned one. I don't trust the signers. I don't trust that the people on the other end are who they say they are. I have a low trust factor all around. >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. Sigh. I'll say it again: I don't trust a domain name. I have an *EQUAL* distrust of a C&A signed certificate alleged to go with a domain name. It's not that I trust a domain name so much -- It's that I trust the system of C&A signing so *LITTLE* Are you reading what I'm typing? It sure doesn't sound like it... You make it sound like I think it's perfectly safe to use a credit card on any old SSL link, C&A signed or not. No. I *ALSO* contend that a C&A signed certificate *ONLY* proves: example.com paid $$$ to somebody I don't trust, *OR* example.com *STOLE* both the domain name and the SSL from somebody who paid $$$ to somebody I don't trust Now, suppose I *REALLY* trust the people running example.com? So what? I don't trust that they haven't been hijacked. So I don't trust that their signed Cert is any more valid than their unsigned Cert, *BECAUSE* they could have had their domain name and their signed Cert stolen. Hopefully, example.com would *DO* something about this situation immediately. I sure don't trust the C&A folks to notice of their own volition. Either I trust the folks at example.com to make sure their certs are not stolen, to make sure their domain is not scraped&hijacked, to make sure that any stolen certs are repudiated, or I don't trust them at all. If I trust them to do all that, then they either watch their domain name *AND* their Certs like a hawk. If they do that, then what "extra" trust is there in the C&A Signing by a company I don't trust? The people who made my *BROWSER* might trust those C&A signers, but *I* don't. The only real added value is the repudiation of a C&A Signed cert -- which is not really worth a whole whole lot when I don't trust the C&A people to do their job right, now is it? >>>>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. What *PROCESS* does evilcriminal.org have to undergo to get a certficate that will make the pretty lock icon "closed"? 1. Register a domain name. 2. Pay $119 3. Wait. I don't *CARE* what process the the C&A companies went through. Security is only as strong as the weakest link in the chain. The weakest link here is: *ANY* schmoe can pay $119 and get a C&A-Signed SSL cert. I do *NOT* trust the C&A people did *ANY* real background check on that schmoe. >>>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. Look, neither of us is saying anything new here. I *UNDERSTAND* how this works. I DO NOT TRUST THE C&A PEOPLE TO DO THEIR JOBS RIGHT Okay? I have *NO* *MORE* trust in them than I do in the guy I don't know at mybuddy.org >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. Sigh. I treat them with *EQUAL* lack of confidence. >>>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. I have no confidence that a theif didn't steal both the domain name and the Cert, and, while we're at it, his whole damn web-server, lock, stock and barrel. I have no confidence the C&A people would notice. I have no confidence the C&A people would do a good job of doing something useful in a timely fashion if if they were notified. I don't trust the C&A people. I don't trust the people who trust the C&A people. I don't even trust you :-) The C&A Signed Cert with the pretty little lock icon has NO MORE trust factor for me than an unsigned home-brewed SSL connection. They are equally un-trustworthy. Are you understanding me yet? Will you at least stop claiming that I trust a domain name? How about this: I don't trust my mother. And she's dead. Is that clear enough? >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. Work with me here, okay? I steal his SSL certificate. I steal his domain name. I put them on my own web-server. When/how do the C&A people catch this? I either trust the DOMAIN NAME owner to *DO* something about this *WHEN* it happens, or I don't trust the site. The signed/unsigned SSL connections are *EQUALLY* untrustworthy *BECAUSE* I don't *KNOW* for 100% certain that the recipient is *really* the guy I trust. Now, here's the crux of the matter, which, every time you read it, you think I "trust" a domain name not getting hijacked by a crook, which I don't: If I *really* trust the person who owns a domain name, they are going to take care of any hijack/theft just as quickly with an unsigned cert as they are with a signed cert. I don't trust the C&A people to facilitate that process any faster or better than somebody I actually *DO* trust in the first place -- The person I personally know who owns that domain name who is going to make damn sure they catch and rectify any hijacking with or without a signed Cert as fast as possible. I trust that person because I know them, not the C&A people I don't know personally, and who have *PROVEN* themselves untrustworthy. I trust people, not corporations, not technology, and *CERTAINLY* not the C&A Signers. If a person I *TRUSTED* chose to have an unsigned C&A Cert -- I would trust them. Not because their site couldn't be hijacked. But because I trust them to do the right thing if it was. Not because I think my credit card isn't at risk, but because the risk is NO HIGHER with the unsigned Cert. The signed/unsigned Cert are *equally* untrustworthy to me. Do you *really* understand what I'm saying? Because if you do, you'd agree with me instead of arguing that C&A Signed Certificates are significantly more trustworthy when you have 0 trust in the person holding the Certificate in the first place. I don't even trust the folks *issuing* the C&A Certs, much less some guy I never met who happens to be holding it and a domain name that matches. Or, at least, *I* have 0 trust in some schmoe who sets up a web-site. I've had to debug enough of them with horrible security to know just how bad it could be. Put it into real-world terms: Let's compare two equally good used cars. Car A is from a licensed used car dealer, which has gone through the same business license process as every other licensed used car dealer. Car B is from a person you personally know and trust. Which car you gonna buy? Do you trust that used car dealer simply because they have a lot and a piece of paper from the government? Maybe you're the kind of guy who buys from a used car lot instead of a friend, because you think that's safe. I'm not. It's that simple. The two cars are equally likely to crap out on me, but if they do, I have a lot more trust in my friend making it right with me than some used car lot I don't know. >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. I'm not laughing. I'm not trolling. Nothing I said was false. You may have mis-understood it, but it wasn't false. The "Security Model" of SSL and C&A signed certificates gives me little "trust" in the system. Maybe it's the best anybody can come up with. Still not inspiring confidence for me. Hopefully, at this point, you actually understand what I typed in the first place. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
