Tim Callan's SSL Blog

Wow. A mere two months ago VeriSign announced that fully half of site visitors were EV SSL aware, and now we're already up to 60%.

To what do we owe this ultra-rapid growth? Well, everybody's doing their part, as it happens. Internet Explorer 7 continues its steady replacement of IE6. Google Chrome and IE8 between them are kicking in over 1% of that share as well. But the big winner is Firefox 3, which spiked from under 8% to over 13% in just the last month due to a pushed update to Firefox 2 users.

Today I shot a live segment on online security for San Francisco station KGO's afternoon show View on the Bay. I had a great time. I'm not seeing the segment archived on the site, but maybe it's too fresh. I'll look for it and post it if it goes up.

In the meantime, feel free to enjoy this segment I shot for Las Vegas TV a couple of weeks ago.

Update 10/4: The segment's up at the same link. I just looked too soon after.

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.