Weekly Edition
Return to the Security page
| |||||||||||||
Extended validation certificatesA new 'security' feature being touted by Microsoft and Verisign has raised a number of red flags for the open source community, but it appears that the new "Extended Validation" (EV) SSL certificates are not some kind of attempt to squeeze out the competition. Neither of those two companies are known for their ability to play well with competitors, so any collaboration between the two requires some close scrutiny to try and ensure a level playing field. In this case, the field seems level, but the security provided by the new feature is somewhat dubious. SSL certificates are used by the HTTPS protocol for encrypted traffic between a web browser and the web server; they are issued by various certificate authorities (CAs) such as Verisign. An SSL certificate is generated for the domain at which it resides and then signed by a CA after it does some verification of the entity requesting the signature. Because CAs have traditionally done very little in the way of validation, a signed SSL certificate does not tell you very much about the identity of the domain; it essentially just verifies that the domain owner was willing to spend $50-100 to get the signature. When presented with a certificate, a web browser attempts to verify any signature using a set of public keys for the CAs that the browser developers have decided to trust. Verisign has generated a new set of keys to sign the EV certificates and Microsoft has already incorporated that public key into IE7. In addition, when presented with a properly signed EV certificate, IE will turn the address bar green to indicate some purported higher level of security. For browsers that do not support EV, Verisign will presumably still sign EV certificates with their current key and those browsers will still display the padlock icon. So, what does it take for a site to get this EV certificate? One would guess that more money would be involved and that is certainly the case. One would hope that more investigation of the entity requesting the signature would be part of it as well and that seems to be the case, but the actual requirements are, as yet, unspecified. The Verisign FAQ indicates that the requirements are soon to be released by the CA/Browser Forum. This organization (which appears to have no website) is a group of CAs and browser developers that is said to include both Microsoft and Mozilla (as well as Opera and KDE) and has been working on EV certificates for 18 months or so. The two big concerns about all of this are that either Verisign will monopolize the EV certificate generation or that Microsoft will monopolize the verification of them. Neither appears to be the case as Verisign clearly states that other CAs will be able to generate EV certificates and other browsers will be able to validate them and, presumably, turn their address bars green too. Mozilla has EV on its radar and it is listed as a feature to be added, but Verisign and Microsoft are the first to market. An article in The Register was the first to alert most people to the new feature; it quoted Tim Callan, a marketing director at Verisign, bemoaning the slow pace of adoption by Mozilla. Callan has since clarified his statements and says that he did not indicate any displeasure with the pace of adoption by the Mozilla Foundation. Commercial browser developers can move more quickly on adopting new CA keys because there is a financial motive, whereas open source browsers need to ensure that they have consistent policies about adopting new CAs and keys. It is interesting to note that the perceived inadequacies of current SSL certificates are a problem that the CAs created for themselves. Because they were willing to sign any certificate with extremely minimal verification of anything other than the credit card charge to pay for it, they made SSL certificates and the padlock icon relatively meaningless for anything other than an indication that the traffic is encrypted. Unless the verification of the entity is extremely thorough (which would be very costly), it is unclear that EV certificates will really do anything to change that. Even then, few people actually look at the name attached to an SSL certificate, and many might be surprised at the names that show up if they did. The end result is that anyone wanting to abuse HTTPS will figure out a way to get a signed EV certificate and, one day, the green address bar will be no more trusted for identity verification than the padlock icon is today. Identity verification is a hard problem and EV certificates are just a quick fix, the problem will need to be addressed again; perhaps we will see 'Super Extended Validation' certificates somewhere down the road. (Log in to post comments)
Extended validation certificates Posted Nov 2, 2006 2:13 UTC (Thu) by jwb (guest, #15467) [Link] I really wish Debian would ship FireFox without any root certificates. I don't trust Verisign any more than I trust Joe Isuzu.
Extended validation certificates Posted Nov 2, 2006 3:08 UTC (Thu) by jamienk (guest, #1144) [Link] How about: when you see that a cert has been issued, you can click it, and see all the documentation that was provided to "prove" the identity of the site in question. Next to each piece of documentation, there can be a "verified by Verisign [or whoever]" stamp.
So it could read:
Extended validation certificates Posted Nov 2, 2006 10:17 UTC (Thu) by gyles (guest, #1600) [Link] That would be meaningful, and useful. It therefore won't happen.
Extended validation certificates Posted Nov 4, 2006 0:32 UTC (Sat) by giraffedata (subscriber, #1954) [Link] There's actually two parts to that: the identification and the authentication. Before you can talk about what proves Bob's social security number, you have have to say what that number is in the first place, and the current system doesn't even do that. It identifies someone by a name alone, and that tells you very little. Is this web site run by THE Bob Smith? Useful identification could be a SSN or passport number, and it could also include place of residence, occupation, and various other soft things. As long as Verisign provides the actual identification, it probably doesn't help me a lot to see how Verisign authenticated it. If I don't trust Verisign to authenticate, I really can't trust it to tell me accurately that it did. The guarantee (insurance) is what really matters. Of course, I would expect and demand to pay for that.
if Bob Smith's website rips you off, you can sue Verisign. And that's a third thing. Neither the identification nor the authentication tells you that Bob Smith is an honest person; you have no basis to sue. For that, you need a voucher. Verisign says, "never mind who the person is; whoever he is, he's not going to defraud you." To protect itself, Verisign would want to ascertain the person's identity, plus probably get references or a bond or such. For a web site, a voucher would probably be much more useful than a signature guarantee.
Extended validation certificates Posted Nov 2, 2006 10:09 UTC (Thu) by Segora (subscriber, #8209) [Link] I get the impression that the value of commercial certificates is below that of the free ones you can get from http://www.cacert.org/
Extended validation certificates Posted Nov 13, 2006 8:53 UTC (Mon) by forthy (guest, #1525) [Link] Sure it is. A non-anonymous CACert web site certificate means that at least two people saw two official documents proving your identity (passport+driver's license). However, the actual content of these documents is not recorded, so in case you want to sue someone over a certificate, you are somewhat lost with CACert certificates, as well (no address, no passport number, etc.).
Extended validation certificates Posted Nov 2, 2006 10:34 UTC (Thu) by nathan (subscriber, #3559) [Link] hey, and there was I presuming that ALL the padlock told me was that it was encrypted :)
Extended validation certificates Posted Nov 2, 2006 12:08 UTC (Thu) by gerv (subscriber, #3376) [Link] The CA/Browser forum website is now up at http://www.cabforum.org; you can download a copy of the current draft of the vetting guidelines from there. (The link's in the header, a little bit hidden for some reason.) A few inaccuracies in the article:Because CAs have traditionally done very little in the way of validationSome CAs would dispute that; they would claim that new entrants to the market have done less validation, thereby driving certificate prices down and pulling the other CAs with them, and that this is a relatively new phenomenon. Verisign has generated a new set of keys to sign the EV certificates and Microsoft has already incorporated that public key into IE7.Not so; the same roots are used. The new certificates are marked with a new policy OID. Mozilla has EV on its radar and it is listed as a feature to be addedIt was somewhat difficult for us to discuss this while the draft was secret; now that it's public, join the discussion in the mozilla.dev.security newsgroup. Unless the verification of the entity is extremely thorough (which would be very costly), it is unclear that EV certificates will really do anything to change that.That's the fallacy of unobtainable perfection. Even then, few people actually look at the name attached to an SSL certificate, and many might be surprised at the names that show up if they did....which is why the IE UI, at least, puts the company name in the chrome. The end result is that anyone wanting to abuse HTTPS will figure out a way to get a signed EV certificateI'm impressed that Mr Edge can draw that conclusion having never seen the EV vetting guidelines!
Extended validation certificates Posted Nov 2, 2006 13:44 UTC (Thu) by gouyou (subscriber, #30290) [Link] Even then, few people actually look at the name attached to an SSL certificate, and many might be surprised at the names that show up if they did....which is why the IE UI, at least, puts the company name in the chrome. Which is a good starting point, but "SecureWebsite Ltd." from US won't be really different than "SecureWebsite Ltd." from Nigeria ... Green bar, names looks ok, let's start phishing :(
Extended validation certificates Posted Nov 2, 2006 14:06 UTC (Thu) by gerv (subscriber, #3376) [Link] You really should read the guidelines and look at IE's UI before commenting :-)
The UI in IE is of the following form:
SecureWebsite Ltd. (US)
so the country of origin is displayed.
Secondly, the certificate will contain (and the CA will hold) sufficient information about SecureWebsite Ltd. to enable the boys in blue in Lagos to track down the people behind it. The guidelines have been designed to raise the cost (in revealed information as well as money) of spoofing them above the possible return from getting a certificate fraudulently. In other words, you can't make them impossible to get round, but you can make it so expensive or time-consuming or dangerous that it's not worth it for the return you'd get from one phishing site.
Note that OCSP is mandatory for EV certificates, so they can be revoked quickly.
Of course, the vetting guidelines probably aren't perfect yet; if you can see holes in them, please do submit your points via the public comment system.
Extended validation certificates Posted Nov 2, 2006 22:07 UTC (Thu) by martinfick (subscriber, #4455) [Link] Ahh, the VIP falacy again. Make something a VIP and it is more valuable to fake. You say that it won't be worth it to fakes because it is too expensive. Doesn't that imply that the supposed added trustworthiness of this systems instantly makes it more worthwhile to fake, making bigger phishing expeditions possible?
Extended validation certificates Posted Nov 2, 2006 22:17 UTC (Thu) by gerv (subscriber, #3376) [Link] Yes, EV will be a bigger target if consumers start to trust it (as we hope they will). Then we'll see if the vetting guidelines we've come up with are strong enough. If they aren't, the Forum will revise them until they are.
In the past, there was no standard for CA vetting and so no way to raise standards if there were problems. Now we have a baseline. We hope it's good enough as-is (with input from the community which is coming now) but, if it turns out not to be, we can change it and the CAs will strengthen their vetting.
Extended validation certificates Posted Nov 2, 2006 14:44 UTC (Thu) by kleptog (subscriber, #1183) [Link] I've occasionally wondered if it would be possible to build some kind of "web-of-trust" for certificates. We don't trust the issuer, but I'd probably trust certificates more if someone I know figured the cert was ok.
About the only good part about SSL certs is that they're tied to a domain name, so we should be able to build something on top of that...
Web Of Trust
Web Of Trust Posted Nov 2, 2006 15:20 UTC (Thu) by kleptog (subscriber, #1183) [Link] That puts web of trust at the issuer end, but does nothing for users. For example, I might trust a CAcert certificate to be from who it says, but that doesn't stop the person being a phisher.
The PGP documentation goes on about the difference being trusting the certificate belongs to a particular person, and whether the person is trustworthy in general. It's the latter I want to deal with...
The things I'm thinking of are someone getting a certificate setting up a fake banking site. I would like something to say "this site is from who it says it is, but it's not trusted by other people (and in particular, not by your buddy X)".
Extended validation certificates Posted Nov 2, 2006 23:15 UTC (Thu) by iabervon (subscriber, #722) [Link] The solution for bank sites, at least, is to print the certificate fingerprint on bank statements and ATM cards. Of course, browsers would have to have an interface for users to indicate that they have personally validated the certificate for some particular purpose. If you're using an ATM card provided to you by an attacker, you've got problems already. And this is the only way to stop an attacker with a similarly-named legitimate business as a front (yes, this is a secure connection to a legitimate business's web site, but it's not my bank, so I shouldn't log in). For that matter, I know that there have been multiple legitimate financial institutions simultaneously using the name "Chart Bank"; hopefully, their employees are honorable enough to not take advantage of users who try to log into the wrong one, but who knows?
Extended validation certificates Posted Nov 3, 2006 2:34 UTC (Fri) by pimlott (guest, #1535) [Link] The solution for bank sites, at least, is to print the certificate fingerprint on bank statements and ATM cards. That's absurd, as is the claim in the article that SSL is "meaningless for anything other than an indication that the traffic is encrypted". All the bank has to do is give me an https URL, and I type it in, and I can have quite high confidence I'm talking to my bank. It's not airtight: I could mis-type--though of course I only need to type it once, then bookmark it; and there have been incidents of registrars giving certs to non-owners of domains. But it's practical and I trust it with my finances. Which is not to say that SSL as deployed today is a resounding success--far from it. But suggesting that the padlock is "meaningless" or that users should be checking fingerprints by eye is not productive. The scheme discussed in the article, on the other hand, may be. Let's take the time to look at it and find out.
Extended validation certificates Posted Nov 3, 2006 19:20 UTC (Fri) by bronson (subscriber, #4806) [Link] All the bank has to do is give me an https URL, and I type it in, and I can have quite high confidence I'm talking to my bank.No you can't. DNS cache poisoning is still depressingly easy. And most packets hit 20-30 boxes as they transit the internet. All it takes is for one of those boxes to be subverted. All of these attacks rely on your typing the URL perfectly. Phishing is for chumps. The only way you can be confident you're talking to your bank is to have an out-of-band fingerprint at each end. Each party must authenticate the other. SSL's one way "authentication" will always be prone to MITM attacks, always. I've been meaning to write my SSL MITM proof of concept tool for three years now. That would demonstrate the problem to people who don't have crypto experience. Alas, the round tuits just aren't piling up.
Extended validation certificates Posted Nov 3, 2006 20:14 UTC (Fri) by pimlott (guest, #1535) [Link] How does DNS spoofing defeat certificate verification? Can you give me a concrete scenario that undermines my claim? Assume that I type carefully and double-check my spelling. (I do appreciate that typo-phishing is a serious vulnerability, though.)
Extended validation certificates Posted Nov 4, 2006 1:14 UTC (Sat) by giraffedata (subscriber, #1954) [Link] For those that don't catch what pimlott is implying: As part of https session negotiation, the server supplies its domain name and the browser verifies that it's the same name you typed into the browser. So DNS and IP routing find the server but don't establish its identity in any way.Verisign supplies a certificate that's supposed to convince you that whoever is running the server that claims to be acme.com is the company named Acme. But even if you don't believe Verisign verified that, you probably believe that Verisign didn't hand out certificates for acme.com to two different people, and you know Acme Bank didn't publish that URL until it had a certificate for acme.com in hand.
Extended validation certificates Posted Nov 4, 2006 13:13 UTC (Sat) by kleptog (subscriber, #1183) [Link] Sure, but I can create a certificate on my computer for "acme.com". I can even copy all the details from the real certificate. If I then use DNS spoofing to get people to visit my site, the only way the user is going know the difference is the different fingerprint and the fact that it's not signed by the real verisign.
Most users won't distinguish this from a normal annual certificate change due to expiry.
I think it's the "each certificate has one issuer" that's the real problem here. I have to trust verisign to not give out bad certificate. But why couldn't the local banking regulatory authority also sign each bank's certificate, then I'd be trusting an institution I know (with a legal obligation to not screw up), not one on the other side of the world. Consumer organisations could do this also, then at least I'm placing my trust in something that I know, rather than a company trying to sell for the lowest price.
Extended validation certificates Posted Nov 4, 2006 21:18 UTC (Sat) by giraffedata (subscriber, #1954) [Link] the only way the user is going know the difference is the different fingerprint and the fact that it's not signed by the real verisign. The fact that it's not signed by Verisign should be enough. That will cause the browser to pop up a message saying, "He says he's acme.com, but I have no proof of that. Do you believe him?" Anyone aware enough to check a fingerprint against something on his mailed statement would be aware enough to say, "no way" in this case. Most users won't distinguish this from a normal annual certificate change due to expiry. I never get anything like this, in the beginning or anually, from a website operated by a major company; I don't think others do either. Now I don't doubt that millions of people will blow right past the warning from the browser, having no idea what it means. But all we're claiming in this thread is that a user can make the system work. I have to trust Verisign to not give out a bad certificate That's true, and is discussed in other threads here. But the level of trust you must have in Verisign is very, very small. Imagine the level of negligence or evil required of Verisign for it to sell an acme.com certificate when it has already sold one to someone else.
Extended validation certificates Posted Nov 4, 2006 21:57 UTC (Sat) by pimlott (guest, #1535) [Link] But all we're claiming in this thread is that a user can make the system work.Thank you, giraffedata, for helping explain exactly what I meant.
Extended validation certificates Posted Nov 2, 2006 15:38 UTC (Thu) by dps (subscriber, #5725) [Link] Given the verisign website seemed to suggest at 128/256 bit SSL certificate valid for two year is £949.00 (about $1500), not including VAT, one would imagine only websites with very deep pockets would but a cerficate from them. Maybe those in the US get keener prices. Thawte is more reasonable but still very expensive.
For comparison purposes a comparable from Comodo's install SSL is about £67. If nominet has mispelt your company name you probably have to get that fixed that before you the certificate is issued (FYI the site I have in ming is not accepting credits cards or accessable to the general public).
Of course maybe EV certificates, when they become avaialble, will cost even more.
|
|||||||||||||