Entrust Certificate Services

In 2005, the longstanding Internet browser trust model, which had served as a foundation for many billions of dollars of e-commerce, was starting to show signs of age. Just like an older building, the model was in need of renovation and repair to its foundation in order to ensure it could continue to support future e-commerce initiatives.

Based on Secure Sockets Layer (SSL), certificates and the ubiquitous padlock icon, the browser trust model was reworked to help renew consumer confidence and to better suit handling e-commerce transaction volumes as they continued to increase.

The new model was defined by a group called the CA/Browser Forum, and consumers first saw the results of their work in January 2007. This paper outlines why the group was formed, what it is working toward and the impact it has on consumers and Web site operators.

In the mid 1990s, Netscape foresaw the need for security to enable the adoption and growth of e-commerce. Creating and embedding the SSL security protocol in their browser and server products was the first step, but the real challenge was building consumer trust.

From the outset, a key or padlock icon was chosen to represent a secure SSL connection, and consumers were told that if the lock was closed, they were dealing with a “trusted” Web site. Whether a site was trusted or not was based on the digital certificate it presented to the browser through SSL. If the server certificate was issued from a Certification Authority (CA) whose root key was embedded in the browser, then the lock would immediately close. A decade and many billions of dollars in e-commerce later, the lock icon has served its purpose well.

While SSL and the padlock icon have served as a solid foundation for many years, some cracks are appearing. Con artists always have searched for ways to exploit the learned responses of their fellow humans and the Internet has brought with it many new opportunities. With varying degrees of sophistication, examples have appeared where consumer trust of the lock icon has been abused. In one exploit, a server certificate was acquired under false pretenses to give a phishing Web site extra credibility as it attempted to steal usernames and passwords.1 In other potential exploits, fake lock icons are embedded directly in the Web pages using simple graphics or more sophisticated active code to lull users into a false sense of security.

What Is Being Done to Fix Browser Trust?

To bolster consumer trust in the foundation of e-commerce before it is irreparably damaged, several Certification Authorities and browser vendors have come together to establish a higher security approach based on common standards. The CA/Browser Forum has created a new tier of SSL certificate with very high standards for validation and assurance, and is also exploring browser security user-interface elements (e.g. colors, padlock location) and behavior.

The new certificates were referred to by different names as they were being defined — ‘High Assurance’ and ‘Enhanced Validation’ were considered — but ‘Extended Validation’ was the final name chosen by the CA/Browser Forum. It is important to note that these certificates are still fully compliant with the X.509 standards and are backwards compatible with older browsers.

Now that these new validation processes are in place, all CAs will use the same highly rigorous checks before issuing one of these new SSL certificates, and browsers detecting one of these certificates at a Web site can reflect the higher trust level in the user interface.

SSL Certificates Before Extended Validation

Using certificates in SSL is based on public key cryptography. This paper won’t attempt to explain public key technology in detail, but at a high level the Web server needs to create a mathematically related pair of keys — the private key and the public key. The public key portion of the pair is then put into an electronic document called a certificate and signed by a trusted CA. For SSL server certificates it is important that the Web server’s domain name (e.g., www.company.com) be present in the certificate, otherwise browsers will warn users that they may not be on a legitimate site.

From a human perspective, the Web server administrator begins this process by issuing commands in the Web server to generate the keys and to create a “Certificate Signing Request,” or CSR. The administrator then submits the CSR to the CA, generally submitting it through a Web page. Workflow then begins at the CA to validate that the certificate can be issued as requested. Before Extended Validation, requirements varied significantly between CAs, without an easy way for consumers to distinguish certificates issued using more- or less-rigorous validation processes.

Some CAs are still willing to issue certificates after simply checking that the requestor controls the domain name requested. This is accomplished by sending an automated e-mail to the administrator e-mail address listed in the Internet registry for the requested domain name. The approach is very fast and convenient for both CA and for customers, but it introduces some risk in that spoofers can register a domain that looks very similar to a target domain. Harvard Researchers demonstrated this risk and documented their findings.2

Source: http://people.deas.harvard.edu/~rachna/papers/why_phishing_works.pdf

What’s in a name?

The purpose of a certificate is to assign a key to an individual key-holder’s name. There are many forms of name in common use. Some are unique, and others are shared. Some are meaningful, and others are meaningless. By virtue of the way they are assigned, domain names are unique but meaningless. Certificates that bind a key only to a domain name do offer some protection against such attacks as HTTP response-splitting and ISP eavesdropping. However, these are relatively uncommon. The most prevalent type of attack today, of course, is phishing. Domain-name-only certificates offer little or no protection against this type of attack.

Most CAs will check a business’s credentials in more detail before issuing a certificate, but there are discrepancies in the level of rigor applied. Some CAs simply accept faxed copies of a company’s utility bill.

Other CAs, like Entrust, have been more rigorous from the outset and will not accept information provided by the requestor at face value, instead looking up company registration information in trusted databases. They also will typically verify that the individual requesting the certificate is properly authorized by the organization by initiating phone calls to listed numbers for the company.

This inconsistency of validation processes between CA vendors was one of the key focus issues for the CA/Browser Forum.

Impact of the New Extended Validation SSL Certificates

The new certificates have the highest impact on consumers, reassuring them that the site they are visiting is legitimate through visual cues in un-modifiable parts of the browser interface “chrome.” For example, Microsoft Internet Explorer Version 7 (IE 7) shows a green background behind the address bar for sites protected by an Extended Validation SSL certificate. IE 7 also displays the corporate name and the name of the CA (e.g., Entrust) in a scrolling user interface (UI) element beside a more prominent padlock icon.

Sites without Extended Validation SSL certificates simply have a white background as before. Sites with invalid certificates, or that are known to be malicious, cause the address bar to turn red.

It is expected that these prominent UI changes will become widely accepted and expected by consumers, providing organizations with a new tool to show customers that they take security and privacy seriously.

Web site operators will notice differences in the amount of information they need to provide to CAs during the initial validation process. Although certificate validity periods are now limited to two years, Web site operators using these certificates may notice that their information is revalidated by their CA after 12 months. Wildcard certificates are no longer acceptable, and for deployments with requirements to protect multiple hostnames with a single certificate, each hostname will need to be included in the certificate using multiple “subjectAltName” attributes.

Certificate revocation checking will be active by default in many new browsers. This will allow a CA to react to a problem by revoking a certificate that, in turn, enables browsers to detect if a certificate is no longer trustworthy. Past versions of browsers have been inconsistent in their implementations and default settings for revocation checking.

Extended Validation Is a Reality

The CA/Browser Forum was formed in May 2005 and has been driving toward consensus since that first meeting. Efforts to extend the scope of Extended Validation SSL certificates are continuing, but the value of Extended Validation SSL certificates is a reality today for users of Microsoft’s Internet Explorer 7 browser — estimated at almost 30 percent3 of the browsers in use as of March 2007. Makers of other popular browsers have made statements on availability for various dates in 2007. Entrust has had Extended Validation SSL certificates available since January 2007.

What Can I Do Now?

Entrust customers who wish upgrade to Extended Validation SSL certificates can do so today, with minimal changes to their existing procedures. Customers using large numbers of Extended Validation SSL certificates should consider switching to the Entrust Certificate Management Service in order to benefit from streamlined validation and the flexibility of the subscription approach to certificates.

For the latest information on this topic, please visit www.entrust.net/ev.

top