EV-SSL, SSL, And Who’s Not Using It
It seems I've been picking on EV-SSL lately. It's not intentional; I just have encountered a lot of questionable marketing fluff lately and wanted to talk about it. Today is no different. Tim Callan's recent blog post got me thinking. Basically he referenced some SSL attacks that were disclosed at BlackHat, and suggested EV-SSL certificates as the cure to SSL MitM attacks and phishing in general. On the one hand, I believe his conclusion is conveniently aligned with his employer's sales agenda. On the other hand, I acknowledge that EV-SSL could raise the bar...if it's adopted and deployed in widespread fashion. And therein is the crux.
I've previously talked about the EV-SSL adoption rate (or lack thereof) in this blog. NetCraft has reported its findings of one million valid SSL-capable sites are in use (note: sites with invalid, self-signed, or expired SSL certs are not included in that count). And while I don't have access to their commercial SSL Survey report for January 2009, we infer from some third party mentions that the report states around 10,000 EV-SSL sites were found. That's 3,000 more than Verisign mentioned last month, but perhaps Verisign was only reporting what they alone issued. Given their marketshare (~75%, albeit that number is a year old) against total EV-SSL cert vendors, that seems to make sense.
Only 10,000 EV-SSL sites within two years seems very low to me, especially for something which is essentially an enhanced derivative of an already understood and accepted technology. People already know what SSL is and what function SSL certs perform, so that definitely is not the hold up. There just doesn't seem to be much of an adoption momentum, and maybe that's because the additional value these premium EV-SSL certs provide is questionable in the eyes of site owners.
But maybe I'm looking at this wrong. Only 10,000 EV-SSL sites seems a bit low, but what if they were 10,000 sites that matter? I suppose that would paint a different picture. If 10,000 big sites that account for a notable portion of the web's traffic used EV-SSL, I suppose that actually might not be so bad. So I entertained that theory. I manually surfed to each of the upper 50 of Alexa's Global Top 500 Sites list, and recorded who was using EV-SSL vs. normal SSL vs. no SSL. The idea is that these sites represent the most visited sites in all of the world (according to Alexa), and as such, assumingly have a vested interest in assuring their voluminous user population that the users' accounts and transactions are secure. If most of these sites were using EV-SSL, then that would actually provide notable EV-SSL permeation into overall web traffic.
The process I used was simple: visit each of the Alexa-listed sites (the top 50), surf around to find a 'signin' or 'signup' form or other equally-sensitive use of HTTPS, and then watch if the URL address bar in my Internet Explorer 7 browser turned green when SSL was utilized. A green bar meant EV-SSL; no green bar but still having a valid lock icon is standard SSL. I found that only two sites (ebay.com and login.live.com) were using EV-SSL. That's it. Just two. All of the other sites were using standard SSL, with the exception of ten sites that don't use SSL at all with their login forms (youtube.com, hi5.com, mail.ru, photobucket.com, vkontakte.ru, imageshack.us, friendster.com, skyrock.com, odnoklassniki.ru, and dailymotion.com) and two more that don't really receive sensitive info from the user and thus don't necessitate SSL (bbc.co.uk and cnn.com).
We might label that a bleak picture. Ten of the fifty top sites (20%) don't even use SSL for their logins. Only two use EV-SSL. I was a bit surprised to see the online retail giant, Amazon.com, didn't use EV-SSL. If EV-SSL was a sure-thing to lead to better customer confidence and more online retail conversions, I would have figured they would have been all over it. They would not be one to overlook a technological advantage if the ROI helped their bottom line...that is, after all, how they got started. And given that they store credit card data for quick purchasing convenience, there is a certain financial value to compromising someone's Amazon account; I’m surprised it hasn't been the target of more phishing attacks to date.
Also surprising was Yahoo (login.yahoo.com), AOL (my.screenname.aol.com), and Google (www.google.com) all use standard SSL for their common backend authentication sites. These vendors offer multiple different web services, but tie it all back to a single authentication mechanism, much like a Single Sign-On (SSO) platform. And aren't some of these vendors OpenID providers? That means a successful phish of a single account could be leveraged across many sites/services, even outside the realm of just these vendors. On Microsoft's live.com site, I found that the login form (from login.live.com, which was presented over HTTP by default but did include a link to switch to HTTPS) did go to an EV-SSL site once submitted, but the signup page (signup.live.com) was handled with a standard SSL cert. Maybe they just want to discourage new signups while assuring existing accounts it's safe to login.
But here's another thought: maybe these sites have invested in standard SSL certificates before EV-SSL was popular, and just are waiting for their current certs to expire before renewing with EV-SSL variants. That seems plausible, but the results are a bit mixed. Google renewed their current standard SSL cert in May 2008 and signup.live.com was renewed in November 2008. That was fairly recent, and definitely after EV-SSL was well established. Opposite that, AOL's my.screenname.aol.com certificate was issued in March 2007 and Yahoo's is from January 2006; it's arguable they were issued before EV-SSL really caught on. So it's hard to say, but the thought might hold true for some cases. Certainly not others.
But again, maybe I'm still looking at it all wrong. EV-SSL might only make the most sense to certain verticals, like online banking sites. The Alexa list doesn't really have any bank sites in their top 50. So I did a spot-check of some big bank site URLs pulled from the top of my head. Of all the ones I tried, only BankOfAmerica's login site (which is separate from their normal site) used EV-SSL:
- www.bankofamerica.com: standard SSL (renewed December 2008)
- sitekey.bankofamerica.com: EV-SSL
- www.wellsfargo.com: standard SSL (renewed June 2008)
- online.wellsfargo.com: standard SSL (renewed July 2008)
- www.chase.com: standard SSL (renewed August 2008)
- chaseonline.chase.com: standard SSL (renewed April 2008)
- online.citibank.com: standard SSL (renewed December 2007)
- www.us.hsbc.com: standard SSL (renewed July 2008)
- myonlineaccounts2.abbeynational.co.uk: standard SSL (renewed February 2009**)
That last one is very interesting. Abbey National Bank has been a notable target of phishing attempts going back a year. And yet, when they renewed their SSL certificate last week (February 12, 2009), they went with a standard certificate instead of EV-SSL. Whether they didn't know or didn't care that EV-SSL could help assure users against phishing, I don't know. But if a bank that's been phished for over a year doesn't decide to buy into EV-SSL when it has the convenient opportunity...who will? Marketing fluff aside, that is probably the absolute best-case realized application for EV-SSL ever. User accounts have access to monetary instruments. The site has been an active target of phishing attempts for over a year. They needed new SSL certs anyway. Any one of those reasons by itself is (supposed) ground for EV-SSL, and they had all three reasons. Oh well, maybe they're reconsider EV-SSL in 2010 when their new cert expires.
**Postscript: it seems Abbey National Bank's site uses a cluster of SSL web servers that have different SSL certs installed. In some cases, I connect to a server that gives me an SSL cert that was issued on Feb 12 2009. On other occasions, I get connected to a server that gives me an SSL cert that expires on Feb 24 2009 (i.e. next week). So apparently they have currently upgraded the SSL certs on some of their servers, but not all. I just wanted to mention this in case you were poking around yourself and noticed the discrepancy. Here is a screenshot of the newer SSL cert, to prove I'm not making stuff up: