The Browser Threat Model


This document describes in overview form the threat model facing the browser. For a fast reading, skip to the 3rd section.

What is a Threat Model?

The construction of the threat model is an essential, critical, phase in the construction of the overall security model for a system [Modelling]; the threat model is one of the factors that feeds into the security model, which latter takes and analyses the costs and benefits of defending against each listed threat [Modelling];

Note. Defences against particular threats are more part of the security model than the threat model. To complete and link the discussion, defences are shown in the sideboxes. They are, however, not part of the formal threat model, and this document thus includes more than the threat model per se.

Attack Trees

An attack tree is "a systematic method to characterize system security based on varying attacks. Each attack tree enumerates and elaborates the ways that an attacker could cause the event to occur. Each path through an attack tree represents a unique attack on the enterprise [Hollingworth]." I've found relatively little in the literature on threat models, but there is some literature on Attack Trees [AT]. Attack trees differ from the approach of this document. Attack trees document all potential and plausible attacks, and then leave it up to the security model to identify and deal with each attack. In contrast, this document is currently structured to start from the known, validated threats to Internet users in general and browsing in particular. In this sense, it considers theoretical attacks as less important, a priori.

An attack tree formatted as a mindmap is presented at http://iang.org/maps/browser_attack_tree.html [Maps]. The attack tree is not as structured nor complete as the above literature suggests. For one, it does not develop the attacks in its full process, rather, each attack is simply listed and left to the reader for full development.

User Base

What are the users doing?

What sort of threat model / security model can we construct in the face of an uncertain user base for the Mozilla certificate and browsing architecture?

Why now?

Evolution of the Threats

Criticism of the secure browsing security model has been ever-present, but lacked momentum until recently due to no serious threats to browsing. Most criticism has centered on the key exchange part of the protocol, grounded as it is in a public key infrastructure ("PKI") known as the Certificate Authority model [PKI].

During recent years, serious attempts at revisionism of security architecture policy have been attemtped. The cornerstone of these efforts has been to move from the deductive, no-risk school representative in SSL to the inductive, opportunistic school representative of SSH. These efforts at re-aligning security architecture to economic risks have gained momentum from the market success of the SSH model, and the arisal of phishing as a serious breach of the secure browsing security model.

Original Models

The original security model for browsing never developed and validated a proper threat model [WYTM?]. Instead, the model used was variously assumed, guessed at, and labelled, ex poste, the Internet Threat Model ("ITM"). This has been known as weak for some time, yet only recently has it been recognised as wrong and also one of the root cause of weaknesses in secure browsing.

Without a viable threat model, the construction of a security model is unfounded. That is, it's a building of concrete and steel, of some significant height and weight, yet laid on sand dunes. Will it sink, will it roll over, or will it collapse?

The weakness of a laid-out threat model for browsing has been recognised for some time. Since then, unaddressed threats have grown worse, but there has been relatively little momentum to address these threats.

Mozilla Foundation

Frank Hecker's Working Drafts of MF Policy

The core policy proposal:


the proposed details of the policy and how it would be implemented:


the metapolicy:


In 2004, the Mozilla Foundation, a publisher of open source browser software, embarked on the selection of a policy for the addition of new Certificate Authorities. This new policy project has recognised and called for a remedy to the lack of a threat model; this present document is this author's informal attempt to fill that gap.


What's Missing

Frank Hecker wrote:
> Note that for a full treatment we
> really need to consider email and
> downloading executable code as well,
> since those are the other two major
> uses for certificates in the context
> of Mozilla and related software.

Things to consider

Frank Hecker wrote:
> Some things I've found so far include
> Nelson's posting "On a crypto security
> threat model for mozilla users":
> http://www.google.com/groups?selm=c0mp01%24cip1%40ripley.netscape.com&output=gplain
> and John Meyers' posting in a thread
> Nelson started about "On criteria
> for trusting public root CAs":
> http://www.google.com/groups?selm=9dadnUFVDPKtVbTdXTWc-g%40speakeasy.net&output=gplain
> There are more useful comments in these
> threads and others.


Firstly, the general major Internet threats that are clear and present today are laid out. As a Threat Model strives to be complete, it necessarily should start out broad, and then narrow down (fast readers can skip this section).

Then, the Internet threats are taken as the context and background for the next section, being those threats that are relevant to the browser.

General Threats to Users of the Internet

Follows is a list of the major threats to Internet users. These are major because they are frequent, and costly. In other words, these are validated threats.

However, not all of them relate to browser security, (and some are not specific even to the Internet). For threats against browsing, see the next section.

