Slashdot Mirror
Extended Validation SSL, More Secure or Just a Racket?
Nalfeshnee writes "The Register is reporting on the new 'Extended Validation SSL' cert currently being touted by Verisign. Vista and IE7 will be using this but not, apparently, Firefox anytime soon. For this the Verisign Product Marketing Director Tim Callan squarely blames the Firefox dev team for 'not keeping up' with their new technology. However, the whole thing just seems to be a way for Verisign to enjoy ridiculous markup on selling 'more secure' certs."
They couldn't do this with SSL because the user wouldn't know if a certificate comes from a CA which has really checked the identity of the certified company. With Extended Validation, the certificate will contain the information that the CA actually checked, and standardization makes sure that nobody issues such a certificate without checking.
I don't think anybody believes that. It was the CA's job all along to verify the identity before certifying the identity. If the CAs can't do their job for the kind of money that they are asking, who thinks the CAs can and will do it for 150%?
Honestly, I believe that there should be a WC3 conference to contribute a single CA that makes its way onto all browsers. Give the WC3 CA site an automated system for generating certs, including an open API and then combine DNS registration protocals with the CA gen protocals. Publicly open the API, and charge small, if anything. This service is an easy one to implement. The real issue is getting browsers to add it to its automatically trusted CA list. I can create SSL at home, but I can't get browsers to add my home web onto the trusted CA list by default.
Development notes at http://devscribbles.blogspot.com
... is that they are a commercial venture. They will sign just about anything as long as they are paid. I have seen more than one piece of malware signed by Thawte. The whole model of third party commercial CAs is badly flawed in concept. One only needs to pay a CA like Verisign or Thawte to appear legitimate to the average user and then proceed with whatever nefarious purpose one desires.
I trust a self-signed certificate more than one signed by Thawte or Verisign. (I do trust Entrust though, as they are Canadian)
Extended Validation SSL? Is it 256 bit? I think not (what would be the point?). 128 bit SSL is 128 bit SSL regardless of who signs it and how. You must trust the server you are dealing with in the first place, SSL is merely there to make your cummunications with that server private (all the more so if self-signed).
I expect that this "Extended Validation" is an implicit admission that up till now they have been signing pretty much anything as long as they get paid. Even so, it is not up to a CA to assure users that a particular site or application is not nefarious in purpose.
The signing CA model is flawed and very misleading to the average user. I say it does more harm than good.
I mean... since they don't do any verification anyway... and the customer service is terrible... why does it cost hundreds of dollars?
No.
No.
No.
SSL (and TLS) aren't encryption algorithms, they're protocol standards. These protocols make use of existing encryption algorithms to secure data. Many of these algorithms have a variable level of complexity, depending on things like key size. Since security (including encyrption) is always a tradeoff of resources versus security, the goal is to tweak the configuration parameters (again, such as key length) to find a level of security such that an attack against the cipher is less profitable an option than the next best choice, such as kidnapping the document's author. Those who require greater security can use turn up the complexity at the expense of using more resources.
As computation capability increases, the complexity of encryption system is increased to compensate, usually by increasing key length. If a flaw is discovered in a given encryption algorithm making it too easy to break, or if the algorithm isn't capable of being expanded to account for better decryption technology (such as DES) then that algorithm is discarded in favor of some stronger replacement. SSL remains the same.
Verisign's "Extended Validation" program has nothing to do with cipher strength, key length, or encryption. Instead, it's indicative of the vetting process that the company had to undergo to get the certificate. To get a certificate for citibank.net, I have to verify that I own that domain. I don't, necessarily, have to verify that I represent Citibank [1]. Under this High Assurance program, Verisign will vouch, not only for the validity of the domain, but also for the validity of the organization owning that domain.
This is a Good Thing, since there currently is only one tier of validation. An SSL certificate is designed to prevent man-in-the-middle attacks, which it does well. What it doesn't protect against (though we act as if it does) is forged identity attacks. Certificates used for financial transactions, for example, should go through a stronger vetting process than certificates used for securing a blog.
[1] In reality, almost all CAs do extended verification when the other party sounds like a high-profile company or financial institution. Nonetheless, Mistakes do happen.
"With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea...."
RFC 1925
IE7 is harder to change once released
Say again?
Since when has there been any difficulty changing IE once released?
It's just a matter of releasing eleventy-one quadruple bazillion 'security updates' until it is deemed 'just barely functional'...
Has any major IE update been anything else but the last major version with the last bazillion security patches rolled into it, then dotted with fresh new bloat, eyecandy and bugs?
The Hacker's Guide To The Kernel: Don't panic()!
However, they feel just as dumb as everyone else after they've been suckered into paying an extra $1000 for a Verisign Super-duper Whiz-Bang Mega-Ultra Cert.
To be honest there is a difference between a cert from a real CA and some $10 cert from some outfit that doesn't care anything more about your true identity than whether your credit card payment goes through. Google for "high assurance" vs "low assurance".
Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"
It has nothing at all to do with cracking SSL. It has to do with easily getting a certificate bound to an identity and making sure that the user doesn't compromise his private keys thereafter.
You can change procedures for verifying the identity of a person before issuing a cert, that will make it certain that less certificates get issued by the highly trusted CAs. It will help cut down on simple phishing schemes. But it will also turn a lot of businesses to using certs with less stringent requirements, with businesses turning to the CA that has the least hassle and customers getting used to accepting them. For an admin, a tree structured heirarchy gets you into central planning and breadlines when you are trying to get a suite of servers up and running. You may have 15 days to setup 100 servers, and a CA with a 30 day turnaround. This can make things so painful, that the only thing you use a "real certified cert" for is for your external IP addresses.
A good reputation system that understands that reputation can be context dependent and tweaked by the community might be a better fit for the internet.
The technical problems with X509 certs run so much deeper than any of this however.
1) There are no ultimate roots that all users can trust, making a universal set of root CAs problematic. Do you trust the root CA of every country you deal with? As an example: The DoD won't accept anything other than a highly cleared US Government entity, while those outside the US might not trust such an entity for any purposes whatsoever. One of the first acts of setting up a web browser in some military environments is to remove all of the civilian CAs from the "trusted" list.
2) SSL certificates are generally issued as software files, servers generally need to be rebooted unattended, it is bad to have passwords on the filesystem, and finally if a web server gets compromised there is a chance that the software certificate store (with private key material) is now floating around on the internet. These things conspire to ensure that no matter how carefully you identified the identity of the certificate owner, that over the lifetime of the certificate it's very likely that the private key information has been made available to somebody other than the owner. (Ex: import your client software cert into IE at a workstation that you login to, but somebody else administers).
3) Using the common name in the certificate to map to the issued DNS name is a bad hack that attempts to fix the insecurity of the DNS system. Assuming the approach of requiring the hostname to match is used, the certificate securely binds the DNS name to an endorsement from the signing entity; assuming that the owner manages to keep the private key material a secret. A passphrase wont really stand up to a long offline attack once the software cert (PKCS12 or JKS file) ends up in a hacker's database of "certificates that somebody would trust". Using an email address in the common name for client certs has similar problems.
4) You REALLY NEED TO GO TO HARDWARE TOKENS (like smartcards) if you want X509 certs to have anything resembling security. This is ESPECIALLY true with client side certificates. This is because it prevents the user from accidentally spilling the beans - over a period of years over which the cert will be valid. In this case, the hardware token has a set of root CAs that it trusts, with the user generally being limited in managing these trusts for himself. And the user cannot have the private key material permanently compromised because the key material is never exported out of the hardware token to perform computations (into the server's memory, etc.).
5) Certificate Revocation: I have yet to see many using it correctly on a large scale. If you trust ALL of the certificates issued by a CA, then you should check the CRL to make sure that the certificate you are accepting is not revoked (in spite of being valid and not yet expired). A lot of people don't bother keeping updated CRLs
"Technology?" Give me a break. They're looking at what authority signed the cert, and if the web browser has been told to dogmatically trust that authority more than others, then it turns something green.
Actually, it's not a bad idea. There are degrees of trust, and showing it to the user is fine. But you bet your ass this is mostly just a cashgrab from Verisign.
Good news. There's a way to do this, that will absolutely embarrass MSIE, making its version of https look completely insecure by comparison, and screw Verisign over, in the process.
Support an OpenPGP-based cert model (perhaps using GNU TLS library, perhaps not). Suddenly, you can have certs that are signed by multiple authorities, including users themselves, and display a whole spectrum of trust metrics. Equifax can make mistakes and issue an incorrect cert to a bank, but can three CAs all make the same mistake, without a conspiracy? And what if you get the bank's fingerprint on your snailmail statements, or there's a sign showing the fingerprint when you walk into it, and thus you can cert it yourself? What if you haven't ever been to the bank (ok, I can't imagine that) but you have 3 friends who have, and you have certified them, and told your computer they are each marginally trusted, and they all certify the bank? Three friends are sure as hell a lot more trustworthy than some faceless corporation named Verisign, whose identification policies you don't even know, whose private key storage policy you don't even know, and in fact doesn't have a single employee you have even met, assuming they have any employees at all and aren't a robot in the basement of a building at the NSA.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
This is stupid. You're paying EXTRA to have someone do the verification they were supposed to be doing already.
ROTFL...
You mean like pay a mailing/shipping company insurance for them to do their own job?
Or paying extra for an extended warranty? (To guard against stuff that shouldn't be crappy in the first place)
Or paying a credit card company EXTRA MONEY for them to taken YOUR PAYMENT "express" ?
Or paying extra money for a "Service Plan" to get "updates" to bug-ridden software?
Or paying a monthly fee for ambulance service? WTF?!?!!
Sadly, we do live in interesting times... And its only getting more and more "interesting"!