Certied Lies: Detecting and Defeating GovernmentInterception Attacks Against SSL

8/4/2019 Certied Lies: Detecting and Defeating GovernmentInterception Attacks Against SSL

1/20

Certified Lies: Detecting and Defeating Government

Interception Attacks Against SSL

Christopher Soghoian and Sid Stamm

Cryptography is typically bypassed, notpenetrated. Adi Shamir [1]

Just because encryption is involved, thatdoesnt give you a talisman against a pros-ecutor. They can compel a service providerto cooperate. Phil Zimmerman [2]

Abstract

This paper introduces the compelled cer-tificate creation attack, in which governmentagencies may compel a certificate authority toissue false SSL certificates that can be used byintelligence agencies to covertly intercept andhijack individuals secure Web-based commu-nications. Although we do not have direct ev-idence that this form of active surveillance istaking place in the wild, we show how prod-ucts already on the market are geared and mar-

keted towards this kind of usesuggesting suchattacks may occur in the future, if they arenot already occurring. Finally, we introducea lightweight browser add-on that detects andthwarts such attacks.

1 Introduction

Consider a hypothetical situation where an Ameri-can executive is in France for a series of trade ne-gotiations. After a day of meetings, she logs in toher corporate webmail account using her company-

provided laptop and the hotel wireless network. Re-lying on the training she received from her com-panys IT department, she makes certain to look for

The authors hereby permit the use of this article underthe terms of the Creative Commons Attribution 3.0 UnitedStates license.

Both authors of this paper have written it in their per-sonal capacities as academic researchers. All statements,opinions and potential mistakes are their own, and do notreflect the official positions of their respective employers.

the SSL encryption lock icon in her web browser,and only after determining that the connection issecure does she enter her login credentials and thenbegin to upload materials to be shared with her col-leagues. However, unknown to the executive, theFrench government has engaged in a sophisticatedman-in-the-middle attack, and is able to covertly in-tercept the executives SSL encrypted connections.Agents from the state security apparatus leak detailsof her communications to the French company withwhom she is negotiating, who use the information togain an upperhand in the negotiations. While thisscenario is fictitious, the vulnerability is not.

The security and confidentiality of millions of In-ternet transactions per day depend upon the SecureSocket Layer (SSL)/Transport Layer Security (TLS)protocol. At the core of this system are a num-ber of Certificate Authorities (CAs), each of whichis responsible for verifying the identity of the en-tities to whom they grant SSL certificates. It isbecause of the confidentiality and authenticity pro-vided by the CA based public key infrastructure thatusers around the world can bank online, engage inelectronic commerce and communicate with theirfriends and loved ones about the most sensitive ofsubjects without having to worry about maliciousthird parties intercepting and deciphering their com-munications.

While not completely obvious, the CAs are alltrusted equally in the SSL public key infrastructure,a problem amplified by the fact that the major webbrowsers trust hundreds of different firms to issuecertificates for any site. Each of these firms can becompelled by their national government to issue acertificate for any particular website that all webbrowsers will trust without warning. Thus, usersaround the world are put in a position where theirbrowser entrusts their private data, indirectly, to alarge number of governments (both foreign and do-mestic) whom these individuals may not ordinarily

1


2/20

trust.

In this paper, we introduces a new attack, thecompelled certificate creation attack, in which gov-ernment agencies compel (via a court order or someother legal process) a CA to issue false certificatesthat are then used by law enforcement and intelli-gence agencies to covertly intercept and hijack indi-viduals secure communications.

We also show how currently available surveillanceproducts are advertised in a way that suggests thatthis attack is more than a theoretical concern, butis likely in active use; at least one private companyis supplying government customers with specializedcovert network appliances specifically designed to in-tercept SSL communications using deceptively cre-ated certificates.

In order to protect users from these powerful gov-ernment adversaries, we introduce a lightweight de-fensive browser add-on that detects and thwartssuch attacks. Finally, we use reductive analysis ofgovernments legal capabilities to perform an adver-sarial threat model analysis of the attack and ourproposed defensive technology. We believe that thisform of legal threat model analysis is itself new tothe computer security literature.

In section 2 we provide a brief introduction toCAs, web browsers and the man-in-the-middle at-tacks against them. In section 3 we discuss the pres-ence of government-controlled CAs in the browsers.In section 4, we describe the compelled certificatecreation attack and then in section 5, we presentevidence that suggests it is being used. In section6 we introduce our browser based add-on, and insection 7, we analyze its effectiveness via a threatmodel based analysis. Finally, we present relatedwork in section 8 and conclude in section 9.

2 Certificate Authorities and the

Browser Vendors

In this section, we provide a brief overview of theroles played by the Certificate Authorities in thepublic key infrastructure, the browser vendors inpicking the certificate authorities that they includein the browsers, and existing man-in-the-middle-attack techniques that circumvent SSL based secu-rity.

2.1 Certificate Authorities

[Browser vendors] and users must be care- ful when deciding which certificates andcertificate authorities are acceptable; a dis-honest certificate authority can do tremen-dous damage.

RFC 2246, The TLS Protocol 1.0 [3]

CAs play a vital role in the SSL public key in-frastructure (PKI). Each CAs main responsibilityis to verify the identity of the entity to which it is-sues a certificate.1 Thus, when a user visits https://www.bankofamerica.com, her browser will informher that the banks certificate is valid, was issuedby VeriSign, and that the website is run by Bank ofAmerica. It is because of the authenticity and confi-dentiality guaranteed by SSL that the user can con-tinue with her transaction without having to worrythat she is being phished by cyber-criminals.

CAs generally fall into one of three categories:Those trusted by the browsers (root CAs), thosetrusted by one of the root CAs (intermediate CAsor subordinate CAs), and those neither trusted bythe browsers nor any intermediate CA (untrustedCAs). Furthermore, intermediate CAs do not nec-essarily have to be directly verified by a root CA but can be verified by another intermediate CA,as long as the chain of trust eventually ends with aroot CA.2

From the end users perspective, root CAs andintermediate CAs are functionally equivalent. Awebsite that presents a certificate signed by eitherform of CA will cause the users browser to displaya lock icon and to change the color of the locationbar. Whereas certificates verified by an untrusted

1The level of verification performed by the CA dependsupon the type of certificate purchased. A domain registrationcertificate can be obtained for less than $15, and will typi-cally only require that the requester be able to reply to anemail sent to the administrative address listed in the WHOIS

database. Extended Validation (EV) certificates require agreater de of verification.2Dan Kaminsky describes this aspect of the CA chain of

trust as: You can just walk up to a certificate authority andsay, Yeah, so I spent a lot of money on my CA and it doesntwork with anyone outside my company. Um, heres a pile ofmoney and I promise to be good. No really, you can justbuy a root certificate, effectively. Its not expensive, its notthat difficult, and theres an unknown number of companiesout there not just the certificate authorties but all of thecompanies that have intermediate certificates they can allissue certificates for your domain [4].

2


3/20

CA and those self-signed by the website owner willresult in the display of a security warning, whichfor many non-technical users can be scary [5], con-fusing, and difficult to bypass in order to continuenavigating the site [6].

As the CA system was originally designed andis currently implemented, all root CAs are equally

trusted by the browsers. That is, each of the 264root CAs trusted by Microsoft, the 166 root CAstrusted by Apple, and the 144 root CAs trustedby Firefox are capable of issuing certificates for anywebsite, in any country or top level domain [7]. Forexample, even though Bank of America obtained itscurrent SSL certificate from VeriSign, there is notechnical reason why another CA, such as GoDaddy,cannot issue another certificate for the same site tosomeone else. Should a malicious third party some-how obtain a certificate for Bank of Americas site

