The most obvious badge of internet security is the "lock" icon. The lock indicates that the website is backed by a digital certificate:
Yeah, exactly. Who decided these CA’s were trust worthy? There’s basically the same root cert list in FF 2 that there was in Netscape 2 10 years ago. I remember b/c I had to buy a cert way back then. Those lucky few who got in the list (who decided that?) can now charge us yearly for cert signing that costs them nothing and is totally automated (GoDaddy’s $19.95 cert is instant, requires no faxing / emailing them anything).
The only things certs are good for is encrypting traffic. Yes, locks give people warm fuzzies, but the reality is that if someone can poison the DNS system and redirect to their own server, it is even easier to obtain a certificate from the inexpensive providers that is “good enough”.
Verisign remains high on the trust list, however, because they actually do verification of the information. I know, because every few years something breaks the automatic renewal process of our certs. (Our office changed address on year, the technical contact changed on another).
It’s certainly true that web browser developers/packagers are making security decisions on behalf of customers. That said, though, this is at least as secure as most other things in the real world. Sure, the whole system relies on the idea that Verisign won’t suddenly decide to cooperate in a scam. Then again, people generally have no choice but to make the assumption that significant companies won’t violate public trust in any number of ways. If they do, one hopes (though not always reasonably) that they will lose their credibility and be economically forced out of the picture.
So that lock thing means two things: first (and most significantly) that the web traffic is encrypted; and there’s no problem there. Second, that the web site is who it claims to be; but that simply won’t work unless users specifically check on it. And personal names – the kind you can back up with a driver’s license – can’t be trusted in that way anyway. I’m sure there are plenty of people named Bill Gates in the world, and some of them don’t represent Microsoft. So I don’t see a lot of opportunity for improvement in this way.
I agree with an earlier post that the attempt at transparency is risky, but I also question whether a less transparent approach would ever be accepted. In the end, there is a limited extent to which people are willing to be inconvenienced to protect themselves against highly unlikely security threats.
On Phil Zimmerman’s ZFone project website ( http://zfoneproject.com/prod_zfone.html ) he has two great links worth reading regarding the PKI infrastructure worth reading:
Ten Risks of PKI: http://www.schneier.com/paper-pki.html
Improvements on conventional PKI Wisdom: http://www.cs.dartmouth.edu/~pki02/Ellison/
His ZRTP solution for VoIP doesn’t apply to web applications, but his use of glyphs is helpful and I’ve seen a number of bank sites starting to use them. It’s going to be interesting to see what emerges as the new model for web security (especially in regards to authentication).
I agree with the point that people often put too much faith in what a digital certificate can provide. It definitely does not guarantee that the recipient of the digital certificate is a reputable business person.
I do think it does do a fairly good job at what it promises, which is to prevent eavesdropping and spoofing. I fault Verisign if someone intercepts my conversation or else the owner of the certificate is not really who they say they are, but I assume that it is my fault if I choose to trust a crook. In the best case, I would hope that I have a better chance of tracking down that crook afterwards if Verisign has done their job properly. It is more about providing traceability and accountability than it is about guaranteeing trust in the first place.
All I assume from the lock is an encrypted connection, which is my main concern. I don’t need anybody sniffing at my private packets. But as for the guy at the other end, I use my own judgment and common sense about who gets my data. Very few qualify.
But few if any casual users will ever understand the risks and implications of a cert…
I strongly believe that certificates have their place in the security communication over the internet. In order to establish an SSL connection to a server, you firstly need to accept the server’s (Amazon) public key and use it to decrypt the communication that comes on the pipe. The communication can come from anyone not only Amazon. In order to bring some structure to this possibly chaotic problem, there are these CAs that compute a hash of the public key, encrypt the hash with the CA’s private key and append it to the actual public key. In effect by adding the CA’s private key encrypted server public key plus some information about the server you have a certificate. Now the issue boils down to if you trust the CA to have verified the credentials of the server that asked for a certificate for its public key. From my knowledge, VeriSign has three levels of certification: level 1 requires a valid email address and is the less trustworthy, level 2 requires a valid mailing address and a valid email address, and level 3 which is the most expensive and more trustworthy than the first two, requires the requester to show up in person and prove who he/she is and get their certificate.
As I said in the beginning of this post, if you want to establish an encrypted connection with a server, you need to trust that the public key that is offered to decrypt the server traffic comes from the actual server. A better way than trusting VeriSign is to go and get the public key in person from the server. Also, to finish my idea, the entire communication encryption is as good as the usage of the data that reaches the server. Upon arriving at the server, the data stream is decrypted and used in a certain fashion. How are you going to trust that server that it will not missuse your data? Hard to do.
Heck, you don’t even need a cert from an iffy CA to make a user feel warm and fuzzy. Use a pretty little lock as your favicon.ico file and most browsers will be happy to put it next to your domain name. I doubt that most users would notice the lack of color behind the address. If they noticed anything, it would be the comforting (but misleading) lock beside the domain name.
You’ll always have the problem of authenticating through a third party. The real scam is that if you want to encrypt traffic to and from your site and not annoy users with the popup that says your site’s certificate can’t be validated, you must buy a cert from one of the major CAs that have their CA public certificates bundled with the browser distribution.
In my mind this was Netscape’s screw up when they created the first SSL implementation. Encryption of the channel and authentication of the end point are two distinct things, but Netscape stupidly tied them together.
Real life isn’t all that different. Put on a suit and print out the first google hit for “FBI Badge” and see who’s going to dare question your “badge”.
I have to mention my favorite part about digital signatures is spyware/malware that’s digitally signed. You can’t top that! Digital signature is as meaningful as a candy wrapper. If you find a toffee on the street, but it’s still wrapped, do you eat it? I’m not trusting that candy wrapper.
As for SSL, the only thing that SSL really ensures is that the data going between your computer and the remote server can not be spied upon by 3rd party prying eyes. What happens to the communication once it gets to the server is a whole other issue. I’m not going to be trusting sleazy web site with important personal data, no matter who signed their certificate. I’m would not run “love.exe” that comes in my email even if it is digitally signed.
The disgusting thing is that they are making money from this scam. Certificate Authority should really be a non-profit organization. For companies like Verisign, the fact that they’re in this for massive profit with their exorbitant prices really undermines their position of authority. In the end they’re doing it for their own profit, not my security.
That’s my two cents.
As already pointed out, certificates are to verify the site or executable’s identity (i.e. you are not being spoofed) and to encrypt traffic. They do not guarantee the reputation of the organization that is offering the site or executable. Certificates do not replace the BBB or your own common sense.
Here’s an analogy. Let’s say you’re in Manhattan at one of those famous discount electronics boutiques. Asking for “Crazy Sam”'s driver license will help you to verify that he is indeed “Crazy Sam” owner of “Crazy Sam’s Too Good to Be True Electronics”, but it won’t guarantee that the “Panasoanic” TV your buying is the Panasonic he’s fooled you into believing it is. Should we also be decrying the use of driver’s licenses to verify people’s identity, just because a crook can also have a legitimate license?
Scott G,
I agree with you 110%. It is stupid that SSL requires certificates. PKI does not require certificates, just an exchange of public keys. Having encryption entangled with identity verification has been a major PITA for anyone wanting to just encrypt traffic.
I’m not quite sure what you are implying with this post. Certificates protect you from accepting something bad from someone who you trust, via the old swithcheroo.
What else do you expect?
It’s obviously not feasible for anyone to validate the intentions of every piece of software you choose to install or every single website you visit.
But it gives me a warm feeling to know that when I visit gmail it is in fact gmail or when i install software from microsoft that it is in fact from microsoft. And certificates fill this function perfectly.
Essentially all certicates are really good for is knowing that the channel is encrypted, using it to verify identity as well seems suspect.
What’s to stop someone from getting a certificate for “Apple, Inc.”? Does the registrar actually do due diligence to verify the business exists under that name and is not in violation of trademark laws? I think not.
All the certificate is saying, is that at the time of issuance, the entity named in the certificate could prove more or less that they had ownership rights for the domain (CN) the certificate was issued for. Nothing more, nothing less. Unless there are new certificate types that are harder to get.
On the subject of trusted SSL certificates, you might be interested in CACert, which uses a community based approach to issuing certificates. Did I mention they are free?
Right now they are working towards inclusion in Firefox. However, I doubt Internet Explorer will ever accept them. To Microsoft, certificates are all about money.
In the netherlands the banks joined forces and launched the campaign 3xkloppen.nl (litterally: 3 knocks, but also “check 3 things”).
The 3 things to check are: computer security, website, payment.
In the website check, there are 3 items, some with 2 subitems:
So only a minor part of the security campaign revolves around the certificate. But the danger is in connecting the certificates with trust.
As you said, a certificate certifies that a website is who it claims to be, and that the certificate itself is not fake. However, a phisher could easily set up www.mybank.com (instead of .nl), assign it a tucows certificate and use a looptrough authentication to do a man-in-the-middle-attack and change the account number. The layman who is confronted with a slightly off login procedure will check, miss the off TLD, see the padlock and colored address bar and think “this is ok”, and continue. Boom, account compromised.
But then, what should we tell the layman? “trust only sites with a certificate”, thus learning the phishers they should use certificates (an easy task to do)? or learn them to trust nothing, in which case they either go paranoid or (more probable) waltz into any phishing trap?
Who can think of a way to certify (using certificates or other ways)that sites are “trusted” in a way the layman can understand?
@alan:
Do you read previous comments before you post? You might be interested in the one by Sumo with the link to a MS security bulletin.
Regards
Peter
Two other things which involve digital certificates: Signed Java applets, and drivers.
On that last note, in 64-bit versions of Vista, Microsoft has ONLY allowed the use of drivers signed by a ‘trusted’ authority… As far as I’m concerned, such exclusion and isolation is even worse than certificates’ use in other regards, as flawed as it might be there as well. I wouldn’t mind it as much if they weren’t so insistent upon it… http://tiniuri.com/f/0mc
“In my mind this was Netscape’s screw up when they created the first SSL implementation. Encryption of the channel and authentication of the end point are two distinct things, but Netscape stupidly tied them together.”
No, the two are linked together. http://en.wikipedia.org/wiki/Man-in-the-middle_attack
Also, the guy who said SSL is broken. No, SSL is just fine. It is the key management that has grown up around the web that has issues.