Threat #I1 - Phishing

Phishing is defined as the sending of emails to victims in a spam-like broadcast, attempting to elicit account information. In general, the email purports to come from a targeted institution, and includes a URL which the victim is tricked into following.

Threat #I2 - Viruses

Viruses that pass from one mailer to another.

Viruses can pass from any active agent to another; the essence is a service that accepts connections and performs some processing.

Threat #I3 - Spam

Spam email is an economic problem. As email is free, and presumes that any person can send any other person an email without prior relationship, it creates the environment for costless advertising (in approximate marginal terms).

Threat #I4 - DOS

Denials of Service are generally launched at upstream elements and stop users reaching assets.

Threat #I5 - Cracking

The major issues with Cracking into boxes on the net (a.k.a., hacking) are that:

  1. The box itself suffers, due to the cost of cleaning out any damage or changes made;

  2. The box can be used as a staging point for a further attack against other assets; and

  3. Information on the box such as card or personal details can be stolen.

Cracking is frequent. Last August, in one month, 12,892 Linux servers were breached, and 4,626 Windows servers also were cracked [Linux].

Other Threats

The following threats are not considered to be Internet threats, per se, but are relevant (tenuously or directly) to the browsing environment, as they effect browser users.

Financial Fraud

Identity Theft

This threat is more asymmetric to the net, but for reasons of its relationship and classification to other threats, and its increase in prevalence to (mostly) american commerce, it needs to be recognised [Identity].

Ponzis and Pyramids

In the online payments world, many scams of the Ponzi and Pyramid nature are conducted. These generally involve a game or investment, with some promise of fortunes to be made [P+P].

Threats to Browser Users

This section refines the above from a broad Internet list to a specific browser list.

Threat #B1 - Phishing

Phishing is primarily a browser threat. The browser is the tool of choice for accessing financial accounts.

How it is done

The attack has many phases. It has a very good filtering characteristic, as spam techniques allow a broadcast invitation, and the victims self-filter themselves through the website. [Semantic Attacks].


Normally a mail is sent, and a URL is presented. There are several aspects.

The mail can be plaintext or it can be in HTML. If in HTML, the URL can be bogus by means of hiding the real URL in the HTML. For example,

    <a href="http://dodgy.free.com/scam.php"> www.bankofamerica.com </a>

If the email is in plaintext, the URL is normally one that relates to a "like" name. E.g., www.boa-fraud-control.com.

Elements of both can be used. Often, there are many valid URLs mixed with a few invalid ones.


The essence of the email is to convince the user to click on the URL, as presented by the email. Once clicked through, the browser launches directly, and presents the site.

Note. The click through feature is only partially to blame here, as even if the user were forced to copy the URL by hand, there would be ways to encourage the user to continue along that path. It is also worth bearing in mind that consumers are unlikely to give up their click through feature.

The Spoof Site

On the site itself, a series of more or less convincing claims, or a convincing copy of the original targeted site, entice the user to enter account number/name and password. Once these details are captured by the spoof site, some form of closure is attempted.

Defences against Phishing

There are many proposed defences, but this author finds the following one most worthwhile:

The browser should present to the user, clearly and provocatively, the bona fides of the site concerned.

In general, a spoof site has no bona fides. It does not generally use SSL, so there is no cert info to present and verify.

Therefore, this must become the salient fact: that the site has no bona fides. Which means, in order to make this fact plain to the viewer, there should be a presentation of other sites' bona fides, such that an absence becomes a warning in and of itself.

So, space should be set aside on the chrome to present the brand and provenance of the site. That is, issues such as the name, number of times visited, the certificate issuer, the branding of the certificate issuer, the nature of the SSL, etc, should be presented for all sites of any bona fides [Ye&Smith] [SSLBar].

Currently, the reverse is done; making it easy for phishing - the nature of the site's bona fides is suppressed and hidden; the only indication is that there may or may not be a small lock symbol shown in an open or closed state.

The Crime

Once the account details are obtained, the account can be raided. The theft can either be done immediately, or delayed to another time when there is more money in the account (or a coordinated sweep can be attempted across many accounts).

The Launder

The money is transferred directly to another account. This will often be a way-station account, from there, the funds are transferred again, and potentially again and again [Wash].


Attempts at phishing happen daily, in bulk mailings. Often, the same attempt is tried with multiple variations. Actual statistics of frequency of victims and losses are hard to come by [aphwg]. [mi2g] [Crowne] [Texas]. But, the evidence of frequent attempts indicates some success is occurring.

Threat #B2 - Eavesdropping

