Tim Callan's SSL Blog

I'm very pleased that the ranks of the VeriSign bloggers have recently been joined by VeriSign SSL product marketer Bob Angus. Bob shares the insights from more than twenty years selling and marketing Internet and software products, including a wealth of experience in e-commerce enablement. Bob describes the Ecommerce Evangelist blog this way:

The Ecommerce Evangelist is about what our customers do.

• It's a blog about how Internet retailers drive more customers to their door and effectively convert clicks into sales.
• It's about why effective marketing can attract new customers and can help them come back again and again.
• It's about who the leaders are today and how they are shaping the future of transactions tomorrow.
• It's about what you do everyday. It's about Ecommerce.

So, if you make money online, this blog is for you.

Bob looks like he's already off to a strong start. His most recent entry is Three of the 24 Tactics You Can Do to Make More Money Next Week.

As you may know, lots of online businesses have measured the results of putting Extended Validation SSL on their sites and have universally found that it increases the propensity for site visitors to complete sensitive transactions. With so many measurements of EV's effect (I am aware of seventeen such tests, personally), we have decided to gather as many of them together in one place so that it's easy to take in the science all at once. The SSL case studies are here.

Regular readers of The SSL Blog will know that Opera 9.5 supports EV and has supported the VeriSign root from the very beginning. Well, Opera 9.5 now contains native support for GeoTrust and thawte roots as well.

After a year and a half of people asking me the question, I'm happy to state that the company Amazon.com is using both Extended Validation SSL and the VeriSign Secured Seal in production. In particular Amazon has chosen to roll out these confidence enhancers first on its Amazon Sourcing page. My conjecture is that this page is for vendors who provide goods or services to Amazon.com, the company. I wonder if the public facing stores are to follow.

Apologies for pointing to kind of an old article, but this article goes into depth on how Firefox 3 handles errors with SSL Certificates. These errors include such things as domain name mismatches, expired certificates, and untrusted (e.g. self-signed) roots. The comments on the article also include a lively and intelligent discussion of the issues surrounding self-signed certificates.

I mentioned that I recently gave a Web seminar with some lively questions at the end. I'll present some of the questions I received, with my responses. Because I received so darn many questions, I'll break this one into multiple postings.

Q: If EV is so far ahead of standard SSL (in terms of security/authentication), do you think the PCI industry will mandate EV in near future?

A: I certainly hope so. EV is a definite improvement to a consumer's ability to protect herself against credit card theft, and the PCI standard is all about reducing credit card theft. It's not only in the interest of the consumers but also in the interest of the issuing banks, who usually are the ones that wind up eating bad credit card debt.

Q: What is the cost of implementing EV?

A: Costs break into two pieces. The first is the cost of the certificates themselves. EV certificates are more expensive than standard certificates because the certificate issuer needs to support an entirely new authentication and auditing process. You can see the prices for VeriSign EV SSL Certificates here.

The second cost is the project itself. For whatever services you plan to roll out EV certificates, you will need staging and QA, possibly some development, and eventually installation and rollout of the new certificates. Each organization needs so size this project for itself.

Q: How much more secure is Extended Validation SSL as opposed to old-style SSL?

A: Let's be clear that the security advantage of EV SSL is in its defence against social engineering attacks like phishing. All of the classic PKI features of the certificate (encryption, revocation checking, expiration management, etc.) are the same as standard SSL.

It is important to note that wildcard certificates and durations longer than two years are disallowed by the EV standard because they're considered to be less secure from a PKI perspective.

Q: What prevents the hacker or malware to copy the EV padlock & name of the company in green color on the right side of URL?

A: That area is controlled by the browser, so presuming that the hacker is copying the green address bar and other EV interface conventions into the browser is tantamount to saying that the operating system on that client has been compromised. Well, once we're able to modify the behaviour of a client system without the user's knowledge, then there are much easier ways to steal information than setting up spoof sites and sending out spam e-mail and creating false green address bars in hopes of collecting information. At that point all you need to do is put a key logger on the client system and steal the information users enter when they go to the real sites where they really do have accounts and do business. I find it hard to believe that a purveyor of malware will go to all of the trouble of modifying the OS to show green address bard on the site when that same purveyor need merely use the tried-and-true keylogging capability that has existed for years.

