In the physical world, you often conduct business with others face-to-face. If you do not personally know someone, you might rely on a trusted third party to vouch for the person's identity. That trusted third party might be a mutual friend, or it might be a government office that issues identification documents (passports, driver's licenses, state identification cards, school IDs, and the like). Digital certificates are the online equivalent of an identification card. See my article on the Heartbleed OpenSSL vulnerability for a thorough (but easily readable) explanation of digital certificates.
The above analogy implies some degree of trust - you accept a passport as identification because you trust that the issuing government can correctly identify a citizen. Likewise, digital certificates rely on a trusted third party, known as a Certificate Authority or CA. Through some complex and clever math, your computer can be certain that a web site has a particular certificate - but that knowledge by itself is not of much use. After all, anyone could create a certificate that says "I am Facebook." We rely on the CA to verify the identity of the real Facebook before issuing a certificate for Facebook.com.
And there's the rub. If a CA issues fraudulent certificates (whether through malicious intent or through poor identity verification) and you trust that CA, you may be fooled into thinking a malicious web site is the real Facebook. That is precisely what happened here. The National Informatics Center, which operates CAs under the Government of India root certificate authority, issued fraudulent certificates for a large number of web properties owned by Google and Yahoo!.
With these fraudulent certificates, a malicious actor could create a spoof of gmail.com (for example), and then engage in what is known as a man-in-the-middle attack. The attacker would sit somewhere between you and the real Gmail; to you, they pretend to be Gmail, while to Gmail they pretend to be you. All the while they get to read everything sent back and forth (including passwords, private email messages, and other sensitive information).
Fortunately the inventors of digital certificates thought of this possibility, and made two ways of addressing bad certificates. These are known as a Certificate Revocation List (CRL), and a Certificate Trust List (CTL). The former is useful when a Certificate Authority needs to cancel a certificate, while the latter is useful if a CA itself is no longer trustworthy. Chrome, Internet Explorer, Firefox, Safari, and other programs that rely on digital certificates will consult the CRL and the CTL to verify that a certificate presented by a web site is in fact still valid, and is issued by a CA that is trusted. If either case is no longer true, your web browser will display a warning message. Depending on the browser and the settings implemented on your computer or mobile device, you may be able to acknowledge the risk and proceed anyway, or you may be blocked entirely from accessing the web site with the invalid certificate.
The moral of the story? If you see one of the below warning messages, take the warning seriously. Unless you know for absolute certainty that you are visiting the site you intend to visit, and understand the reason that site has an invalid certificate, don't go there.
The moral of the story? If you see one of the below warning messages, take the warning seriously. Unless you know for absolute certainty that you are visiting the site you intend to visit, and understand the reason that site has an invalid certificate, don't go there.
