December 14, 2024

CITP Call for 2012-2013 Visiting Fellows and Postdocs

The Center for Information Technology Policy is an interdisciplinary research center at Princeton University that studies the intersection of digital technologies and society. Each academic year, CITP issues a call for visiting fellows and postdoctoral researchers. Applications for the 2012-2013 academic year are due by February 1st, 2012.

CITP seeks candidates for Fellows positions from academia, industry, government, and civil society. These are one year appointments — usually from July 1st to June 30th. We are happy to hear from anyone who works at the intersection of digital technology and public life. In addition to our existing strengths in computer science and sociology, we are particularly interested in hearing from faculty members at other universities who have first-hand experience in public service in the technology policy area, engineers, economists, lawyers, civil servants and policy analysts whose research interests are complementary to our existing activities. Please see our current and past fellows to get a sense for the type of people we seek.

For more details, and to apply, visit:
http://citp.princeton.edu/about/join/fellowship-application/

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.)

Web Browsers and Comodo Disclose A Successful Certificate Authority Attack, Perhaps From Iran

Today, the public learned of a previously undisclosed compromise of a trusted Certificate Authority — one of the entities that issues certificates attesting to the identity of “secure” web sites. Last week, Comodo quietly issued a command via its certificate revocation servers designed to tell browsers to no longer accept 9 certificates. This is fairly standard practice, and certificates are occasionally revoked for a variety of reasons. What was unique about this case is that it was followed by very rapid updates by several browser manufacturers (Chrome, Firefox, and Internet Explorer) that go above and beyond the normal revocation process and hard-code the certificates into a “do not trust” list. Mozilla went so far as to force this update in as the final change to their source code before shipping their major new release, Firefox 4, yesterday.

This implied that the certificates were likely malicious, and may even been used by a third-party to impersonate secure sites. Here at Freedom to Tinker we have explored the several ways in which the current browser security system is prone to vulnerabilities [1, 2, 3, 4, 5, 6]

Clearly, something exceptional happened behind the scenes. Security hacker Jacob Appelbaum did some fantastic detective work using the EFF’s SSL Observatory data and discovered that all of the certificates in question originated from Comodo — perhaps from one of the many affiliated companies that issues certificates under Comodo’s authority via their “Registration Authority” (RA) program. Evidently, someone had figured out how to successfully attack Comodo or one of their RAs, or had colluded with them in getting some invalid certs.

Appelbaum’s pressure helped motivate a statement from Mozilla [and a follow-up] and a statement from Microsoft that gave a little bit more detail. This afternoon, Comodo released more details about the incident, including the domains for which rogue certificates were issued: mail.google.com, www.google.com, login.yahoo.com (3 certs), login.skype.com, addons.mozilla.org, login.live.com, and “global trustee”. Comodo noted:

“The attack came from several IP addresses, but mainly from Iran.”

and

“this was likely to be a state-driven attack”

[Update: Someone claiming to be the hacker has posted a manifesto. At least one security researcher finds the claim to be credible.]

It is clear that the domains in question are among the most attractive targets for someone who wants to surveil the personal communications of many people online by inserting themselves as a “man in the middle.” I don’t have any deep insights on Comodo’s analysis of the attack’s origins, but it seems plausible. (I should note that although Comodo claims that only one of the certificates was “seen live on the Internet”, their mechanism for detecting this relies on the attacker not taking some basic precautions that would be well within the means and expertise of someone executing this attack.) [update: Jacob Appelbaum also noted this, and has explained the technical details]

What does this tell us about the current security model for web browsing? This instance highlights a few issues:

  • Too many entities have CA powers: As the SSL Observatory project helped demonstrate, there are thousands of entities in the world that have the ability to issue certificates. Some of these are trusted directly by browsers, and others inherit their authority. We don’t even know who many of them are, because such delegation of authority — either via “subordinate certificates” or via “registration authorities” — is not publicly disclosed. The more of these entities exist, the more vulnerabilities exist.
  • The current system does not limit damage: Any entity that can issue a certificate can issue a certificate for any domain in the world. That means that a vulnerability at one point is a vulnerability for all.
  • Governments are a threat: All the major web browsers currently trust many government agencies as Certificate Authorities. This often includes places like Tunisia, Turkey, UAE, and China, which some argue are jurisdictions hostile to free speech. Hardware products exist and are marketed explicitly for government surveillance via a “man in the middle” attack.
  • Comodo in particular has a bad track record with their RA program: The structure of “Registration Authorities” has led to poor or nonexistant validation in the past, but Mozilla and the other browsers have so far refused to take any action to remove Comodo or put them on probation.
  • We need to step up efforts on a fix: Obviously the current state of affairs is not ideal. As Appelbaum notes, efforts like DANE, CAA, HASTLS, and Monkeysphere deserve our attention.

