In the previous part we established the fact, that for HTTPS to work as intended, you as a web browser user need to trust your browser vendor's decision to trust the certificate authorities issuing the certificates to web server maintainers. This post is about when things go wrong, the chain-of-trust is broken and organization's actions are deemed not so trustworthy.
Known CA security incidents in chronological order:
- 2010 (multiple incidents): Key Internet operator VeriSign hit by hackers
- There isn't much information available on this, but they disclosed this on their quarterly report.
- "Are we finally ready to accept that the certificate system is completely broken?"
- Bruce Schneier, on his blog
- March 2011: Hackers target Google, Skype with rogue SSL certificates
- Comodo was cracked, and certificates for orgs like Google were issued without them knowing about it.
- August 2011: Hackers stole Google SSL certificate, Dutch firm admits
- DigiNotar was cracked and Google certificates were created. Later DigiNotar went bankcrupt as they reputation was gone.
- December 2013: French Government ANSSI responsible of a MITM against Google SSL-TLS
- French CA issuing Google certificates
- July 2014: Indian government agency issues fake Google certificates
- This is really bad! A government agency in India issuing Google certificates. I'd understand a company doing that, but government... no.
- December 2014: Turkish Certificate Authority screwup leads to attempted Google impersonation
- Turkish CA issuing Google certificates
- March 2015: Google to drop China’s CNNIC Root Certificate Authority after trust breach
- A Chinese CA issuing Google certificates.
- September 2015: Symantec employees fired for issuing rogue HTTPS certificate for Google
- Inside job at Symantec, guys wanted to issue Google certificates
- October 2016: Distrusting New WoSign and StartCom Certificates (on Mozilla and on Google)
- WoSign issued certificate for GitHub, yet another inside job.
As you already figured out the pattern. Anybody can issue any certificate for anybody. This many-to-many pattern isn't very trustworthy. 
Also, there seems to be more activity during the past two years or so, there is clearly more interest in gaining access to somebody's certificate.
In part 1 of my HTTPS-series it was established, that a X.509 certificate cannot identify the server. Now that cert-business sells certificates with a claim, that they have "verified" the request and the owner is who they claim to be, the above list tells another story. Nasty things happen when there is no verification, no real customer, but a malicious act of issuing a certificate for own cracking purposes.
Other acts of mistrust:
- January 2015: Gogo Inflight Internet serves up 'man-in-the-middle' with fake SSL
- Inflight service provider goes man-in-the-middle on purpose. Of course all bad deeds can be wrapped into good intentions, they wanted to "protect the bandwidth usage".
- February 2015: Lenovo PCs ship with man-in-the-middle adware that breaks HTTPS connections
- Lenovo laptops were pre-installed with a certificate used for snooping your HTTPS-traffic. The thing is: if anybody can inject a trusted root certificate to your computer, you won't notice that somebody is reading your encrypted traffic.
- November 2015: Dell does a Superfish, ships PCs with easily cloneable root certificates
- Yet another pre-installed certificate making man-in-the-middle. Every computer had same PKI installed making anybody able to eavesdrop your carefully encrypted traffic.
These acts are as evil, altough different by nature, but target the same thing: to gain access to your encypted data.
Ok, what's the risk here?
In practice, what is the threat here? What are those "nasty things" that can happen?
The incidents where new computers had a pre-installed trusted certificate, or your traffic was forced via man-in-the-middle -proxy are easier to address. Without you realizing it, all your encrypted traffic is directed to a party faking to be your intended target. Man-in-the-middle just de-crypts your passwords and credit card numbers and passes the traffic forward to the real target server acting as you. So, there is an obvious direct risk, that your traffic isn't secure at all.
Somebody issuing a trusted rogue Google certificate is bit more complex. A certificate itself isn't too dangerous, but in a scenario where the outgoing traffic from your computer is re-directed to a rogue server having the certificate you won't be able to tell the difference. How somebody's traffic can be redirected can be done locally, by changing your DNS-settings or remotely attacking the DNS-server your're using. Both cases are seen in real life. Nevertheless, it is almost impossible to know that such a change has been made and you go to a fake "google" server, enter your password without realizing, that somebody else is in possession of your login credentials. These cases haven't been publicly reported, but if anybody manages to pull that one off, it would be really really bad. Ultimately, there is only indirect risk, that you may lose your secure data.
Ok, this insecurity is horrible, isn't there anything we can do?
Yes.
There are a number of technical innovations trying to govern the certificates. However, none of them are widespread nor commonly accepted. This leaves everybody at the mercy of certificate authorities and their actions.
I'll address those technical measures in my final part of this HTTPS-series.
This is the second part of a three part series addressing HTTPS and it's (in)security. Previous part was about basics of trusted certificates. Next part is about (failed) attempts to supervise trust.