This week Mozilla, and all updated their browser blacklists to include a list of fraudulent certificates issued for the following URLs:


These SSL certificates were issued by a Registration Authority (RA) affiliated with (and trusted by) Comodo, which claims that access to the RA was compromised and a user account was breached. They claim that this RA account was fraudulently used to issue 9 SSL certificates for the URLs above. They also claim that the attack originated from Iran.

Although these fraudulent certificates were revoked, many end users were still exposed to risk. Why? Because the technology that make sure revoked certificates are not mistakenly validated are either turned-off or entirely missing in some users’ browsers. Even if the technology (called OCSP, for “online certificate status protocol”) was present and enabled, a simple timing-out of a browser revocation query can cause some browsers to accept certificates as if they had been checked – when they have not. As a final line of defense in such a scenario, the big browser providers released blacklist updates this week which specifically identify the fraudulent SSL certificates by their serial numbers.

Symantec advises the following:

  1. Upgrade to the latest version of your browser of choice
  2. Turn on OCSP checking in your browser settings
  3. Choose EV SSL (the SSL that turns the browser address bar green

Upgrade your Browser and Enable OCSP

Symantec strongly recommends that users upgrade to the latest version of their browser and that they deliberately check whether OCSP checking is actually enabled in their browser settings.

For example: in Firefox users can find this setting under “Tools -> Options -> Advanced -> Encryption -> Validation”. In Firefox, users also must check both “Use the OCSP to confirm the current validity of certificates” AND “When an OCSP server connection fails, treat the certificate as invalid”.

If the latest version of your browser does not support OCSP, Symantec suggests you switch to a browser which does.

What is OCSP?

OCSP is one of two technologies currently used by browsers to double check that digital certificates have not been revoked when validating a certificate. Historically, browsers downloaded certificate revocation lists (CRLs) to check the validity of a certificate. Since these CRLs could get large and browsing performance could suffer the industry created OCSP, which performs a similar function to a CRL but is far more efficient. With OCSP, a simple query about the specific certificate is performed, rather than the download of a potentially large list.

Each Certificate Authority (CA), such as VeriSign or Comodo, is responsible for maintaining its own revocation list and for processing OCSP requests. The effectiveness of OCSP depends on a reliable and robust CA infrastructure because the number of OCSP queries continues to grow as Internet usage continues to grow. A weak or slow OCSP infrastructure can lead to OCSP queries “timing out” due to delays. Some browsers will mistakenly consider a “time out” to be as good as a passed revocation check. Symantec takes this requirement very seriously and has invested in an industrial-class, scalable infrastructure to ensure reliable OCSP checking. Recently VeriSign field 3 billion OCSP queries in a single day, representing an average of over 34,700 online validations per second.

Can you trust SSL?

The encryption protection offered by SSL is trusted and proven – as long as the private key and the root infrastructure have not been compromised.

However, SSL provided by an independent CA is also intended to authenticate that the requestor of the certificate actually has the right to hold that certificate. More specifically that this person either directly holds the right to the domain or is actually an authorized member of the organization named in that certificate. Clearly the SSL certificates blacklisted this week were not issued to individuals or organizations whose identity and rights to those domains had been authenticated properly – or at all.

The trustworthiness of an SSL certificate depends on the strength of the authentication that has been performed. There are a number of methods for authenticating SSL certificates and the reliability of these methods varies widely. Symantec maintains high authentication standards for every SSL certificate issued under its flagship VeriSign brand. The requesting organization’s identity must be verified before it can receive a VeriSign SSL certificate.

What is EV SSL?

The most trustworthy SSL certificate is Extended Validation SSL. Symantec recommends EV SSL to all customers because it is nearly impossible for an EV SSL to be issued to a fraudulent recipient, and it cannot be issued instantly without “hands-on” validation from the CA.

The CA/Browser Forum (a consortium of CAs and browser providers) created the EV SSL standard in 2007 as an alternative to weakening SSL authentication practices used by some CAs. Strong authentication is central to EV SSL – a requester must pass a stringent, standardized set of identity validation procedures in order to be issued an EV SSL certificate. These procedures include authentication of a web site’s identity, authentication of the organization named by the site, and specifically authentication that the person requesting the certificate actually has management authority for that site.

VeriSign was the first CA to offer EV SSL and remains the market leading provider of EV SSL certificates according to Netcraft in their most recent March 2011 SSL report.

In Closing

The disclosures this week are a reminder of how important it is that CAs maintain strong authentication and practices as well as the importance of a scalable, resilient and heavily adopted revocation checking system. Symantec leads the industry in all facets of the solution to today’s events, including EV SSL market share leadership, the best SSL verification and authentication practices in the industry and an OCSP responder already proven capable of handling 3 billion queries per day.

See the original post here:
How to avoid fraudulent SSL