[Update: Jacob Appelbaum has posted his response to the Comodo announcement, criticizing some aspects of their response and the browsers.]

[Update: A few more details are revealed in this Comodo blog post, including the fact that “an attacker obtained the username and password of a Comodo Trusted Partner in Southern Europe.”]

[Update: Mozilla has made Appelbaum’s bug report publicly visible, along with the back-and-forth between him and Mozilla before the situation was made public. There are also some interesting details in the Mozilla bug report that tracked the patch for the certificate blacklist. There is yet another bug that contains the actual certificates that were issued. Discussion about what Mozilla should do in further response to this incident is proceeding in the newsgroup dev.mozilla.security.policy.]

[Update: I talked about this issue on Marketplace Tech Report.]

You may also be interested in an October 22, 2010 event that we hosted on the policy and technology issues related to online trust (streaming video available):


Web Browser Security User Interfaces: Hard to Get Right and Increasingly Inconsistent

A great deal of online commerce, speech, and socializing supposedly happens over encrypted protocols. When using these protocols, users supposedly know what remote web site they are communicating with, and they know that nobody else can listen in. In the past, this blog has detailed how the technical protocols and legal framework are lacking. Today I’d like to talk about how secure communications are represented in the browser user interface (UI), and what users should be expected to believe based on those indicators.

The most ubiquitous indicator of a “secure” connection on the web is the “padlock icon.” For years, banks, commerce sites, and geek grandchildren have been telling people to “look for the lock.” However, The padlock has problems. First, it has been shown in user studies that despite all of the imploring, many people just don’t pay attention. Second, when they do pay attention, the padlock often gives them the impression that the site they are connecting to is the real-world person or company that the site claims to be (in reality, it usually just means that the connection is encrypted to “somebody”). Even more generally, many people think that the padlock means that they are “safe” to do whatever they wish on the site without risk. Finally, there are some tricky hacker moves that can make it appear that a padlock is present when it actually is not.

A few years ago, a group of engineers invented “Extended Validation(EV) certificates. As opposed to “Domain Validation(DV) certs that simply verify that you are talking to “somebody” who owns the domain, EV certificates actually do verify real-world identities. They also typically cause some prominent part of the browser to turn green and show the real-world entity’s name and location (eg: “Bank of America Corporation (US)”). Separately, the W3 Consortium recently issued a final draft of a document entitled “Web Security Context: User Interface Guidelines.” The document describes web site “identity signals,” saying that the browser must “make information about the identity of the Web site that a user interacts with available.” These developments highlight a shift in browser security UI from simply showing a binary padlock/no-padlock icon to showing more rich information about identity (when it exists).

In the course of trying to understand all of these changes, I made a disturbing discovery: different browser vendors are changing their security UI’s in different ways. Here are snapshots from some of the major browsers:

As you can see, all of the browsers other than Firefox still have a padlock icon (albeit in different places). Chrome now makes “https” and the padlock icon green regardless of whether it is DV or EV (see the debate here), whereas the other browsers reserve the green color for EV only. The confusion is made worse by the fact that Chrome appears to contain a bug in which the organization name/location (the only indication of EV validation) sometimes does not appear. Firefox chose to use the color blue for DV even though one of their user experience guys noted, “The color blue unfortunately carries no meaning or really any form of positive/negative connotation (this was intentional and the rational[e] is rather complex)”. The name/location from EV certificates appear in different places, and the method of coloring elements also varies (Safari in particular colors only the text, and does so in dark shades that can sometimes be hard to discern from black). Some browsers also make (different) portions of the url a shade of gray in an attempt to emphasize the domain you are visiting.