and then trick a user into visiting their fake webserver (for example, by using DNS or ARP spoof-ing), there is no practical, easy way for the user todetermine that something bad has happened, as thebrowser interface will signal that a valid SSL sessionhas been established.3

Of course, GoDaddy is extremely unlikely toknowingly provide such a certificate to a maliciousthird party. Doing so would almost certainly leadto significant damage to its reputation, a number oflawsuits, as well as the ultimate threat of having its

trusted status revoked by the major web browsers.4

Therefore, it is in each CAs self-interest to ensurethat malicious parties are not able to obtain a cer-tificate for a site not under their own control.

It is important to note that there are no technicalrestrictions in place that prohibit a CA from issuing

3Even if the user examines the more complex security in-formation listed in the browsers SSL interface, she will stilllack the information necessary to make an informed trust de-cision. Since GoDaddy is a valid certificate authority and hasissued millions of other valid certificates, there is no way for

the user to determine that any one particular certificate wasimproperly issued to a malicious third party.4The browser vendors wield considerable theoretical power

over each CA. Any CA no longer trusted by the majorbrowsers will have an impossible time attracting or retainingclients, as visitors to those clients websites will be greeted bya scary browser warning each time they attempt to establish asecure connection. Nevertheless, the browser vendors appearloathe to actually drop CAs that engage in inappropriate be-havior a rather lengthy list of bad CA practices that havenot resulted in the CAs being dropped by one browser vendorcan be seen in [8].

a certificate to a malicious third party. Thus, boththe integrity of the CA based public key infrastruc-ture and the security users communications dependupon hundreds of CAs around the world choosing todo the right thing. Unfortunately, as will soon beclear, any one of those CAs can become the weakestlink in the chain.

2.2 Web Browsers

There is no technical standard that specifies howweb browsers should select their list of trusted CAs.As a result, each browser vendor has created theirown set of policies to evaluate and approve CAs[9, 10, 11]. Since there is no evidence to suggestthat any browser has knowingly or incompetentlyapproved a rogue CA, we do not discuss each par-ticular vendors policies in depth.

What does merit further attention is the methodby which the browser vendors deliver and updatetheir list of root CAs and the in-browser user in-terface provided to end-users to view and managethem.

The major browsers (Internet Explorer, Firefox,Chrome and Safari) have all adopted slightly differ-ent policies for managing and displaying the list oftrusted CAs: Firefox is the only major browser tomaintain its own database of trusted CAs, while theother three browsers instead rely upon a list of CAs

provided by the operating system. However, sincetwo of these three browser vendors are also majorplayers in the computer operating system business,the line between browser and operating system tendsto be rather blurry.

In years past, Microsoft, like the other vendors,included hundreds of CAs in its Windows operat-ing system Trusted Root Store. Users who discov-ered the relevant user interface were able to viewand manage the full list of CAs. However, in re-sponse to criticism from large enterprise customers,

Microsoft reduced the number of certificates in thetrusted store in subsequent OS versions down to justa handful.5

5The former product manager for Internet Explorer toldthe authors that a very few enterprises who chose to con-trol their own trust decisions raised concerns regarding atrusted store pre-loaded with 70100 root CAs as a poten-tial for abuse. For this and several other reason Microsoft hassince reduced the number of root certificates in the trustedstore [12].

3


4/20

Figure 1: The browser location bars of Internet Explorer (top), Firefox (middle) and Chrome (bottom)when visiting an Extended Validation HTTPS site (Bank of America) and a site with a standard HTTPS

certificate (Chase). Note that the country information (US) presented by the browsers refers to thecorporation that obtained the certificate (Bank of America), not the location of the Certificate Authority.

It would be easy for a naive user (or securityresearcher) comparing the various CA databasesthrough the user interfaces provided by Microsoft,Apple and Mozilla to conclude that Microsoft hasadopted a far more cautious approach in trustingCAs than its competitors, since the user interface ofa fresh installation of Windows Vista or Windows 7

will list less than 15 CAs in the operating systemsTrusted Root Store. Unfortunately, this interface isextremely misleading as it does not reveal the factthat Microsoft has opted to trust 264 different CAs.The companys own documentation reveals that:

Root certificates are updated on Win-dows Vista [and Windows 7] automatically.When a user visits a secure Web site (byusing HTTPS SSL) [. . . ] and encounters anew root certificate, the Windows certifi-cate chain verification software checks theappropriate Microsoft Update loca-

tion for the root certificate. If it findsit, it downloads it to the system. To theuser, the experience is seamless. The userdoes not see any security dialog boxes

or warnings. The download happens

automatically, behind the scenes [9].

Thus, any web browser that depends upon Mi-crosofts Trusted Root Store (such as Internet Ex-plorer, Chrome and Safari for Windows) ultimatelytrusts 264 different CAs to issue certificates withoutwarning, although only a handful of them are listedin the operating systems user interface. While Mi-crosoft clearly describes this in its online developerdocumentation [9], no mention of this rather impor-tant design decision is made in the browser or theoperating system certificate management user inter-face, where interested users are most likely to look.

2.3 Man in The Middle

Any website secured using TLS can be im-personated using a rogue certificate issuedby a rogue CA. This is irrespective of whichCA issued the websites true certificate andof any property of that certificate.

Marc Stevens et al. [13].

While an exhaustive explanation of man in themiddle attacks against SSL is beyond the scope ofthis article, we at least provide a brief introduc-tion to the subject. Over the past few years, theSSL protocol has been subject to a series of suc-cessful attacks by security researchers, some exploit-ing flaws in deployed systems while others madeuse of social engineering and other forms of decep-tion [14, 15, 16, 17, 18].

It is because SSL protected web connections flowover a number of other insecure protocols that it ispossible for attackers to intercept and hijack a con-nection to a SSL protected server (these are knownas man in the middle attacks ). It is only once thebrowser has received and verified a sites SSL certifi-cate that the user can be sure that her connectionis safe.

However, this step alone is often not enough toprotect users. Sites that supply self-signed certifi-cates, or that exploit unpatched vulnerabilities inthe certificate handling code in the browsers can stilltrigger the display of the SSL lock icon, yet withoutproviding the user with the associated security pro-tections that they would normally expect.

Security researcher Moxie Marlinspike has repeat-edly attacked the SSL based chain of trust, revealingexploits that leverage both browser design flaws, aswell as social engineering attacks against end-users.His sslsniff [19] and sslstrip [20] tools automate thetask of performing a man-in-the-middle attacks, and

4


5/20

when supplied with a valid SSL certificate (obtainedvia a rogue CA for example), can be used to inter-cept users communications without triggering anybrowser warnings.

3 Big Brother in the Browser

Microsoft, Apple and Mozilla all include a number ofnational government CAs certificates in their respec-tive CA databases.6 These government CAs, like allother root CAs included by the browsers, must sat-isfy the requirements detailed in each browser ven-dors CA policies, and are included for legitimatereasons: Many governments embed cryptographicpublic keys in their national ID cards, or do notwish to outsource their own internal certificate issu-ing responsibilities to private companies.

While it may be quite useful for Estonian users ofInternet Explorer to trust their governments CA bydefault (thus enabling them to easily engage in se-cure online tasks that leverage their own national IDcard), the average resident of Lebanon or Peru hasfar less to gain by trusting the Estonian governmentwith the blanket power to issue SSL certificates forany website. Thus, users around the world are put ina position where their browser entrusts their privatedata, indirectly, to a number of foreign governmentswhom those individuals may not ordinarily trust.