Passive listening to browsing activity in general is a possible attack. The attacker is sometimes known as Eve.

How it is done

For Eve to listen to web traffic, there needs to be access to either an open broadcast network (unswitched ethernet or 802.11b), or access to a router node. Having access to a router node of some form implies either an insider attack or a cracking attack.

Defences against Eavesdropping

The easy fix to eavesdropping is to encrypt traffic. Opportunistic cryptography organises an open key exchange at the start, and carries on using that key, or new keys bootstrapped from it.

Protocols and algorithms of any strength will generally add value, as they act to push the attacker, Eve, off to some easier target. In practice, encryption algorithms and protocols are strong, and are rarely broken and breached for gain (some exceptions include 802.11b's WEP and DVD's scheme).

Other defences are to secure the network from easy access. Employment of switches, WEP over 802.11b, and secure routing nodes goes a long way to making eavesdropping harder.


It is very hard to validate eavesdropping attacks. For the most part, the frequency seems to be below the noise level, i.e., unmeasurable. This is in direct opposition to the public perception of the Internet as a wild and lawless place where all of the user's traffic can be read.

There have been isolated incidents of eavesdropping. Here are some examples, of anecdotal strength:


The attack is hard to monetarise due to its poor filtering characteristics. Browsing involves a huge amount of traffic, and searching for the key parts of a form submission, or scanning downloads for key information requires a lot of work. Further, as access to larger amounts of data is needed, security gets tougher, either at the node level, or due to side-effects.

For this reason, eavesdropping is normally conducted as a privacy breach - the search for some specific privacy information against some stated target, rather than a monetary breach such as scanning for cards.

This makes it harder to detect as there is no direct and costly crime or event that points back to the original breach.

In practice, little evidence leads to this as a serious monetary threat, but it may be more of a privacy threat due to its difficulty in detection.

Threat #B3 - MITM

In contrast to the above, the the man in the middle attack ("MITM") is an active attack, requiring the attacker (known as Mallory) to send and/or block packets.

Defences against MITM

There are, in general, three defences:

First is to generate self-signed certificates, which establish a relationship dependent on the first connection. This is the SSH approach. The vulnerability is then dependent on the first connection, which for a site of some value is generally a fair bet.

Second, use a CA-signed cert, which establishes the bona fides externally, and thus overcomes the first-connection vulnerability. This is the SSL approach. However, it shifts the burden across to the CA to "get it right," and it adds large costs to the system operators, which reduce deployment.

Third, verify the establishment of the key exchange over a separate channel. This is the OpenPGP web of trust approach. It requires the two parties to communicate the information over the phone.

All three have been successful and have no measurable track record of being breached. SSH's method wins on points due to the lack of cost (and thus much greater takeup) and also, SSH grew in response to actual attacks on sessions (eavesdropping of passwords for system admin accounts) and presumably has more validation. OpenPGP's method relies on the existent of an alternate channel such as telephone, also, on the carefulness of the users. The CA method attempts to make it easy for the end user, but raises costs, and shows no return on investment.

How it is done

Opportunistic crypto leaves open the weakness of the MITM. This is because opportunistic crypto does not authenticate the other party, so a third party can sit in the middle and complete the protocol both ways.


MITM is an expensive attack as it leaves tracks. It's also an active attack, and thus presents evidence of wrong doing, in the act. Unlike eavesdropping, which is a passive attack, MITM potentially provides the victims with sufficient evidence without needing to capture the sessions of the attacker "in the act" as it were.

Therefore, we can presume that Mallory will generally only use the technique of MITM where he is unconcerned about being caught. For example, one of the following scenarios:

  1. It is a "demonstration," not a crime. This happens for example at hacker conferences, and on university campuses.

  2. The criminal is out of reach: sufficiently remote and untouchable so as not to care (so, not on an open ethernet, but rather, hacked into a router box, or if wardriving, too far away to be seen).

  3. The attacker is unpunishable even if caught. This would generally imply that the attacker has many other resources, and only chooses this method so as to be surreptitious [HRC].

Of the above, the only serious threat is the remote attack. This limits the attack to the hacked routers, or potentially the wardriver.

The unpunishable attacker can generally attack other ways as well, so the essence is on limiting and detecting that avenue if possible. The demonstration attacker is a nuisance, but not a serious input into a security model.

Because of their poor filtering characteristics, and their high riskiness deriving from active tracks (evidence), they remain the tools of only a select few fringe attackers with obscure interests.


There are extraordinarily few reports of MITMs.

Some reports come from demonstrations and from demonstration kits that are available for MITMing the popular protocols. Others come from conferences of hackers and the like, and are akin to "mucking around in a safe environment."