Almost all of the browsers have made changes to these elements in recent versions. Mozilla has been particularly aggressively changing Firefox’s user interface, with the most dramatic change being the removal of the padlock icon entirely as of Firefox 4. Here is the progression in changes to the UI when visiting DV-certified sites:

By stepping back to Firefox 2.0, we can see a much more prominent padlock icon in both the URL bar and in the bottom-right “status bar” along with an indication of what domain is being validated. Firefox 3.0 toned down the color scheme of the lock icon, making it less attention grabbing and removing it from the URL bar. It also removed the yellow background that the URL bar would show for encrypted sites, and introduced a blue glow around the site icon (“favicon”) if the site provided a DV cert. This area was named the “site identification button,” and is either grey, blue, or green depending on the level of security offered. Users can click on the button to get more information about the certificate, presuming they know to do so. At some point between Firefox 3.0 and 3.6, the domain name was moved from the status bar (and away from the padlock icon) to the “site identification button”.

In the soon-to-be-released Firefox 4 is the padlock icon removed altogether. Mozilla actually removed the “status bar” at the bottom of the screen completely, and the padlock icon with it. This has caused consternation among some users, and generated about 35k downloads of an addon that restores some of the functionality of the status bar (but not the padlock).

Are these changes a good thing? On the one hand, movement toward a more accurately descriptive system is generally laudable. On the other, I’m not sure whether there has been any study about how users interpret the color-only system — especially in the context of varying browser implementations. Anecdotally, I was unaware of the Firefox changes, and I had a moment of panic when I had just finished a banking transaction using a Firefox 4 beta and realized that there was no lock icon. I am not the only one. Perhaps I’m an outlier, and perhaps it’s worth the confusion in order to move to a better system. However, at the very least I would expect Mozilla to do more to proactively inform users about the changes.

It seems disturbing that the browsers are diverging in their visual language of security. I have heard people argue that competition in security UI could be a good thing, but I am not convinced that any benefits would outweigh the cost of confusing users. I’m also not sure that users are aware enough of the differences that they will consider it when selecting a browser… limiting the positive effects of any competition. What’s more, the problem is only set to get worse as more and more browsing takes place on mobile devices that are inherently constrained in what they can cram on the screen. Just take a look at iOS vs. Android:

To begin with, Mobile Safari behaves differently from desktop Safari. The green color is even harder to see here, and one wonders whether the eye will notice any of these changes when they appear in the browser title bar (this is particularly evident when browsing on an iPad). Android’s browser displays a lock icon that is identical for DV and EV sites. Windows Phone 7 behaves similarly, but only when the URL bar is present — and the URL bar is automatically hidden when you rotate your phone into landscape mode. Blackberry shows a padlock icon inconspicuously in the top status bar of the phone (the same area as your signal strength and battery status). Blackberry uniquely shows an unlocked padlock icon when on non-encrypted sites, something I don’t remember in desktop browsers since Netscape Navigator (although maybe it’s a good idea to re-introduce some positive indication of “not encrypted”).

Some of my more cynical realistic colleagues have said that given the research showing that most users don’t pay attention to this stuff anyway, trying to fix it is pointless. I am sympathetic to that view, and I think that making more sites default to HTTPS, encouraging adoption of standards like HSTS, and working on standards to make it easier to encrypt web communications are probably lower hanging fruit. There nevertheless seems to be an opportunity here for some standardization amongst the browser vendors, with a foundation in actual usability testing.

CITP Visitors Application Deadline Extended to Feb 1st

The deadline for applications to CITP’s Visitors Program has been extended to February 1st. If you or someone you know is interested but has questions, feel free to contact me at

The Center has secured limited resources from a range of sources to support visiting faculty, scholars or policy experts for up to one-year appointments during the 2011-2012 academic year. We are interested in applications from academic faculty and researchers as well as from individuals who have practical experience in the policy arena. The rank and status of the successful applicant(s) will be determined on a case-by-case basis. We are particularly interested in hearing from faculty members at other universities and from individuals who have first-hand experience in public service in the technology policy area.

For more details and instructions about how to apply, see the full description here.