Today, the vulnerable state of electronic communications security dominates headlines across the globe, while surveillance, money and power increasingly permeate the ‘cybersecurity’ policy arena. With the stakes so high, how should communications security be regulated? Deirdre Mulligan (UC Berkeley), Ashkan Soltani (independent, Washington Post), Ian Brown (Oxford) and Michel van Eeten (TU Delft) weighed in on this proposition at an expert panel on my doctoral project at the Amsterdam Information Influx conference. [Read more...]
The main takeaway of two recent disclosures around N.S.A. surveillance practices, is that Americans must re-think ‘U.S. citizenship’ as the guiding legal principle to protect against untargeted surveillance of their communications. Currently, U.S. citizens may get some comfort through the usual political discourse that ‘ordinary Americans’ are protected, and this is all about foreigners. In this post, I’ll argue that this is not the case, that the legal backdoor of U.S. Citizenship is real and that relying on U.S. citizenship for protection is not in America’s interests. As a new CITP Fellow and a first time contributor to this amazing blog, I’ll introduce myself and my research interests along the way. [Read more...]
Over the past couple of days there has been some press coverage over security researcher Guarang Pandya’s report that the browser on his Nokia phone was sending all of his traffic to Nokia proxy servers, including his HTTPS traffic. The disturbing part of his report was evidence that Nokia is not just proxying, but actually decrypting the HTTPS traffic. Nokia replied with a statement (in the comments section of Pandya’s blog post, and to several news outlets):
We take the privacy and security of our consumers and their data very seriously. The compression that occurs within the Nokia Xpress Browser means that users can get faster web browsing and more value out of their data plans. Importantly, the proxy servers do not store the content of web pages visited by our users or any information they enter into them. When temporary decryption of HTTPS connections is required on our proxy servers, to transform and deliver users’ content, it is done in a secure manner.
Nokia has implemented appropriate organizational and technical measures to prevent access to private information. Claims that we would access complete unencrypted information are inaccurate.
We aim to be completely transparent on privacy practices. As part of our policy of continuous improvement we will review the information provided in the mobile client in case this can be improved.
You can find out more about Nokia’s privacy practices at http://www.nokia.com/privacy.
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.
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):
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:
- too many entities have Certificate Authority powers
- the current system does not limit damage
- governments are a threat
- we need to step up efforts on a fix
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.)