There are no known reports of MITMs over the SSH network, which is arguably the highest prized network to attack, as it could create the pool of hacked machines to further deploy attacks. Likewise, OpenPGP and SSL have not experienced any successful MITMs that have been reported.

DNS has been "poisoned" several times, resulting in email and web sites being diverted. The former was for a privacy attack (salacious emails being revealed in political campaign) and the latter was a demonstration of the weakness of DNS.

In essence, MITMs remain the stuff of legend.

Threat #B4 - DOS

Denial of service is conducted by causing many controlled boxes to flood a website with requests. These boxes are controlled via one of two methods, being cracking, or viruses.

As the DOS is conducted by copying the activities of normal users, in the act of browsing, it is a hard attack to address. For this reason, it is often considered to be the last threat to be dealt with, if at all.


[Modelling] See also extracted notes at Security Modelling http://www.financialcryptography.com/mt/archives/000109.html in the FC Blog.

[Modelling] An example: Threat Analysis of the Domain Name System (DNS)

[Hollingworth] 02-Hollingworth.pdf

[AT] Twan van der Schoot's list:

This introductory article is good: John Viega and Gary McGraw, Attack Trees Software Development, August 2002. It includes a partial attack tree for SSH.

Bruce Schneier, Attack Trees Dr. Dobb's Journal, December 1999. Also this figure: Attack Nodes. This may also be the Dr. Dobb's reference.

Bruce Schneier, Secrets and Lies chapter 21.

Moore, Ellison and Linger of CMU/SEI have written quite a serious 'manual' MEL of how to do attack modeling using attack trees. It is certainly worth reading.

A mister Moberg has written his thesis on an attack tree model for Lotus Notes I hadn't had the time for a careful read, but skimming its contents suggest that it is quite informative. It is the only serious analysis I've found of a live/existing product of any size.

In Niels Ferguson's book the "safe-cracking" example in chapter 1 probably hasn't escaped your attention. Although I do agree that it is a trivial example.

draft-convery-bgpattack-00 (Convery, Cook, Franz) (IETF draft presenting all known attack vectors into or using BGP, presented in "Attack Tree" format.)

[Maps] See notes at Maps Page on usage of the applet.

[PKI] Ian Grigg, PKI considered harmful, surveys and lists the criticisms on the PKI.

[WYTM?] WYTM?, or, "What's your threat model?," a rant written for the cryptography list.

[Linux] Globe and Mail (Technology) reports statistics from a London security firm, mi2g: "During August, 67 per cent of all successful and verifiable digital attacks against on-line servers targeted Linux, followed by Microsoft Windows at 23.2 per cent. A total of 12,892 Linux on-line servers running e-business and information sites were successfully breached in that month, followed by 4,626 Windows servers." Whether mi2g are credible as reporters of statistics is questioned by VMyths.

[Identity] E.g., ID theft victims face tough bank fights.

[P+P] The difference between the two is subtle, and often, elements of both are involved. Pyramids require victims to explicitly sign up other victims in order to achieve payoff, whereas Ponzis pay out early investors from the money of later participants. Pyramids differ from multi-level marketing (MLM) by the absence of a real product.

[Semantic Attacks] Bruce Schneier calls these Semantic Attacks, where the attacker targets the interface between the machine and user.

[Ye&Smith] Ye and Smith, Trusted Path for Browsers, 11th Usenix security symp, 2002. Advertisement by Sean Smith: "we also built this into Mozilla, for Linux and Windows. http://www.cs.dartmouth.edu/~pkilab/demos/countermeasures/ sws@cs.dartmouth.edu


[Wash] In the trade, each transfer is called a wash because the transfer comes in and goes out immediately. At some point in the laundering process, the funds are combined with those from other accounts, similarly stolen. Washes will generally take the money through to another financial system, or through several financial systems, so as to further obscure the trail. For example, from the offshore gold community to the onshore bank transfer world, or vice versa.

[aphwg] The anti-phishing WG says in its monthly Phishing Attack Trends Report that there were 176 unique phishing attacks in January, up from 116 the previous month. See my blog entry for more details.

[mi2g] These merchants of doom and worry predict "110 in less than a year" mi2g but I think this is too low.

[Crowne] Phishing Attack on Crowne Gold.

[Texas] Cost of Phishing - Case in Texas lists a convicted phisher as taking $75,000 from 400 victims.

[HRC] This observation results from the Human Rights Community, where workers have reported direct MITM attacks by governments on their activities, where being caught resulted in shrugging of shoulders.