At 12/4/01 6:58 PM, Eric Smith wrote: >Encryption is entirely useless if you can't confirm the identity of >the other party, because it is subject to man-in-the-middle attacks. >In other words, I could open an encrypted link to someone who claims >to be ibm.com, and if I don't have any way to confirm that they really >are authorized representatives of IBM, the encryption is NOT going >to prevent my data from getting into the wrong hands. The point of >the X.509 certificate is to give me trusted third parties that can >provide information to confirm that the web site is really operated >or authorized by the party that owns the domain. The trusted third >parties are the certificate authority, and the browser vendor who >put the root cert for that CA into their browser. (Sophisticated users >might choose what root certs to use, but the average user does not.) > >However, contrary to what some have claimed here, all I expect out of >the certificate is proof that the server that handles IP traffic for >the domain name "www.ibm.com" is being operated by (or at least with >the authorization of) the party that is responsibile for the ibm.com >domain.
I agree that there is value in knowing that your connection to www.ibm.com is actually going to the organization that registered ibm.com, and I also wouldn't argue with people who say there is extra value in knowing that you're connected to the organization that owns the IBM trademark. However, that's mostly useful when you know and trust the URL of the site you're going to via external means -- for example, if you've heard of IBM and trust them in advance, it's obviously handy to know you're talking to ibm.com. But if you've never heard of the organization you're connecting to, and have no external way of knowing if it's safe to trust them, it doesn't really matter whether you're connected to the organization that registered the domain name, let alone whether they own the trademark, etc. Since most of my customers have never heard of tigertech.com before they make a purchase, there is less value in authenticating who I am -- perhaps not enough value to justify me spending several hundred dollars a year for it. From the customer's perspective, I'm just as likely (or unlikely) to be stealing their credit card whether I'm the guy who registered tigertech.com or not. Imagine a bad guy who was able to place themselves between the customer and my standard (non-SSL) site. To begin the attack, the bad guy intercepts and changes the ordering URL on my insecure pages to point to a fake secure page under his own domain name (such as "tigertech-orders.com") and certificate for "Tiger Technologies" (which he was able to get authenticated by filing a $35 fictitious business name statement at his county office). Since the customer doesn't know there's anything wrong with this, no alarms are raised; authentication in certificates wouldn't help at all. Anyway, my point was not that authentication was useless -- encryption, authentication, etc. are independently useful additive security measures, each of which prevent different sorts of attacks. But there are situations where encryption alone may be sufficiently useful if your main concern is preventing the casual Ethernet snooper in the next cubicle from stealing your credit card number. Given that, there should have been an option for self-generated, free encryption only certificates (with a different lock icon, or whatever) in the first place. It's highly annoying that you can't do simple encryption without paying extortionate fees to certificate authorities (and indirectly, browser makers), based on the claim that it's expensive to verify the authentication you may not even want. In fact, the idea that there should be different "levels" of browser security would come in handy in the current discussion. Simple encryption could be level 1 security, domain contact authentication could be level 2, and corporate owner authentication could be level 3. Alas, we're stuck with an everything-or-nothing notification to the user, leading to an argument about what's "sufficient" to show the lock icon. :-( -- Robert L Mathews, Tiger Technologies
