October 19, 2018

Turktrust Certificate Authority Errors Demonstrate The Risk of "Subordinate" Certificates

Update: More details have continued to come out, and I think that they generally support the less-paranoid version of events. There continues to be discussion on the mozilla.dev.security.policy list, Turktrust has given more details, and Mozilla has just opened up for public viewing their own detailed internal response documentation (including copies of all of the certs in question). None of this changes the fundamental riskiness of subordinate certificates, or the improvements that should be made to the CA system. It just means that in this case, the failure didn’t progress to a full-blown meltdown.

Today, the public learned of another failure by a Certificate Authority–one of of companies that certifies SSL-encryption for our internet communications. (See the end of this post for a catalogue of our past writing on problems with this “CA” system.) This time, the company Turktrust was revealed to have issued two subordinate certificates (also known as “intermediate” certificates) to entities that should not have had them. Subordinate certificates are very powerful. They give the holder the ability to issue SSL certificates for any domain name as though they have control of the parent CA’s “root” certificate. In this case, Google discovered that one of Turktrust’s previously undisclosed subordinate certificates had issued SSL certificates for the domain gmail.com, and that these certificates had been used to intercept Gmail users’ traffic… somewhere. This is where the details get foggy, but Turktrust has begun to describe their version of events.

There is a less paranoid and a more paranoid way of interpreting what happened.

[Read more…]

Firefox Changes its HTTPS User Interface… Again

A year and a half ago, I wrote about major changes to the way that Firefox indicates whether the connection to a web site is encrypted. I noted that, especially with the emergence of mobile browsers, the traditional “padlock icon” of standard SSL-secured connections and the “green glow” of Extended Validation was being implemented in varied and conflicting ways across different browsers (“Web Browser Security User Interfaces: Hard to Get Right and Increasingly Inconsistent”). For standard SSL connections, Firefox had removed the padlock icon entirely, relying instead on a “blue highlight” color. I criticized this change because it confused users and made Firefox even more atypical:

Firefox 14 shipped last week. The padlock icon is back and the blue glow is gone (this page describes the new indicators):

[Read more…]

DigiNotar Hack Highlights the Critical Failures of our SSL Web Security Model

This past week, the Dutch company DigiNotar admitted that their servers were hacked in June of 2011. DigiNotar is no ordinary company, and this was no ordinary hack. DigiNotar is one of the “certificate authorities” that has been entrusted by web browsers to certify to users that they are securely connecting to web sites. Without this certainty, users could have their communications intercepted by any nefarious entity that managed to insert itself in the network between the user and the web site they seek to reach.

It appears that DigiNotar did not deserve to be trusted with the responsibility to to issue certifying SSL certificates, because their systems allowed an outside hacker to break in and issue himself certificates for any web site domain he wished. He did so, for dozens of domain names. This included domains like *.google.com and www.cia.gov. Anyone with possession of these certificates and control over the network path between you and the outside world could, for example, view all of your traffic to Gmail. The attacker in this case seems to be the same person who similarly compromised certificate-issuing servers for the company Comodo back in March. He has posted a new manifesto, and he claims to have compromised four other certificate authorities. All signs point to the conclusion that this person is an Iranian national who supports the current regime, or is a member of the regime itself.

The Comodo breach was deeply troubling, and the DigiNotar compromise is far worse. First, this new break-in affected all of DigiNotar’s core certificate servers as opposed to Comodo’s more contained breach. Second, this afforded the attacker with the ability of issuing not only baseline “domain validated” certificates but also higher-security “extended validation” certificates and even special certificates used by the Dutch government to secure itself (see the Dutch government’s fact sheet on the incident). However, this damage was by no means limited to the Netherlands, because any certificate authority can issue certificates for any domain. The third difference when compared to the Comodo breach is that we have actual evidence of these certificates being deployed against users in the real world. In this case, it appears that they were used widely against Iranian users on many different Iranian internet service providers. Finally, and perhaps most damning for DigiNotar, the break-in was not detected for a whole month, and was then not disclosed to the public for almost two more months (see the timeline at the end of this incident report by Fox-IT). The public’s security was put at risk and browser vendors were prevented from implementing fixes because they were kept in the dark. Indeed, DigiNotar seems to have intended never to disclose the problem, and was only forced to do so after a perceptive Iranian Google user noticed that their connections were being hijacked.

The most frightening thing about this episode is not just that a particular certificate authority allowed a hacker to critically compromise its operations, or that the company did not disclose this to the affected public. More fundamentally, it reminds us that our web security model is prone to failure across the board. As I noted at the time of the Comodo breach:

I recently spoke on the subject at USENIX Security 2011 as part of the panel “SSL/TLS Certificates: Threat or Menace?” (video and audio here if you scroll down to Friday at 11:00 a.m., and slides here.)