EV SSL Certificates - Just once, why can't one of our poorly considered quick fixes work?
PayPal has announced some of its strategies against phishing against their users. Some of this is good stuff and since PayPal is a larger target, they should be commended in taking a proactive role. However, the requirement that browsers using PayPal must support EV SSL Certs and that they must have built-in anti-phishing protection simply do no good. First, an analysis on EV SSL certificates:
EV SSL Certificates - Twice the Effort, 10 times the Cost, No tangible benefit
Extended Validation Certificates are basically SSL certs that require a more detailed background examination of the requesting entity. They require an establishment of a legal identity, that the applicant owns the domain and that all the required documents are signed by an authorized official. In short, it requires the sort of thing that any SSL certificate should have required in the first place. If you think about it, a general SSL certificate should "prove" that you are seeing an authentic website. The reality is, that pretty much anyone can get an SSL cert (for free) without proving anything. The only validation is that the FQDN in the cert matches what the browser says. Net result, attackers buy domains and then gets certs for them, because no real validation occurs. www-paypal.com can get an SSL certificate too that will show up as valid to a user. All an SSL certificate proves is that the URL matches the certificate.
Now comes EV Certs which are supposed to provide that background check that should have taken place before issuing a normal SSL certificate to begin with. Generally, they require the requesting entity to be: a government entity, a legal corporation, a general partnership, a sole proprietorship, or an unincorporated association. This level of "authentication" only makes criminals simply jump through some more hoops... hoops they may have jumped through already (more on that later).
Here is how you can become a legal corporation in less than 24 hours (this is US-Centric, sorry I don't know how to form companies in another nation, but foreign entities can apply for FEINs by fax here). Step one, go to the IRS and apply for a FEIN. You can pretty much enter any values you want here, they just have to pass the smell-test. For instance, create a FEIN for "Al Qaeda in America". (NB, realize you're probably never going to be able to get on a plane in the US again without a thorough prostate exam). You get your FEIN back instantly.
Step two, let's say you want to incorporate in Illinois. Go here to the Secretary of State's website, fill out the form, and you get your articles of incorporation in 24 hours. Congratulations, you are now incorporated and eligible for an EV Cert.
These steps may not be necessary because many spam outfits and other nefarious groups are already incorporated. In short, this process doesn't keep the Internet's bottom-feeders out, it just makes them jump through a few more hoops and toss some cash towards the Certificate Authorities. For that matter, many outright mob outfits are properly organized in the legal sense.
While it is important to note that the list of CAs that can issue EV Certs is smaller than the general list of CAs, I have little faith this will remain so. Many CAs came to be simply to lower the bar to getting a certificate, there will be the same demand to lower the bar to get EV Certs and companies that are willing to service the less-than-honest among us. The bar was lowered once, it'll be lowered again.
So an EV certificate only proves that the website owner can fill out a few webforms, cough up some money, and cough up some more money to pay the CAs for doing the job they should have done in the first place (i.e. verify the identity of the requestor of a cert).
All this said, it doesn't protect against website content that is made to look like another website (i.e. forgery). A user may not see the full green bar, but the content can be made to look and feel the same. Even worse, a normal SSL certificate can still work and display content that is malicious. Or for that matter, a website that isn't encrypted at all. The question remains, is a user able to discern an EV Signed site from other SSL signed sites to know the difference. Academic research indicates that, no, EV certificates make no impact on users spotting fraudulent sites or not.
The purpose of EV SSL Certs - PayPal isn't Using them Correctly
The purpose of an EV SSL certificate is to authenticate a website to a user, period. PayPal, however, is wanting to use EV SSL support as a way of authenticated a user to PayPal. That makes no sense. PayPal has an interest in authenticating people who want to use their service are valid. The presence or absence of EV SSL support in their browser is irrelevant. Does anyone really think that say, the Russian Mob, won't be able to use IE to process PayPal transactions with stolen credentials?
This stance won't, for instance, prevent users from getting keyloggers on their machines to steal the information, being infected with a trojan that will silently process transactions while the user is logged-in, money mules from doing the heavy lifting for malicious individuals, cross-site scripting, or from a user giving up their credentials in a phishing attack to another website. In short, an EV SSL enabled browser proves nothing.
How to Properly Authenticate a User for Online Transactions With Proven Technology
There are already existing and proven ways to authenticate a user for online transactions in a way that mitigates the phishing problem. Many banks do this already as well. Two-factor authentication limits the ability to use stolen information for online fraud (though it does not prevent the trojan problem mentioned above, but neither does EV SSL or "anti-phishing" browsers). Requiring a hardware token to enter another piece of data to send money is something that is shown to work and is economical considering the cost for fraud.
Part of the phishing problem with paypal is the amount of emails they send to their customers and the difficulty of users in determining authenticity. Signed e-mail would help. Reducing e-mail or at least sending email with no clickable links would be better. Both would be great.
Anti-phishing support in a browser proves nothing, there are plenty of fine solutions out there that provide anti-phishing protection. Simply attacking Safari smacks of Anti-Apple bias. And while I'm not fan of the ham-handed way they do security, Mac users simply aren't the phishing victims we need to worry about right now.
Remote Validation of Secure Systems
I have argued that the fundamental problem with phishing, and in fact, all online fraud is the fundamental assumption that consumer PCs can be secured and/or are trustworthy. We need to accommodate ourselves to this fact: consumer PCs are insecure and insecurable. We must treat them as such, just like we treat communication over the internet as insecure and susceptible to interception. This goes back to the absolute necessity of two-factor authentication for "important" transactions and the elimination of typing in sensitive data into a web browser. For instance, the U.S. Department of Education still uses the **Social Security Number** as a **username** to log in to their student loan system. Keyloggers everywhere are happily stealing college students' SSNs and stealing their identities as we speak.
There is a place for remote validation for consumer PCs and denying them access if they are insecure (and I've argued as such). However, simply validating default broswer features is not it. It would be far better to ensure up-to-date AV signatures, up-to-date patches, up-to-date spyware/malware protection and secure OS configuration. Failing any of these, the site in question can provide instructions (or better yet, send the user a CD) to secure and harden their machine.
Basing your security posture based on superficial differentiators provides no real security, and really only creates a headache. This takes work, laziness will only get more people 0wned.
--
John Bambenek /at/ gmail {dot} com
Comments