As an illustrative and hypothetical example of

what is currently possible the Korean InformationSecurity Agency is able to create a valid SSL cer-tificate for the Industrial and Commercial Bank ofChina (whose actual certificate is issued by VeriSign,USA), that can hypothetically be used to performan effective man-in-the-middle attack against usersof Internet Explorer.

While this might at first seem like an extremelypowerful attack, there are several reasons why gov-ernments are unlikely to use their own CAs to per-form man in the middle attacks.

First, while some governments have succesfullypetitioned the browser vendors to include their CAcertificates, not all governments have done so. Thus,for example, the governments of Singapore, the

6For example, Microsofts Root Certificate Program in-cludes the governments of Austria, Brazil, Finland, France,Hong Kong, India, Japan, Korea, Latvia, Macao, Mexico,Portugal, Serbia, Slovenia, Spain, Switzerland, Taiwan, TheNetherlands, Tunisia, Turkey, United States and Uruguay[21].

United Kingdom and Israel (among many others) donot have state-run CAs that are included by any ofthe major browsers. These governments are there-fore unable to create their own fake certificates foruse in intelligence and other law enforcement inves-tigations where snooping on a SSL session might beuseful.

Second, due to the fact that the SSL chain of trustis non-repudiable, any government using its own CAto issue fake certificates in order to try and spy onsomeone elses communications will leave behind ab-solute proof of its involvement. That is, if the Span-ish government opts to issue a fake certificate forGoogle Mail, and the surveillance is somehow dis-covered, anyone with a copy of the fake certificateand a web browser can independently trace the op-eration back to the Spanish government.

4 Compelled Assistance

Many governments routinely compel companies toassist them with surveillance. Telecommunicationscarriers and Internet service providers are frequentlyrequired to violate their customers privacy pro-viding the government with email communications,telephone calls, search engine records, financialtransactions and geo-location information.

In the United States, the legal statutes definingthe range of entities that can be compelled to as-

sist in electronic surveillance by law enforcement7and foreign intelligence investigators8 are remark-ably broad.9 Examples of compelled assistance us-

7An order authorizing the interception of a wire, oral, orelectronic communication under this chapter shall [. . . ] directthat a provider of wire or electronic communication service,landlord, custodian or other person shall furnish the applicantforthwith all information, facilities, and technical assistancenecessary to accomplish the interception unobtrusively andwith a minimum of interference with the services that suchservice provider, landlord, custodian, or person is accordingthe person whose communications are to be intercepted. See:

18 U.S.C.

2518(4).8An order approving an electronic surveillance under thissection shall direct [. . . ] a specified communication or othercommon carrier, landlord, custodian, or other specified per-son [. . . ] furnish the applicant forthwith all information, fa-cilities, or technical assistance necessary to accomplish theelectronic surveillance in such a manner as will protect itssecrecy and produce a minimum of interference with the ser-vices that such carrier, landlord, custodian, or other personis providing that target of electronic surveillance. See: 50U.S.C. 1805(c)(2)(B).

9A thorough survey of the ways in which technology firms

5


6/20

ing these statutes include a secure email providerthat was required to place a covert back door inits product in order to steal users encryption keys[2], and a consumer electronics company that wasforced to remotely enable the microphones in a sus-pects auto-mobile dashboard GPS navigation unitin order to covertly record their conversations [23].

Outside of the United States, and other demo-cratic countries, specific statutory authority may beeven less important. The Chinese government, forexample, has repeatedly compelled the assistanceof telecommunications and technology companies inassisting it with its surveillance efforts [24, 25].

Just as phone companies and email providers canbe forced to assist governments in their surveillanceefforts, so too can SSL certificate authorities. Thecompelled certificate creation attack is thus one inwhich a government agency requires a domestic cer-

tificate authority to provide it with false SSL certifi-cates for use in surveillance.

The technical details of this attack are simple, anddo not require extensive explanation.10 Each CAalready has an infrastructure in place with which itis able to issue SSL certificates. In this compelledassistance scenario, the CA is merely required toskip the identity verification step in its own SSLcertificate issuance process.

For the purposes of our analysis, we assume thata CA cannot refuse to comply with a lawful court

order. However, it may be possible, via a warrantcanary or a similar technique, for a CA to communi-cate the existence of a secret court order to the Inter-net community. For example, a representitive fromone CA has informed us that his organizations dis-aster contigency plans include court orders, and thathis technical infrastructure includes a kill switchthat enables him to move to a new physical location,and nullify data at the data center [26]. We do notevaluate the effectiveness of such measures in this

can and have been compelled to violate their customers pri-vacy can be found in [22].10The legal issues relating to this kind of compelled assis-

tance are far more complex. Any US government agenciescompelling such CA assistance would almost certainly rely onthe assistance provisions highlighted earlier. However, it isunclear if such compelled assistance would be lawful, due tothe fact that it would interfere with the CAs ability to pro-vide identity verification services. Such compelled assistancewould also raise serious First Amendment concerns, due toto the fact that the government would be ordering the CA toaffirmatively lie about the identity of a certificate recepient.

paper.

When compelling the assistance of a CA, the gov-ernment agency can either require the CA to issue ita specific certificate for each website to be spoofed,or, more likely, the CA can be forced to issue a inter-mediate CA certificate that can then be re-used aninfinite number of times by that government agency,

without the knowledge or further assistance of theCA.

In one hypothetical example of this attack, theUS National Security Agency (NSA) can compelVeriSign to produce a valid certificate for the Com-mercial Bank of Dubai (whose actual certificate isissued by Etisalat, UAE), that can be used to per-form an effective man-in-the-middle attack againstusers of all modern browsers.

5 Surveillance AppliancesIn October 2009, one of the authors of this paper at-tended an invitation only conference for the surveil-lance and lawful interception industry in Washing-ton, DC.11 Among the many vendor booths on thetrade show floor was Packet Forensics, an Arizonabased company that sells extremely small, covertsurveillance devices for networks.

The marketing materials (an excerpt of which isincluded in this paper as Appendix A) for the com-panys 5-series device reveal that it is a 4 square inch

turnkey intercept solution, designed for defenseand (counter) intelligence applications, capable ofpacket modification, injection and replay capabil-ities at Gb/sec throughput levels. The companyproudly boasts that the surveillance device is per-fect for the Internet cafe problem. Most alarmingis the devices ability to engage in active man-in-the-middle attacks:

Packet Forensics devices are designed tobe inserted-into and removed-from busy

networks without causing any noticeableinterruption [. . . ] This allows you to con-ditionally intercept web, e-mail, VoIP and

11The author caused national headlines in December of2009, when he released an audio recording of one of the paneldiscussions at the same conference in which telecommunica-tions company employees bragged about the extent of theircooperation with government agencies, including the extentto which they provide consumers GPS location information[27, 28].

6


7/20

other traffic at-will, even while it remainsprotected inside an encrypted tunnel onthe wire. Using man-in-the-middle to in-tercept TLS or SSL is essentially an at-tack against the underlying Diffie-Hellmancryptographic key agreement protocol [. . . ]To use our product in this scenario, [gov-

ernment] users have the ability to import acopy of any legitimate key they obtain (po-tentially by court order) or they cangenerate look-alike keys designed to givethe subject a false sense of confidence in itsauthenticity.

The company has essentially packaged softwareequivalent to sslstrip into a 4 square inch appliance,ready for government customers to drop onto net-works, at a price that is so cost effective, theyre

disposable.When contacted by a journalist from Wired News

