Comodo Security Breach
It’s been a wide spread news now on web about Comodo RA certificate(SSL) issue.It was on 15th March 2011, a RA(Registration Authority) partner of the Comodo CA suffered an internal security breach .It’s been informed that the attacker used the RA’s account with Comodo to cause 9 fraudulent certificates to be issued.We just go through behind the issue and some tips from experts.
Most browsers has been informed about the regarding these issue and mostly every browsers(Mozilla,chrome) had updated this issue to recognize these certificates and block them automatically.It’s been on several news that Google updated Chrome on March 16, . Mozilla updated Firefox 4.0, 3.6, and 3.5 by March 22, per a note on the Mozilla Security Blog.
What was the issue?
On 15th March 2011, a RA partner of the Comodo CA suffered an internal security breach (Comodo incident report). The attacker used the RA’s account with Comodo to cause 9 fraudulent certificates to be issued.
The domain names of the certificates were as follows:
The attack was discovered almost immediately by an internal Comodo check, and the certificates were revoked (via both CRL and OCSP). The compromised RA account has been suspended.
What is this attack /hack meant by?
Well if you are familiar with SSL, it’s easy to explain,In order to understand these issues , we need a bit knowledge on how certificates work.Just as the government issues forms of identification to prove your identity, CA’s(Certificate Authority) serve as proof of digital identities, called certificates, to secure websites that let your web browser know that it is really talking to sites like Google, Yahoo!, or your bank.
When you go to an HTTPS (encryption)address, your browser encrypts communication with the site. The mechanics of setting up the connection involve public key cryptography; your browser and the website have to implement the encryption by exchanging public keys. Your browser also has to determine that the public key it receives is valid, which is where the certificate comes into play.
A certification authority issues digital certificates that say, in effect, “This is the public key owned by ABC Corp.” If you point your browser at https://ABC.com, the website sends your browser a public key and its certificate. Now Your browser verifies that the certificate was issued by a “trusted” certification authority, is associated with the site you’re looking at, and is still valid. It performs this check by looking to see if the specific certificate is on a list of revoked certificates. If all passes , your browser uses the public key to initiate an encrypted session with the HTTPS website.
Certification authority companies charge money to issue certificates, and websites apply to get a certificate. Meanwhile, browsers maintain lists of validated CAs, which could run to several dozen companies. I trust — and you trust — those companies to make sure a certificate for ABC website gets issued to only ABC Corp. The three largest certification authorities are VeriSign, GoDaddy, and Comodo.
So what the attacker did, is he used a valid username and password from Comodo Trusted Partner in Southern Europe to get into the Comodo certificate issuing system. The cracker set up a new user account and issued nine validated requests (called “certificate signing requests”) to apply for certificates. Certificates were then issued by Comodo to intruder who owns an Iranian ip address.
Armed with these fake SSL certificates, the owner can successfully trick your browser into believing you’re logging on to a secure site .This could deceive them into revealing personal information such as usernames and passwords. It may also deceive users into downloading malware if they believe it’s coming from a trusted site.For example, you would type or click on a link to https://mail.google.com and somehow the bad guys would send you to their own fake site.
But quest remains
how that person managed to get the username and password?
How could Comodo issue an SSL certificate for famous organization like Google,yahoo?
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”.Now don’t forget to check out as you are in an HTTPS connection , go to URL bar , right left to the URL bar, for eg:twitter.com , click on it , a window pops up ,Click “more information” and “view certificates”.Check your certificate is verified.
If the latest version of your browser does not support OCSP, Symantec suggests you switch to a browser which does.However Comodo appropriately revoked the certificates immediately and notified the major browser vendors so that more proactive actions could be taken.
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.
Sources of the News or to know more