Browser Certs Can't Force Adherence

Consumers and enterprises alike are rightly concerned with privacy and security when conducting business on the Internet. Without the familiar setup of the brick-and-mortar world, it's difficult for users to judge the validity of Web sites with which they do business.

Extended Validation certificates, developed by the CA/Browser Forum, are intended to allay some of those concerns by certifying sites that are valid business entities.

The CA/Browser Forum's EV certificate guidelines standardize the scrutinization of certificate applicants and require EV CAs (certificate authorities) to pass a "WebTrust for CA" audit. And EV certification is making its way into the mainstream; the CA/Browser Forum's EV guidelines aren't final, but Microsoft's Internet Explorer 7 already supports EV certificates.However, because of some basic weaknesses in how digital certificates are used on the Web, EV certificates will do little to improve the strength of SSL nor will they signify any meaningful trustworthiness of the site presenting the certificate.

Security Signals

The familiar attributes we use to assess trust in a business--such as its location, our impression of the owner or the employees, and the appearance of the store or building--are missing on the Web. Anyone, including criminals, can create a professional-looking Web site. The visual appeal of a Web site is not an indicator of the owner's intent. The only visual signals of a site's trustworthiness are the "https://" that prepends an SSL-enabled site and, if transmissions are encrypted, a golden lock located somewhere in the browser window. That golden lock means that as long as the SSL negotiation between the server and browser wasn't subverted, your session is protected from prying eyes. But neither mechanism indicates whether a Web site is run by a valid company. In many cases, SSL certificates can be issued to anyone with an address and a business license, both of which are easy to get.

Prior to EV certificates, there were no agreed-upon ways that CAs validated certificate requestors--or even validated that the requestor owned the domain name it was seeking to secure. CPSs (Certification Practice Statements) define how a certificate authority issues and manages certificates, but CPSs vary from CA to CA and even within a single CA. The CA/Browser Forum's EV certificate guidelines standardize CPSs.

A CA that wants to issue EV certificates must first pass a "WebTrust for CA" audit of its security practices; it must follow rigorous guidelines concerning the operation and management of the approved EV certificate. EV certificates will be granted only to legally incorporated organizations and government entities. Sole proprietorships, general partnerships and individuals need not apply.

To apply for an EV certificate on behalf of your company or government agency, you must gather the necessary information for a request. Make sure your information is current and consistent; your domain name registrar contact information, for example, should match your corporate address or place of business, and information about your company's contact person should be current.

The EV guidelines contain a laundry list of requirements that CAs must follow before issuing an EV certificate (see "Extended Validation," right). The CA must validate that your company is incorporated as a legal entity, has a physical location, is engaged in a business activity, and has exclusive rights to the domain name included in the request. All that verification accounts for the relatively high list price--$850 to $1,500 for one year--of an EV certificate compared with regular SSL certs, which range from $80 to $1,000 for one year. Multiyear contacts usually bring discounts.

Continue Reading This Story...

Subversive Forces

While setting up an SSL session, the Web server sends a digital certificate to the browser identifying the Web server. The Web browser validates the certificate by checking that the name in the certificate matches the Web server's domain name, the certificate hasn't expired, the certificate is signed by a CA whose root certificate is built into the browser, and a few other things. If all goes well, the SSL session is established. In the case of errors, browsers pop up dialogs asking if you'd like to continue. If users don't pay attention to the dialog boxes, they can end up loading pages that are clearly warned as being problematic. Due to the relative complexity of how CAs operate, software developers' propensity to display cryptic (to the uninitiated, at least) messages in dialog boxes, and the Pavlovian conditioning of users to click "OK" on any dialog box that pops up, criminals can trick users into thinking they are connecting to an authentic Web server rather than a fraudulent one.Web browsers, such as IE7, Opera and future versions of Firefox, indicate, using a green address bar and other visual cues, when an EV certificate has been sent. Clearly, the hope is that users will associate green with "good," but there is no sign users will give up the habit of automatically clicking OK on dialog boxes, so even with EV certificates, it's likely fraudulent sites will stay in business.

Revocation Flaws

Besides the issues surrounding usability weaknesses, there are other flaws in the use of certificates, and EV certificates don't address these flaws well enough. A digital certificate has a corresponding private key that is used for cryptographic functions by the Web server. If that key is stolen, the thief can easily impersonate the Web server. Although we're not aware of any cases where a private key has been stolen and used, the threat is real. Defrauding a CA may be easier. In January 2001, VeriSign issued two code-signing certificates to imposters representing Microsoft. VeriSign discovered the problem and Microsoft had to issue a patch to revoke the certificates because certificate revocation wasn't readily available.

The CA/Browser guidelines require CAs maintain revocation data but don't require browsers to validate certificates against the revocation data. This is a critical oversight: If a secret key bound to a certificate is compromised or a CA mistakenly issues an EV certificate, the quickest way to indicate that is through revocation and certificate validation. We do note that while using IE Version 7.0.5730.11, we could get a green bar while perusing https://www.overstock.com, only after we manually enabled certificate-revocation checking.

The CA/Browser Forum's position as to why it doesn't require certificate-revocation validation is that it would put an undue burden on the directory distributing revocation data to clients. The preferred method, called stapling, is to send revocation data to the EV certificate during the SSL negotiation. The CA/Browser guidelines do require EV CAs to maintain revocation data, but revocation validation is not required until a majority of Web servers support RFC 3546 TLS Extensions, which include an extension for the server to send its revocation data with its certificate, or digital certificates are issued after Dec. 31, 2010. However, that pushes the integration burden from the Web client to the Web server because the server will have to query an OCSP (On-Line Certificate Status Protocol) responder for validation data. Not requiring server certificate validation is an oversight that truly reduces the value of EV certificates. n

Mike Fratto is a senior technology editor based in Network Computing's Syracuse University Real-World Labs. Write to him at [email protected].