in March 2010, Packet Forensics spokesman RaySaulino initially denied the product performed asadvertised in its sales materials, or that anyone usedit. But in a follow-up call the next day, Saulinochanged his stance, telling the journalist that:

The technology we are using in our prod-ucts has been generally discussed in in-ternet forums and there is nothing specialor unique about it [. . . ] Our target com-munity is the law enforcement community[29].

Furthermore, while Packet Forensics has not dis-closed a list of its customers, the firms website re-veals that the 5-series device was authorized for ex-port to foreign firms and governments by the UnitedStates Bureau of Industry and Security on July 7,2009 [30].

6 Protecting UsersThe major web browsers are currently vulnerableto the compelled certificate creation attack, and wedo not believe that any of the existing privacy en-hancing browser add-ons sufficiently protect userswithout significantly impacting browser usability.

In an effort to significantly reduce the impact ofthis attack upon end-users, we have created Cert-lock, a lightweight add-on for the Firefox browser.

Our solution employs a Trust-On-First-Use (TOFU)policy (this is also known as leap-of-faith authenti-cation) [31, 32], reinforced with a policy that thecountry of origin for certificate issuing does notchange in the future. Specifically, our solution reliesupon caching CA information, that is then used toempower users to leverage country-level information

in order to make common-sense trust evaluations.In this section, we will outline the motivations

that impacted the design of our solution, discussour belief in the potential for users to make wisecountry-level trust decisions, and then explore thetechnical implementation details of our prototypeadd-on.

6.1 Design Motivations

The compelled certificate creation attack is a classic

example of a low probability, high impact event [33].The vast majority of users are extremely unlikely toexperience it, but for those who do, very bad thingsare afoot. As such, it is vital that any defensivetechnique have an extremely low false positive rate,yet be able to get the attention of users when anattempted SSL session hijacking is detected.

Most users are unlikely to know that this threateven exists, and so it is important that any protec-tive system not require configuration, maintenance,nor introduce any noticeable latency to users con-

nections. Given the low likelihood of falling victimto this attack, most rational users will avoid anyprotective technology that requires configuration orslows down their Web browsing [34].

Furthermore, to achieve widespread adoption(even moreso if the browser vendors are to add simi-lar functionality to their own products), any protec-tive technology must not sacrifice user privacy forsecurity. Information regarding users web brows-ing habits should not be leaked to any third party,even if that party is trusted or if it is done soanonymously. The solution must therefore be self-contained, and capable of protecting the user with-out contacting any remote servers.

We believe that most consumers are unaware ofhow SSL functions, what a CA is, the role it per-forms, and how many companies are trusted by theirbrowser to issue certificates. Expecting consumersto learn about this process, or to spend their timeevaluating the business practices and trustworthi-ness of these hundreds of firms is unreasonable. Nev-

7


8/20

ertheless, the security of the current system requireseach user to make trust decisions that that they areill equipped (nor willing) to perform.

We also believe that consumers do not directlytrust CAs. Aside from the biggest CAs such asVeriSign and large telecommunications firms localto their country,12 it is unlikely that consumers have

ever heard of the vast majority of the hundreds ofcompanies entrusted by their web browser to issuecertificates. Thus, it is just as unreasonable to ex-pect an American consumer to make a trust deci-sion regarding a certificate issued by Polish technol-ogy firm Unizeto Technologies as it is to expect aJapanese consumer to evaluate a certificate issuedby Bermuda based QuoVadis. However, both ofthese CAs are trusted by the major browsers, bydefault.

Consumers are simply told to look for the lock

icon. What happens in the browser to produce thatlock icon, is assumed by users to be reliable. Webelieve that it is our responsibility as security tech-nologists to make sure that what happens behindthe scenes does in fact protect the average usersprivacy and security.

This is not to say that we think that users areclueless merely that browsers currently providethem with little to no useful contextual informationwithout which such complex decisions are extremelydifficult.

6.2 Country-Based Trust

We believe that many consumers are quite capableof making basic trust decisions based on country-level information. We are not alone in this be-lief. Since March 2010, Google has been providingcountry-level warnings to users of its Google Mailservice when it detects that their account has beenaccessed from a potentially suspect IP address in adifferent country [35].

Thus, a consumer whose banking sessions are nor-

mally encrypted by a server presenting a certificatessigned by a US based CA might become suspiciousif told that her US based bank is now using a certifi-cate signed by a Tunisian, Latvian or Serbian CA.

To make this trust evaluation, she doesnt haveto study the detailed business policies of the foreignCA, she can instead rely on common sense, and ask

12For example, Verizon in the United States, DeutscheTelekom in Germany or Swisscom in Switzerland.

herself why her Iowa based bank is suddenly do-ing business in Eastern Europe. In order to em-power users to make such country-level evaluationsof trust, CertLock leverages the wealth of historicalbrowsing data kept by the browser.

Individuals living in countries with laws that pro-tect their privacy from unreasonable invasion have

good reason to avoid trusting foreign governments(or foreign companies) to protect their private data.This is because individuals often receive the great-est legal protection from their own governments, andlittle to none from other countries. For example, USlaw strictly regulates the ability of the US govern-ment to collect information on US persons. How-ever, the government can freely spy on foreignersaround the world, as long as the surveillance is per-formed outside the US. Thus, Canadians, Swedesand Russians located outside the United States have

absolutely no reason to trust the US government toprotect their privacy.

Likewise, individuals located in countries with op-pressive governments may wish to know if their com-munications with servers located in foreign democ-racies are suddenly being facilitated by a domestic(or state controlled) CA.

6.3 Avoiding False Positives

A simplistic defensive add-on aimed at protecting

users from compelled certificate creation attackscould simply cache all certificates encountered dur-ing browsing sessions, and then warn the user anytime they encounter a certificate that has changed.In fact, such an add-on, Certificate Patrol, alreadyexists [36].

The problem with such an approach is that it islikely to suffer from an extremely high false posi-tive rate. Each time a website intentionally changesits certificate, the browser displays a warning thatwill needlessly scare and soon desensitize users.There are many legitimate scenarios where certifi-cates change. For example: Old certificates expire;certificates are abandoned and or revoked after adata breach that exposed the server private key; andmany large enterprises that have multiple SSL accel-erator appliances serving content for the same do-main use a different certificate for each device [37].

By adopting a Trust-On-First-Use policy, we as-sume that if a website starts using a different certifi-cate issued by the same CA that issued its previous

8


9/20

certificate, there is no reason to warn the user. Thisapproach enables us to significantly reduce the falsepositive rate, while having little impact on our abil-ity to protect users from a variety of threats.

We also believe that there is little reason to warnusers if a website switches CAs within the samecountry. As our threat model is focused on a gov-

ernment adversary with the power to compel anydomestic CA into issuing certificates at will, we con-sider CAs within a country to be equals. That is,a government agency able to compel a new CA intoissuing a certificate could just as easily compel theoriginal CA into issuing a new certificate for thesame site. Since we have already opted to not warnusers in that scenario (described above), there is noneed to warn users in the event of a same-countryCA change.

By limiting the trigger of the warnings to country-

level changes, we believe that we have struck a bal-ance that will work in most situations.

6.4 Implementation Details

Our Certlock solution is currently implemented asan add-on to the Firefox browser.

The Firefox browser already retains history datafor all visited websites. We have simply modifiedthe browser to cause it to retain slightly more infor-mation. Thus, for each new SSL protected website

that the user visits, a Certlock enabled browser alsocaches the following additional certificate informa-tion:

A hash of the certificate.The country of the issuing CA.The name of the CA.The country of the website.The name of the website.The entire chain of trust up to the root CA.