As promised I've looked a little more into the SSL behaviors in Chrome.

Chrome has a nice, strong interface regarding certificate errors. The browser presents a roadblock that you have to explicitly pass to access the page (similar to recent developments in, let's say, IE and Firefox), at the bottom of which you see two buttons, "Proceed anyway" and "Back to safety". If you select "Proceed anyway," then you can access the page, but now the https in the Web address is highlighted in red and has a red slash through it, and that reminder remains even while you're in the page. eWeek's Larry Seltzer has screen caps of a self-signed certificate so that you can see for yourself.

I feel the persistent indicator is a good innovation. Chrome makes it unambiguous that you're choosing to live with a certificate error, and it keeps a persistent reminder of this error on the screen while at the same time allowing access in case you need it.

I checked out domain mismatch (e.g. the cert is issued for www.mysite.com but is sitting on secure.mysite.com) and untrusted root and saw similar behaviors for each. The message for domain mismatch reads,

This is probably not the site you're looking for! You attempted to reach secure.mysite.com but instead reached the server identifying itself as www.mysite.com. This may be caused by a misconfiguration on the server or by something more serious. An attacker on your network could be trying to get you to visit a fake (and potentially harmful) version of www.mysite.com. You should not proceed.

And then the same two buttons as in the previous example. I'm guessing we'll see the same for an expired cert, but I don't have one handy to look at. If anyone out there has looked at Chrome on an expired cert, let me know what you saw.

Next I'll cover how Chrome treats mixed content security (i.e. SSL-encrypted and -unencrypted content on a single page).

If you've been camping in the mountains or something you may not have heard that Google will be releasing its own browser, Chrome.

As you might expect, I was instantly curious about how Chrome works with SSL. These are quick and dirty preliminary results, but here's what I have for you today.

Chrome appears to work with SSL in the expected manner. When SSL is in place, the address bar still displays https, and a lock icon appears next to the address bar.

Chrome also recognizes Extended Validation SSL Certificates. The beta recognizes the VeriSign EV root, at the very least. Google does display the organization name to the right of the URL and highlights that name and the https indicator in green. It's a very consistent adaption of the IE7/IE8 EV experience into the light interface to which Chrome aspires.

I'm getting confirmation on this fact, but I think you have to enable revocation checking in the beta before Chrome will detect EV certs as such. The revocation checking requirement is a good one. I hope that in later betas Google will change the default to on, just as Microsoft did with Internet Explorer 7. If you need to turn on revocation checking, this Google tech note explains how.

I haven't had a chance to check out what Chrome does with self-signed or other untrusted roots or with certificate errors such as domain mismatches and expired certs. My hope is that the browser will handle all these scenarios properly, and if it doesn't in this beta that it will shortly. I'll look into these behaviors and let you know what I find out.

Another paper that's oft cited by those who want to discredit Extended Validation SSL was published soon after the release of EV SSL at the beginning of 2007 and is titled "An Evaluation of Extended Validation and Picture-in-Picture Phishing Attacks," authored by Stanford student Collin Jackson.

The Jackson paper is frequent link fodder, usually for bloggers who want to prove that Extended Validation SSL is not the considerable step forward in Web security that the community at large perceives it to be. Typically the link accompanies some broad statement like, "These certificates have been shown not to work." Indeed, if you read the paper's abstract, it appears to back up that claim,

Across all groups, we found that picture-in-picture attacks showing a fake browser window were as effective as the best other phishing technique, the homograph attack. Extended validation did not help users identify either attack.

Before we can draw that conclusion, however, let's look at Mr. Jackson's paper a little more closely. The results reported in this paper are meaningless for the simple reason that the data set is so small that the margin for error far exceeds the results to which we're supposed to be attributing significance.

We recorded a couple of good Web seminars recently on the subject of Extended Validation SSL. I had the privelege to give the first to over 500 security professionals. In addition to boiling the basic EV story down to a half hour, it also contains an excellent Q& A session.

The second was run by my compatriot Ryan White, and what's special about this seminar is it has a special guest visitor, Darren Shafae, vice-president of Proof-Reading.com. Darren offers the unique insights of an online business that has chosen to go with EV SSL.

Chinese megabank ICBC has deployed Extended Validation SSL. The Forbes Global 2000 lists this bank as the 42nd largest in the world and the largest in China. This deployment is noteworthy because it illustrates that EV SSL is a worldwide phenomenon and not just something for North America and Europe.

The Street picked up some tips I published for people to protect themselves online. That fact got me reading the article originally, but what I want to call your attention to today is the other half of the article, which details some interesting research implying that online banks commit an awful lot of errors that enable phishing against their customer bases. States the article,

The study found that of the 214 U.S. financial institution Web sites that were analyzed, 76% of them had at least one design flaw which could compromise your financial data.

Unlike many studies that focus on the vulnerabilities of the coding of the Web sites, where hackers may be able to gain access to information, this study focused on design flaws of the banks' sites that made it easier for users to be tricked into giving up private information (phishing). The flaws include placing log-in boxes and contact information on insecure Web pages (47% of banks), putting contact information and security advice on insecure pages (55% of banks), redirecting customers to a site outside the bank's domain for certain transactions without warning (30% of banks), emailing security-sensitive information insecurely (31% of banks) and allowing easy-to-guess user IDs and passwords such as Social Security numbers or email addresses.

The first of these topics (placing logins on pages that are not secured by SSL) is a personal pet peeve of mine and something I've written about in the past. Fortunately it's getting better, and many online banks are correcting this bad behavior, but clearly based on this research many have not. I will dig into the research in more depth and give you a summary of what it says and my commentary on it.

It's a busy week for VeriSign announcements. Two days ago we announced our support of IDN on SSL. Yesterday we announced VeriSign code signing for the Adobe AIR platform.

Yesterday VeriSign announced that VeriSign-branded SSL Certificates now support IDN. For years I have told people that IDN stood for International Domain Name, but in preparation for our press release on this topic, I have learned that the actual term is Internationalized Domain Name. Go figure.

Anyway, IDN support means that a Web site can use character sets beyond the standard ASCII in its domain name. So you could use an umlaut or a Kanji character, for example. In the long term IDN affords the opportunity for non-English Web communications to have a truer experience by using the native alphabet in domains. One of the elements that's necessary is for sites to be able to secure themselves when these domain names are in use, and VeriSign is ready to do its part in that regard.

As alluded to in a previous post, I'm just home from another of those gonzo road tours, five cities in ten days in this case. On this particular tour I had face-to-face meetings with about twenty large online businesses, gave two industry conference presentations, met with several journalists, and stopped in to visit my grandmother. Grandma's doing fine, thank you, and enjoying the heck out of the Olympics.

I've been speaking on behalf of EV SSL for about two years and at this point have discussed the new technology platform in person with several hundred leading online businesses across a variety of segments, and for the most part I find them to be rational and coherent in their evaluation of Extended Validation and the opportunities it might offer to their performance online. However, once in a while I run into someone whose thought process is quite simply off, a fact that doesn't help a business optimize its bottom line. Some consistent errors have emerged over time, and I experienced four of the common ones on this last trip. So while they're fresh in my mind, let me tell you about them.

Evaluation fallacy #1: "I'm in a debate."
This fallacy is far and away the one I run into the most. As someone who has been continuously engaged with this technology just about as long as anybody in the world, I have accumulated a wealth of research, anecdote, and best practices surrounding EV SSL. I view my role in the customer conversation to share this knowledge as efficiently as possible in order to assist the online business in evaluating its own approach to EV SSL. I try to facilitate the decision process not just about whether or not to add EV to a site but also about how, where, and when to add EV for maximum effect.

Most businesses get it. They understand that they have a resource here at their disposal which will share everything he has to help them work through the process and come to the unique, optimized decision for that business. However, I occasionally run into somebody who seems to view his mission in this interaction to be argument, someone who doesn't use me as an information source but rather seeks to attack the information that I have, to somehow prove it false.

These conversations often still prove useful to the online business, but they're terribly inefficient and disorganized along the way. Rather than seeking to understand the strengths and limitations of the available research and the experience of other businesses, in this flavor of conversation, the evaluator will do everything he can - sometimes to the point of absurdity - to prove to himself that these facts don't apply to him. Even if they apply to everyone else in the world.

It's a poor process for finding the true opportunity in a new technology paradigm. That's because it doesn't depend on the actual facts of the matter (e.g. EV will drive business performance that will ultimately be highly valuable to the site) but rather depends on one individual's (Tim's) ability to engage in successful verbal swordplay. If I happen to be tired or suffering from a head cold or unusually stupid on the day that I engage in this conversation, the conclusion will be different. But the actual underlying facts of the matter are the same. So that means this method of evaluation is less likely to result in an optimized outcome.

Why they do it I don't really know. But I recommend to you, the reader of The SSL Blog, that you do not fall into the same trap. Dispassionately and openly gather the information available and make whatever decision is best for your business. And then reap the rewards.

Evaluation fallacy #2: "I won't benefit until my competitors have it."
I hear this one a lot, too. "Sure Tim, I see that many online businesses have tested EV SSL and seen without exception that it increases transactions. But my main competitor is PopularCartoonCharacterWatches.com, and it doesn't have EV, so there's no point in putting EV on my own site, WellKnownCartoonCharacterWatches.com. I'll just wait until my competitor has it."

I am always amazed by this line of reasoning. In the above example we're discussing an online retailer, but the fact is that most online businesses that bother with SSL at all are better off if they drive more transactions and reduce abandonment. If you're better off, you're better off. Why would anyone in her right mind let a competitor's action prevent her from taking advantage of an obvious business opportunity? If your competitor started sending big boxes of poo to its frequent customers, would you run out and start sending poo to your own customers as well? Then why would you allow your competition's shortsightedness to force you into shortsightedness too? Seems like a pretty self-destructive business practice to me.

Furthermore, this approach misses the opportunity to get a leg up on the competition. If I wait for my chief rival to institute every improvement before I do, then my chief rival is always the leader, is always enjoying a competitive advantage over me, and is teaching customers which vendor consistently has the best service - and that someone ain't me. Again, why on Earth would any right thinking individual choose such a detrimental course of action?

Evaluation fallacy #3: "I can't afford to be an early adopter."
I've listed this one as a fallacy for the simple reason that it's too late to be an early adopter. Major sites like eBay, Charles Schwab, Travelocity, and Overstock.com had EV on their sites more than a year and a half ago. Today over 7000 online businesses use EV including leaders in every major vertical such as online retail, banking, financial, health care, insurance, education, and government.

I hate to be the one to break it to you, kids, but the early adopters have already adopted. This technology is in the mainstream now, and the businesses who are working on their EV plans at this point should expect to be in the high part of the bell curve. Businesses who don't have concrete EV plans are at grave risk of becoming the laggards. So the real question to ask now is not "Can I afford to be an early adopter?" but rather "Can I really afford to be a technology laggard?"

Evaluation fallacy #4: "I think..."
Everyone has an opinion, and in our egalitarian society we are trained to treat all opinions equally. I consistently run into people whose opinions have no basis in the relevant information that's available. The statement typically goes something like, "I don't think people will really care if they see a green address bar" or "I think most of my site visitors aren't on the browsers that recognize these certificates as EV certificates."

If we both knew the same individual and wondered how tall he was, would we say things like "In my opinion he's over six feet tall" or "In my opinion he's under six feet"? I dare say we would not. We'd measure him, and then everyone would know. It's not a matter of opinion; it's a matter of fact.

I suggest that we stop discussing our unfounded opinions about matters of fact when the facts themselves are available. We happen to know how the specific customer bases of seventeen online businesses have changed their behavior when presented with green address bars (hint: they abandoned considerably less often). We happen to know what percentage of client systems in the world use which versions of browsers (hint: more than half of client systems today are EV-compatible), and it's a trivial matter to find out the specifics of the traffic for any given site.

So don't be lazy. Go get the facts.

In conclusion
Remember, you're making a decision that has a real impact on the performance of your online business. By increasing sales or signups or customer satisfaction or brand perception or customer service efficiencies, you're materially affecting your business for the better. You're making more money or saving more money or retaining more customers. These are the things that cause shareholder value to go up and small business owners to take home more cash in their pocket. These are the things that cause people in larger organizations to get bonuses and promotions.

The stakes are real. The stakes are high. You have the opportunity to skew the odds in your favor by avoiding the common errors detailed above. Rational intelligent people will take advantage of that opportunity. Will you?