When a user re-visits a SSL protected website,Certlock first calculates the hash of the sites certifi-cate and compares it to the stored hash from previ-ous visits. If it hasnt changed, the page is loadedwithout warning. If the certificate has changed, theCAs that issued the old and new certificates arecompared. If the CAs are the same, or from thesame country, the page is loaded without any warn-ing. If, on the other hand, the CAs countries differ,then the user will see a warning (See Figure 2).

At a high level, this algorithm is quite simple.However, there are a few subtle areas where somecomplexity is required.

Because governments can compel CAs to createboth regular site certificates as well as intermedi-ate CA certificates, any evaluation of a changed sitecertificate must consider the type of CA that issuedit.

While the web browser vendors do not vouch forthe trustworthiness of any of the root CAs that theyinclude, we believe it is reasonable to assume thatthe browser vendors do at least verify the countryinformation listed in each of their root CAs. There-fore, we are able to trust this information as we eval-uate changed certificates.

When Certlock detects a changed certificate, itmust also determine the type of CA that issued the

new certificate. If the new certificate was issued bya root CA, then Certlock can easily compare thecountry of the old certificates CA to the countryof the new root CA. However, if the new certificatewas issued by an intermediate CA, then we haveno way of verifying that the issuing CAs countryinformation is accurate.

As an illustrative and hypothetical example ofwhat is currently possible, the Spanish governmentcould compel a Spanish CA to issue an intermediateCA certificate that falsely listed the country of theintermediate CA as the United States. This rogueintermediate CA would then be used to issue sitecertificates for subsequent surveillance activities. Inthis hypothetical scenario, let us imagine that therogue CA issued a certificate for Bank Of Amer-ica, whose actual certificate was issued by VeriSignin the United States. Were CertLock to simplyevaluate the issuing CAs country of the previouslyseen Bank of America certificate, and compare itto the issuing country of the rogue intermediate CA(falsely listed as the United States), CertLock wouldnot detect the hijacking attempt. In order to detect

such rogue intermediate CAs, a more thorough com-parison must be conducted.

Thus, in the event that a new certificate has beenissued by an intermediate CA, Certlock follows thechain of trust up to the root CA, noting the coun-try of every CA along the path. If any one of theseintermediate CAs (or the root CA itself) has a dif-ferent country than the CA that issued the originalcertificate, then the user is warned.

9


10/20

Figure 2: The warning displayed to users of Certlock.

7 Threat Model Analysis

In this section, we outline several hypothetical sce-narios in which a man-in-the-middle attack maybe desired. In each example scenario, we examinethe governments available surveillance options, con-sider the suitability of the compelled certificate cre-ation attack, and evaluate the ability of CertLockto detect and thwart the attack. A condensed sum-mary of the threats that CertLock defends againstis also presented in Figure 3.

7.0.1 Scenario A

Actual CA VeriSign (USA)Compelled CA VeriSign (USA)Website Citibank (USA)Location of Suspect USASpying Government USA

In this scenario, the United States governmentcompels VeriSign to issue a certificate for use by a

law enforcement agency wishing to spy on commu-nications between a suspect located in the UnitedStates and Citibank, her United States based bank.

This attack is impossible for CertLock to detect,because the CA issuing the fake certificate is also thesame that issued the legitimate certificate. However,we believe that this scenario is extremely unlikely tooccur in the investigations of end users. This is be-cause if a government adversary is able to obtaina court order compelling VeriSigns cooperation, itcan just as easily obtain a court order compelling

Citibank to disclose the suspects account informa-tion.

While there are perhaps a few volunteer run In-ternet providers that will do anything possible toavoid delivering user data to government agents,we believe that the vast majority of corporationswill eventually comply. Outright refusal could po-tentially result in seizure of corporate assets, andthe jailing of executivesconsequences that profit

10


11/20

Spying Government Country of Actual CA CertLock Protects?

X X NoX Y Yes

Figure 3: A trust matrix evaluating CertLock. In short, the tool only protects users from compelledcertificate creation attacks when the Spying Government and the Country of the Actual CA are not the

same.

focused shareholders would likely wish to avoid.As a related example, in 2006, Google very pub-licly fought a subpoena from the US Deparment ofJustice requesting aggregate search request records.However, once a court ruled on the matter, the com-pany complied and provided the government with50,000 URLs from the Google search index [38]. Assuch, our threat model specifically excludes the rarecategory of ISPs willing to say no to government

requests at all costs, and instead focuses on typi-cal, law-abiding corporations that provide servicesto most users.

7.0.2 Scenario B

Actual CA VeriSign (USA)Compelled CA GoDaddy (USA)Website Citibank (USA)Location of Suspect USASpying Government USA

In this scenario, the United States governmentcompels GoDaddy, a CA located in the UnitedStates to issue a certificate for an intelligence agencywishing to spy on communications between a sus-pect located in the United States and a bank alsolocated in the United States (CitiBank), which ob-tained its legitimate SSL certificate from VeriSign.

Just as with Scenario A, this attack is extremelyunlikely to occur. This is because any governmentagency able to compel GoDaddy is also capable ofobtaining a court order to compel VeriSign or Bankof America. By simple reduction, any attacker ca-

pable of Scenario B is also capable of Scenario A.CertLock does not detect attacks of this type.

7.0.3 Scenario C

Actual CA VeriSign (USA)Compelled CA VeriSign (USA)Website Poker.com (USA)Location of Suspect USASpying Government USA

In this scenario, US law enforcement agents are in-vestigating a US-based online gambling website andthe US-based users of the service. The agents wishto first obtain evidence that illegal activity is occur-ing, by monitoring the bets as they are placed viaSSL encrypted sessions, before they later raid theoffices of the company and seize their servers. Inorder to surveil the communications between usersand the gambling website, law enforcement officials

compel VeriSign to issue an additional certificate forthe site, which is then used to intercept all commu-nications to and from the website.

In this scenario, where both ends of the SSL con-nection are under investigation by the government,the compelled certificate attack is a highly effectivemethod for covertly gathering evidence. However,because the issuing CA does not change, CertLockis unable to detect this attack and warn users.

In general, attack scenarios in which both the end-user and the website are under surveillance are be-yond the scope of our threat model.

7.0.4 Scenario D

Actual CA VeriSign (USA)Compelled CA TeliaSonera (Finland)Website Aktia Bank (Finland)Location of Suspect FinlandSpying Government Finland

In this scenario, a resident of Finland is accessingher Aktia Savings Bank online account, which ob-tained its legitimate SSL certificate from VeriSign, aUS firm. The Finnish intelligence services are inter-ested in getting access to the suspects online trans-action data, and thus seek to compel TeliaSonera,a domestic CA to issue a certificate for the surveil-lance operation.

This scenario is not identical to scenario A, how-ever it is quite similar. Again, if the Finnish govern-ment is able to compel a domestic CA into assistingit, we assume that it could just as easily compel the

11


12/20

Finnish bank into providing the suspects accountdetails. While we believe that this attack scenariois unlikely, should it occur, CertLock will detect it.

7.0.5 Scenario E

Actual CA VeriSign (USA)

Compelled CA TeliaSonera (Finland)Website Google Mail (USA)Location of Suspect FinlandSpying Government Finland

In this scenario, a US executive is travelling inFinland for business, and is attempting to accessher secure, US-based webmail account using the In-ternet connection in her hotel room. Finnish au-thorities wish to intercept her communications, butdue to Googles use of SSL by default for all webmailcommunications [39], the government must employa man-in-the-middle attack. This scenario is thus anideal candidate for a compelled certificate creationattack, since the Finnish authorities have no lever-age to compel the assistance of Google or VeriSign.This scenario is also one that is easily detected byCertLock.

7.0.6 Scenario F

Actual CA VeriSign (USA)Compelled CA VeriSign (USA)

Website CCB (China)Location of Suspect USASurveilling Government USA

In this scenario, a Chinese executive is travellingin the United States for business, and is attemptingto acccess her China Construction Bank account us-ing the Internet connection in her hotel room. USGovernment authorities wish to get access to her fi-nancial records, but are unwilling to let the Chinesegovernment know that one of their citizens is underinvestigation, and so have not requested her recordsvia official law enforcement channels.

This scenario is almost identical to scenario E,however, there is one key difference: The legitimatecertificate used by the Chinese bank was issued by aCA located in the United States and the US govern-ment has turned to the same US based CA to supplyit with a false certificate. Thus, while this scenariois an ideal candidate for a compelled certificate cre-ation attack, it is not one that can easily be detected

by looking for country-level CA changes. As such,CertLock is not able to detect attacks of this type.

7.1 Why Sites Should Consider the

Country of the CA They Use

Building on the information presented thus far in

this paper, we can draw the following conclusions:

Users are currently vulnerable to compelled cer-tificate creation attacks initiated by the gov-ernment of any country in which there is atleast one certificate authority that is trusted(directly or indirectly) by the browser vendors.

When users provide their private data to a com-pany, the government of the country in whichtheir data is located may be able to compel theprovider to disclose their private data.

When users provide their private data to a com-pany that holds the data in country X, but usesa SSL certificate provided by a CA in countryY, users are vulnerable to both the compelleddisclosure of their data by the government ofcountry X, and interception of their privatedata through a compelled certificate creationattack by country Y.

Thus, when a company that uses a certificateauthority located in a country different than theone in which it holds user data, it needlesslyexposes users data to the compelled disclosureby an additional government.

It is based on this that we believe that websitesbest serve their users when they rely on a SSL cer-tificate from a CA located in the same country inwhich their private data is stored.13 Unfortunately,this is not a widespread practice in the industry; in-stead American CAs totally dominate the certificate

market, and are used by many foreign organizations.As just one example a number of the big banks

in Pakistan, Lebanon and Saudi Arabia (countriesin which the US has a strong intelligence interest)all use certificates obtained from US-based CAs tosecure their online banking sites.

13For example, all of the Hungarian banks surveyed by theauthors use certificates provided by NetLock Ltd., a Hungar-ian CA.

12


13/20

It is because of the dominance of US CAs thatCertLock is not able to equally protect users fromdifferent countries. Certlock can effectively protectusers of US based services from compelled certifi-cate disclosure attacks performed by non-US gov-ernments. Thus, it is useful for Americans travellingout of the country who may be subject to surveil-

lance by the national government of the country inwhich they are travelling, and non-US persons whouse US-based services and who do not wish for theirown governments to get access to their data.

However, as long as companies around the worldcontinue to rely on SSL certificates issued by Ameri-can CAs, the US government will maintain the abil-ity to perform man in the middle attacks that arepractically impossible to detect with CertLock orany other country based detection mechanism.

8 Related Work

Over the past decade, many people in the securitycommunity have commented on the state of the SSLpublic key infrastructure, and the significant trustplaced in the CAs [40, 41, 42]. Crispo and Lomasalso proposed a certification scheme designed to de-tect rogue CAs [43], while the Monkeysphere projecthas created a system that replaces the CA architec-ture with the OpenPGP web of trust [44].

Ian Grigg has repeatedly sought to draw attention

to both the potential conflict of interest that someCAs have due to their involvement in other formsof surveillance, and the power of a court order tofurther compel these entities to assist governmentinvestigations [45, 46, 47]. In particular, in 2005,Grigg and Shostack filed a formal complaint withICANN over the proposal to award VeriSign controlof .net domain name registration. The two arguedthat:

Verisign also operates a Lawful Intercept

service called NetDiscovery. This service isprovided to ... [assist] government agen-cies with lawful interception and subpoenarequests for subscriber records.

We believe that [. . . ] VeriSign could be re-quired to issue false certificates, ones unau-thorised by the nominal owner. Such cer-tificates could be employed in an attack onthe users traffic via the DNS services now

under question. Further, the design of theSSL browser system includes a root listof trusted issuers, and a breach of any ofthese means that the protection affordedby SSL can now be bypassed.

We do not intend to pass comment on thelegal issues surrounding such intercepts.Rather, we wish to draw your attention tothe fact that VeriSign now operates undera conflict of interest. VeriSign serves boththe users of certificates as customers, andalso the (legal) interceptors of same [48].

In recent years, several browser-based tools havebeen created to help protect users against SSL re-lated attacks. Kai Engert created Conspiracy, aFirefox add-on that provides country-level CA infor-mation to end-users in order to protect them from

compelled certificate creation attacks. The Conspir-acy tool displays the flag of the country of each CAin the chain of trust in the browsers status bar [49].Thus, users must themselves remember the coun-try of the CAs that issue each certificate, and de-tect when the countries have changed. We believe,like Herley [34], that this is an unreasonable bur-den to place upon end-users, considering how rarelythe compelled certificate creation attack is likely tooccur.

Wendlandt et al. created Perspectives, a Firefox

add-on that improves the Trust-On-First-Use modelused for websites that supply self-signed SSL certifi-cates [50]. In their system, the users browser se-curely contacts one of several notary servers, who inturn independently contact the webserver and ob-tain its certificate. In the event that an attacker isattempting to perform a man in the middle attackupon the user, the fact that the attacker-suppliedSSL certificate, and those supplied by the Perspec-tives notary servers differ will be a strong indicatorthat something bad has happened.

Unfortunately, the Perspectives system requiresthat users provide the Perspectives notaries with areal-time list of the secure sites they visit.14 Al-though the schemes designers state that all servers

14Modern browsers already leak information about the se-cure web sites that users visit, as they automatically contactCAs in order to verify that the certificates have not been re-voked (using the OCSP protocol). While this is currently un-avoidable, we wish to avoid providing private user web brows-ing data to any additional parties.

13


14/20

adhere to a strict policy of never recording client IPaddresses, period, we still dont think it is a goodidea to provide users private web browsing data toa third party, merely based on the fact that theypromise not to log it.

Alicherry and Keromytis have improved upon thePerspectives design with their DoubleCheck system

[51], substituting Tor exit nodes for special notaryservers. Because the Tor network anonymizes theindividual users IP address, there is no way for theTor exit nodes to know who is requesting the certifi-cate for a particular SSL website. While the authorssolved the major privacy issues that plague the Per-spectives scheme, their choice of Tor carries its owncost: Latency. Their system adds an additional sec-ond of latency to every new SSL connection, and upto 15 seconds for visits to new self-signed servers.We believe that this additional latency is too much

to ask most users to bear, particularly if the chanceof them encountering a rogue CA is so low.

Herzberg and Jbara created TrustBar, a Firefoxadd-on designed to help users detect spoofed web-sites. The browser tool works by prominently dis-playing the name of the CA that provided the sitescertificate, as well as allowing the user to assign aper-site name or logo, to be displayed when theyrevisit to each site [52].

Tyler Close created Petname Tool, a Firefox add-on that caches SSL certificates, and allows users to

assign a per-site phrase that is displayed each timethey revisie the site in the future. In the event that auser visits a spoofed website, or a site with the sameURL that presents a certificate from a different CA,the users specified phrase will not be displayed [53].

In May 2008, a security researcher discoveredthat the OpenSSL library used by several popu-lar Linux distributions was generating weak cryp-tographic keys. While the two-year old flaw wassoon fixed, SSL certificates created on computersrunning the flawed code were themselves open toattack [54, 55]. Responding to this flaw, Germantechnology magazine Heise released the Heise SSLGuardian for the Windows operating system, whichwarns users of Internet Explorer and Chrome whenthey encounter a weak SSL certificate [56].

In December 2008, Stevens et al. demonstratedthat flaws in the MD5 algorithm could be used tocreate rogue SSL certificates (without the knowledgeor assistance of the CA). In response, CAs soon ac-celerated their planned transition to certificates us-

ing the SHA family of hash functions [13]. As anadditional protective measure, Marton Anka devel-oped an add-on for the Firefox browser to detectand warn users about certificate chains that use theMD5 algorithm for RSA signatures [57].

Jackson and Barth devised the ForceHTTPS sys-tem to protect users who visit HTTPS protected

websites, but who are vulnerable to man in the mid-dle attacks due to the fact that they do not type inthe https:// component of the URL [58]. This sys-tem has since been formalized into the Strict Trans-port Security (STS) standard proposal [59], to whichmultiple browsers are in the process of adding sup-port. While this system is designed to enable a web-site to hint to the browser that future visits shouldalways occur via a HTTPS connection, this mecha-nism could be extended to enable a website to locka website to a particular CA, or CAs of a specific

country.

9 Conclusion and Future Work

In this paper, we introduced the compelled certifi-cate creation attack and presented evidence thatsuggests that governments may be subverting theCA based public key infrastructure. In an effort toprotect users from these powerful adversaries, we in-troduced a lightweight defensive browser based add-

on that detects and thwarts such attacks. Finally,we use reductive analysis of governments legal ca-pabilities to perform an adversarial threat modelanalysis of the attack and our proposed defensivetechnology.

Our browser add-on is currently just a prototype,and we plan to improve it in the future. First, ourcurrently used warning dialog text is far from ideal,and could be greatly improved with the help of us-ability and user experience experts. We also planto explore the possibility of expanding the country-level trust model to regions, such as the EuropeanUnion, where, for example, residents of France maybe willing to trust Spanish CAs. Finally, We areconsidering adding a feature that will enable usersto voluntarily submit potentially suspect certificatesto a central server, so that they can be studied byexperts. Such a feature, as long as it is opt-in, doesnot collect any identifiable data on the user, andonly occurs when potentially rogue certificates arediscovered, would have few if any privacy issues.

14


15/20

Ultimately, the threats posed by the compelledcertificate creation attack cannot be completelyeliminated via our simple browser add-on. The CAsystem is fundamentally broken, and must be over-hauled. DNSSEC may play a significant role in solv-ing this problem, or at least reducing the numberof entities who can be compelled to violate users

trust. No matter what system eventually replacesthe current one, the security community must con-sider compelled government assistance as a realisticthreat, and ensure that any solution be resistant tosuch attacks.

10 Acknowledgements

Thanks to Kevin Bankston, Matt Blaze, Jon Callas,Allan Friedman, Jennifer Granick, Markus Jakob-sson, Dan Kaminsky, Moxie Marlinspike, Eli O,Adam Shostack for their useful feedback.

References

[1] Adi Shamir. Cryptography: State of the sci-ence. ACM A. M. Turing Award Lecture, June8 2003. awards.acm.org/images/awards/140/vstream/2002/S/s-pp/shamir_1files_

files/800x600/Slide8.html.

[2] Ryan Singel. PGP Creator Defends Hushmail.Wired News Threat Level Blog, November 192007. www.wired.com/threatlevel/2007/11/pgp-creator-def.

[3] T. Dierks and C. Allen. The TLS Protocol Ver-sion 1.0. RFC 2246 (Proposed Standard), Jan-uary 1999. Obsoleted by RFC 4346, updatedby RFCs 3546, 5746.

[4] Dan Kaminsky. Black Ops of PKI. 26thChaos Communication Congress, December

29 2009. events.ccc.de/congress/2009/Fahrplan/events/3658.en.html.

[5] Johnathan Nightingale. SSL Question Cor-ner. meandering wildly (blog), August 52008. blog.johnath.com/2008/08/05/ssl-question-corner/.

[6] Joshua Sunshine, Serge Egelman, Hazim Al-muhimedi, Neha Atri, and Lorrie F. Cranor.

Crying wolf: An empirical study of SSL warn-ing effectiveness. In Proceedings of the 18thUsenix Security Symposium, August 2009.

[7] Ed Felten. Web Certification Fail: BadAssumptions Lead to Bad Technol-ogy. Freedom To Tinker, February 23

2010. www.freedom-to-tinker.com/blog/felten/web-certification-fail-bad-

assumptions-lead-bad-technology.

[8] Mozilla. Potentially problematic CA practices, 2010. wiki.mozilla.org/CA:Problematic_Practices.

[9] Microsoft Root Certificate Program, January15 2009. technet.microsoft.com/en-us/library/cc751157.aspx.

[10] Mozilla CA Certificate Policy (Version 1.2).www.mozilla.org/projects/security/

certs/policy/.

[11] Apple Root Certificate Program.www.apple.com/certificateauthority/

ca_program.html.

[12] Craig Spiezle. Email conversation with author,February 15 2010.

[13] Marc Stevens, Alexander Sotirov, Jacob Appel-

baum, Arjen Lenstra, David Molnar, Dag ArneOsvik, and Benne Weger. Short chosen-prefixcollisions for MD5 and the creation of a rogueCA certificate. In Proceedings of the 29th An-nual International Cryptology Conference onAdvances in Cryptology, pages 5569, Berlin,Heidelberg, 2009. Springer-Verlag.

[14] Dan Kaminsky, Meredith L. Patterson, and LenSassaman. PKI Layer Cake: New Collision At-tacks Against the Global X.509 Infrastructure.

In Proceedings of Financial Cryptography andData Security - 14th International Conference(FC 2010), 2010.

[15] Alexander Sotirov and Mike Zusman. Breakingthe Security Myths of Extended ValidationSSL Certificates. BlackHat USA, 2009.www.blackhat.com/presentations/bh-

usa-09/SOTIROV/BHUSA09-Sotirov-

AttackExtSSL-SLIDES.pdf .

15


16/20

[16] Moxie Marlinspike. More Tricks For Defeat-ing SSL In Practice. BlackHat USA, 2009.www.blackhat.com/presentations/bh-usa-

09/MARLINSPIKE/BHUSA09-Marlinspike-

DefeatSSL-SLIDES.pdf .

[17] Marsh Ray and Steve Dispensa.

Renegotiating tls, November 4 2009.extendedsubset.com/wp-uploads/2009/

11/renegotiating_tls_20091104_pub.zip .

[18] Stuart E. Schechter, Rachna Dhamija, AndyOzment, and Ian Fischer. The emperors newsecurity indicators. In SP 07: Proceedingsof the 2007 IEEE Symposium on Security andPrivacy, pages 5165, Washington, DC, USA,2007. IEEE Computer Society.

[19] Moxie Marlinspike. sslsniff, July 3 2009. www.

thoughtcrime.org/software/sslsniff/.

[20] Moxie Marlinspike. sslsniff, December 182009. www.thoughtcrime.org/software/sslstrip/.

[21] Windows Root Certificate Program Members,November 24 2009. download.microsoft.com/download/1/4/f/14f7067b-69d3-473a-

ba5e-70d04aea5929/windows\%20root\

%20certificate\%20program\%20members.

pdf.[22] Christopher Soghoian. Caught in the cloud:

Privacy, encryption, and government backdoors in the web 2.0 era. In Journal onTelecommunications and High Technology Law,Forthcoming.

[23] Declan McCullagh. Court to FBI: No spyingon in-car computers. CNET News, Novem-ber 19 2003. news.cnet.com/2100-1029_3-5109435.html.

[24] John Markoff. Surveillance of skype messagesfound in china. The New York Times, Octo-ber 1 2008. www.nytimes.com/2008/10/02/technology/internet/02skype.html.

[25] Andrew Jacobs. China requires censorship soft-ware on new pcs. The New York Times, June 82009. www.nytimes.com/2009/06/09/world/asia/09china.html.

[26] Eddy Nigg. Email conversation with author,March 27 2010.

[27] Christopher Soghoian. 8 Million Reasons forReal Surveillance Oversight. Slight Paranoiablog, December 1 2009. paranoia.dubfire.net/2009/12/8-million-reasons-for-

real-surveillance.html .[28] Kim Zetter. Feds Pinged Sprint GPS Data 8

Million Times Over a Year. Wired News ThreatLevel Blog, December 1 2009. www.wired.com/threatlevel/2009/12/gps-data/ .

[29] Ryan Singel. Law Enforcement Appliance Sub-verts SSL. Wired News Threat Level Blog,March 24 2010. www.wired.com/threatlevel/2010/03/packet-forensics/ .

[30] Packet Forensics. Export and Re-Export Re-

quirements, 2009. www.packetforensics.com/export.safe.

[31] Frank Stajano and Ross J. Anderson. The res-urrecting duckling: Security issues for ad-hocwireless networks. In Proceedings of the 7thInternational Workshop on Security Protocols,pages 172194, London, UK, 2000. Springer-Verlag.

[32] Jari Arkko and Pekka Nikander. Weak authen-tication: How to authenticate unknown princi-

pals without trusted parties. In Bruce Chris-tianson, Bruno Crispo, James A. Malcolm, andMichael Roe, editors, Security Protocols Work-shop, volume 2845 of Lecture Notes in Com-puter Science, pages 519. Springer, 2002.

[33] Matthieu Bussiere and Marcel Fratzscher. Lowprobability, high impact: Policy making andextreme events. Journal of Policy Modeling,30(1):111121, 2008.

[34] Cormac Herley. So long, and no thanks for the

externalities: the rational rejection of securityadvice by users. In NSPW 09: Proceedings ofthe 2009 workshop on New security paradigmsworkshop, pages 133144, September 2009.

[35] Pavni Diwanji. Detecting suspicious ac-count activity. The Official Gmail Blog,March 24 2010. gmailblog.blogspot.com/2010/03/detecting-suspicious-account-

activity.html.

16


17/20

[36] Certificate patrol, 2010. patrol.psyced.org/.

[37] Dan Kaminsky. Email conversation with au-thor, February 28 2010.

[38] Nicole Wong. Judge tells DOJ No onsearch queries. The Official Google Blog,March 17 2006. googleblog.blogspot.com/

2006/03/judge-tells-doj-no-on-search-

queries.htmll.

[39] Sam Schillace. Default https access forGmail. The Official Gmail Blog, January12 2010. gmailblog.blogspot.com/2010/01/default-https-access-for-gmail.html.

[40] Daniel Kahn Gillmor. Technical Archi-tecture shapes Social Structure: an ex-ample from the real world, February 212007. lair.fifthhorseman.net/~dkg/tls-

centralization/.

[41] Peter SJF Bance. Ssl: Whom do you trust?,April 20 2005. www.minstrel.org.uk/papers/2005.04.20-ssl-trust.pdf.

[42] Ed Gerck. Overview of Certifica-tion Systems: X.509, CA, PGP andSKIP. Black Hat Briefings, July 7 1999.www.blackhat.com/presentations/bh-

dc-09/Marlinspike/BlackHat-DC-09-

Marlinspike-Defeating-SSL.pdf .

[43] Bruno Crispo and Mark Lomas. A certificationscheme for electronic commerce. In In SecurityProtocols International Workshop, page pages.Springer-Verlag, 1996.

[44] Monkeysphere, 2010. web.monkeysphere.info/.

[45] Ian Grigg. VeriSigns conflict of interest cre-ates new threat. Financial Cryptography (blog),September 1 2004. financialcryptography.com/mt/archives/000206.html.

[46] Ian Grigg. PKI considered harmful. Octo-ber 14 2008. iang.org/ssl/pki_considered_harmful.html.

[47] Ian Grigg. Why the browsers must changetheir old SSL security (?) model. Finan-cial Cryptography (blog), March 24 2010.financialcryptography.com/mt/archives/

001232.html.

[48] Ian Grigg and Adam Shostack. VeriSignand Conflicts of Interest, February 22005. forum.icann.org/lists/net-rfp-verisign/msg00008.html.

[49] Kai Engert. Conspiracy A Mozilla Fire-fox Extension, March 18 2010. kuix.de/

conspiracy/.[50] Dan Wendlandt, David G. Andersen, and

Adrian Perrig. Perspectives: improving ssh-style host authentication with multi-path prob-ing. In ATC08: USENIX 2008 Annual Tech-nical Conference on Annual Technical Confer-ence, pages 321334, Berkeley, CA, USA, 2008.USENIX Association.

[51] Mansoor Alicherry and Angelos D. Keromytis.Doublecheck: Multi-path verification against

man-in-the-middle attacks. In ISCC 2009:IEEE Symposium on Computers and Com-munications, pages 557563, Piscataway, NJ,USA, 2009. IEEE.

[52] Amir Herzberg and Ahmad Jbara. Security andidentification indicators for browsers againstspoofing and phishing attacks. ACM Trans. In-ternet Technol., 8(4):136, 2008.

[53] Tyler Close. Petname tool, 2005. www.waterken.com/user/PetnameTool/.

[54] David Ahmad. Two Years of Broken Crypto:Debians Dress Rehearsal for a Global PKICompromise. IEEE Security and Privacy, 6:7073, September 2008.

[55] Scott Yilek, Eric Rescorla, Hovav Shacham,Brandon Enright, and Stefan Savage. Whenprivate keys are public: results from the 2008Debian OpenSSL vulnerability. In Proceedingsof the 9th ACM SIGCOMM conference on In-ternet measurement conference, pages 1527,New York, NY, USA, 2009. ACM.

[56] The H Security. heise SSL Guardian:Protection against unsafe SSL certifi-cates, July 4 2008. www.h-online.com/security/features/Heise-SSL-Guardian-

746213.html.

[57] Marton Anka. SSL Blacklist 4.0, Jan-uary 31 2010. www.codefromthe70s.org/sslblacklist.aspx.

17


18/20

[58] Collin Jackson and Adam Barth. Forcehttps:protecting high-security web sites from networkattacks. In WWW 08: Proceeding of the 17thinternational conference on World Wide Web,pages 525534, New York, NY, USA, 2008.ACM.

[59] Jeff Hodges, Collin Jackson, and AdamBarth. Strict Transport Security, December 182009. lists.w3.org/Archives/Public/www-archive/2009Dec/att-0048/draft-hodges-

strict-transport-sec-06.plain.html.

A Appendix

The following two scanned pages are a limited por-tion of Packet Forensics marketing materials, suf-

ficient to document the products features and thecompanys statements. We believe that our inclu-sion of this content for scholarly purposes is solidlyprotected by fair use.

18


19/20


20/20

Documents

Certied Lies: Detecting and Defeating GovernmentInterception Attacks Against SSL