Proposed changes to the add-on update mechanism
Dave Townsend
the automatic add-on update mechanism. There are a couple of proposals
knocking about and I would like to get some feedback from you if you
host your own add-ons and updates (on your own website, not on
addons.mozilla.org).
First can you say why you don't host on AMO (doesn't need to be long
winded, just want to get an idea of the main issues here).
On the website you host at, do you already use https to deliver the
update.rdf and/or the xpi's.
If not what would you think of a plan to only allow automatic updates to
extensions that host their update.rdf on a https server (certificates
appear to cost from $20 per year), would you be happy to pay that extra
money, or move to AMO?
Finally if you still want/need insecure delivery of update files, what
would you think of adding an extra step of adding a digital signature to
your update.rdf (hopefully just a few commands but still added work
nontheless).
There is a bug open on this however I'd ask that you keep your replies
here, or to me directly if you prefer then I can collate some overview.
Cheers
Mossop
eric...@yahoo.com
1. AMO provides very limited download statistics. Post-Remora, the download counts aren't even public anymore. I realize some people don't want them public, but why do they get preferential treatment over those of us who want them made public? Moreover, weekly and total download counts are very limited. Ideally, I'd be able to generate awstats/webalizer/google analytics-style reports on AMO. Therefore, I host my extensions on AMO except the ones for which I need download statistics.
2. The permissible application versions are too restrictive. I used to be able to mark my extensions as valid for pre-FF-1.0. That stopped working a few weeks ago out of the blue when I tried updating an extension [note: I just checked and AMO accepts FF 0.7 as a valid version now--so maybe this isn't a problem anymore].
Another example: one of my extensions is compatible with Netscape 7.x. but AMO doesn't accept that. Only 8.x is valid even though people still use 7.x, and Netscape is already up to 9.0b1.
>>On the website you host at, do you already use https to deliver the update.rdf and/or the xpi's.<<
Some yes, some no.
>>If not what would you think of a plan to only allow automatic updates to
extensions that host their update.rdf on a https server (certificates
appear to cost from $20 per year), would you be happy to pay that extra
money, or move to AMO?<<
Personally, I would pay the money for the cert, but I don't think https-only updates is a good idea (curiously, you only said UPDATES and not XPI INSTALLATIONS, too). I understand what you are trying to accomplish--preventing MITM attacks, download corruption, and other attacks of which I'm probably not aware--but this is unduly restrictive IMHO. Have you ever known anyone to install an extension that's been compromised due to MITM? If you answered yes, is it an exceptional case or a common one? I'm going to assume it's rather exceptional. If so, why would you cripple the entire community and force this down their throats for a few bad apples in the batch?
There are plenty of people who won't have the time, knowledge, desire, or ability to purchase SSL certs (e.g., they are teenagers without much money; they host their XPIs on a free hosting site like geocities or googlepages which don't permit ssl certs; etc). So your other option for these people is to host on AMO, to which I ask this question: will AMO approve & host *any* XPI? Does it have restrictions on what it will host? Will it host controversial and/or possibly "illegal" extensions such as ones relating to hacking, pirating, porn, spyware, adware, spamware? If not, then what option do people who author such extensions have?
>>Finally if you still want/need insecure delivery of update files, what
would you think of adding an extra step of adding a digital signature to
your update.rdf (hopefully just a few commands but still added work
nontheless).<<
IMHO, this is much better than a required https-only update, but once again I ask what is the motivation for this? Is it to solve a problem that hasn't happened in the wild yet (or perhaps it's happened to .000001% of extension users worldwide?)
To make an analogy, do you think it would be wise for browsers to be changed so that they absolutely won't submit <input type="password"/> over non-SSL connections? This is not a rhetorical question :)
Eric H. Jung
Grimholtz
Benjamin Smedberg
> Personally, I would pay the money for the cert, but I don't think
> https-only updates is a good idea (curiously, you only said UPDATES and
> not XPI INSTALLATIONS, too). I understand what you are trying to
> accomplish--preventing MITM attacks, download corruption, and other
> attacks of which I'm probably not aware--but this is unduly restrictive
> IMHO. Have you ever known anyone to install an extension that's been
> compromised due to MITM? If you answered yes, is it an exceptional case
> or a common one? I'm going to assume it's rather exceptional. If so, why
> would you cripple the entire community and force this down their throats
> for a few bad apples in the batch?
There have been published MITM attack scenarios against major
extensions,http://paranoia.dubfire.net/2007/05/remote-vulnerability-in-firefox.html
which require nothing more than an untrusted WiFi connection (which are very
common).
> There are plenty of people who won't have the time, knowledge, desire, or
> ability to purchase SSL certs (e.g., they are teenagers without much
> money; they host their XPIs on a free hosting site like geocities or
> googlepages which don't permit ssl certs; etc). So your other option for
> these people is to host on AMO, to which I ask this question: will AMO
> approve & host *any* XPI? Does it have restrictions on what it will host?
> Will it host controversial and/or possibly "illegal" extensions such as
> ones relating to hacking, pirating, porn, spyware, adware, spamware? If
> not, then what option do people who author such extensions have?
Who are you designing for? The user who could become potentially compromised
by using a public WiFi connection, or the extension author? I think that we
have no choice but to err on the side of caution and prevent insecure update
by default.
> To make an analogy, do you think it would be wise for browsers to be
> changed so that they absolutely won't submit <input type="password"/>
> over non-SSL connections? This is not a rhetorical question :)
I think it's worth considering, yes. But note that the extension update flaw
is much more serious because it is automatic and extensions are
fully-privileged code. Sending a password is a conscious action and the
compromise is limited to the password itself.
--BDS
Dave Townsend
points, Benjamin has answered the others better than I could I think.
> Personally, I would pay the money for the cert, but I don't think
> https-only updates is a good idea (curiously, you only said UPDATES
> and not XPI INSTALLATIONS, too).
My main focus for the moment is the auto-update process. Installation is
essentially a user initiated process, they choose an extension and have
to click to install and agree that install. The updating however is a
simple "here's an update, want it?" with no additional info. Ideally we
still want it to be that easy to the user, but be sure that they are
getting the update securely.
But yes ideally at some point soon the installation process should be
looked at as well.
> If so, why would you cripple the entire community and
> force this down their throats for a few bad apples in the batch?
I think that "cripple" is a strong word. I certainly don't want to
cripple anyone, I actually host my own addons on a non-secure server so
any changes made will affect me personally. I'm getting feedback on
these questions precisely so we can get a feel for how much impact
certain changes would have on the add-ons community. If the majority of
responses are against requiring ssl certificates then believe me I will
fight tooth and nail to avoid it.
That said if we can make the update process a lot more secure with a
very small amount of inconvenience to the add-on author then I think
that would be fantastic.
Mossop
20after4
when I have the time.
I would recommend a compromise:
If SSL becomes required for updates, I would hope that it will only
disable automatic updates. Continue to notify users of any available
non-ssl updates and include an explanation of the security risk (in
simple terms.) The update dialog should also provide a link to the add-
on authors' website so that the user can manually force the update if
they are comfortable with taking the risk.
It might be a good idea to incorporate some of the visual cues that
are being used in other parts of the browser ui. Provide more details
in the install and update dialogs, such as a certificate status icon
and an inverse "insecure" indicator for non-ssl installations.
While I'm on the subject of secure extension installation, there is a
small issue with the software installation authorization process that
has been bugging me for a while. I will try to explain in the next
paragraph; I hope this makes sense, let me know if I should
clarify....
After attempting to install an extension by clicking an install link
on some arbitrary website, a"top-bar" pops up to block the
unauthorized domain. Something like "Firefox prevented this site
(www.whatever.com) from asking you to install software..... [edit
options]." ...In order to install the extension, the user must click
the edit options button and then add the domain to a list of
authorized sites, then repeat the process to install the extension.
In my opinion this "edit options" button should have an "authorize
just this once" type of option similar to the popup blocker's "show it
this time" menu option. Maybe I want to install the extension without
granting any further trust to the domain which is hosting said
extension. Providing such an option seems very minor but it's an easy
change that I think would be very worthwhile.
Ok I'm done with my little rant. I hope that the extension update
issue can be cleared up without being overly restrictive. I agree that
it would seem like a bad idea to automate a process that is inherently
insecure, however, completely disabling non-ssl installation and/or
updates seems to be a bit heavy handed. I think that users need to be
given a choice but also educated about the consequences of that choice.
rob...@accettura.com
> Hi all, we are currently investigating ways to improve the security of
> the automatic add-on update mechanism. There are a couple of proposals
> knocking about and I would like to get some feedback from you if you
> host your own add-ons and updates (on your own website, not on
> addons.mozilla.org).
>
Have on occasion, but not official releases. Why? Very simple, it
takes to long to get things approved on amo. By the time it goes out
there's likely an update.
Dave Townsend
> If SSL becomes required for updates, I would hope that it will only
> disable automatic updates. Continue to notify users of any available
> non-ssl updates and include an explanation of the security risk (in
> simple terms.) The update dialog should also provide a link to the add-
> on authors' website so that the user can manually force the update if
> they are comfortable with taking the risk.
That's certainly an option that I've already brought up, really as a
last case scenario in my opinion. We have the problem that warning
dialogs tend to be a pretty poor solution for any security situation. I
think it's fairly well recognised that users rarely read and even more
rarely actually understand what they are saying.
> Maybe I want to install the extension without
> granting any further trust to the domain which is hosting said
> extension. Providing such an option seems very minor but it's an easy
> change that I think would be very worthwhile.
Check out https://bugzilla.mozilla.org/show_bug.cgi?id=252830
Cheers
Dave
eric...@yahoo.com
I'm going to discuss both David and Benjamin's replies in a single email.
Benjamin Smedberg <benj...@smedbergs.us> wrote:
>>There have been published MITM attack scenarios against major extensions,http://paranoia.dubfire.net/2007/05/remote-vulnerability-in-firefox.html which require nothing more than an untrusted WiFi connection (which are very common).<<
Thanks for the link. I'm not doubting the attacks are possible. If you re-read my comment, you'll see I was questioning their frequency. But maybe that's not really the point because if they're not common now, perhaps they'll become common in the future.
My point is this: DNS attacks like the one shown in the linked video (changing a system's HOSTS file) have been the source for potential problems for many years--indeed, well before Firefox existed. Have we seen browsers or other user-agents (newsreaders, ftp clients, etc) change because of
it? No. Have we seen operating systems change because of it? Not to my knowledge. On the contrary, early versions of Windows didn't even support a HOSTS file. Later, support was added but IIRC one had to reboot before the changes took effect. And today, the HOSTS file behaves on Windows similarly to how it behaves on Unix (albeit, I don't know if you need administrator privileges on Windows to change it like you do on *nix). You'd think if HOSTS-based attacks were such a problem, many OS vendors would have dropped support for the HOSTS file--MS & *nix alike.
>>Who are you designing for? The user who could become potentially compromised by using a public WiFi connection, or the extension author? I think that we have no choice but to err on the side of caution and prevent insecure update by default.<<
Designing what? My extension? The Extension Manager updates system? I don't understand your point here. In any case, you always have a choice, and
designing for worst-case scenarios isn't always appropriate; it can reduce freedom and accessibility and increase cost and complexity. In the words of Thomas Jefferson, "I would rather be exposed to the inconveniences attending too much liberty than to those attending too small a degree of it."
>>>>To make an analogy, do you think it would be wise for browsers to be changed so that they absolutely won't submit <input type="password"/> over non-SSL connections? This is not a rhetorical question :)<<<<
>>I think it's worth considering, yes.<<
Really? Do you think the web would be as successful as it is today if browsers had been designed this way from the start? I sure don't. Firefox extension development is still in its infancy. Things like FUEL, sqlLite instead of RDF, etc. will make extension development more accessible. Forced SSL-updates will make extension development *less*
accessible.
>>But note that the extension update flaw is much more serious because it is automatic and extensions are fully-privileged code. Sending a password is a conscious action and the compromise is limited to the password itself.<<
I don't agree. Compromised passwords have ruined fortunes (bank accounts, investment firms, identity theft), contributed to criminal prosecutions, aided civil lawsuits, ended marriages and families, and caused other problems that go far beyond "the password itself." Yet we still see non-SSL and non-hashed password submission in login forms when a simple browser and/or protocol change could end that. Why do you think that is? Similarly, HTTP still permits Basic Authentication over non-SSL transports (i.e., unencrypted credentials transmission). Why? Tim Berners-Lee writes:
"[Basic Authentication] is based on the
assumption that the connection between the client
and the server can be regarded as a trusted carrier. As this is not generally true on an open network,
the basic authentication scheme should be used accordingly."
In other words, caveat emptor.
From: Dave Townsend <dtow...@mozilla.com>
>>My main focus for the moment is the auto-update process. Installation is essentially a user initiated process, they choose an extension and have to click to install and agree that install.<<
I don't see how that mitigates risk. The risk to installation vs. updating appear the same to me. The user is prompted in both cases. Yes, installation is user-initiated, but once the installation or update is accepted, both are subject to the exact same attacks... no?
>>I think that "cripple" is a strong
word. I certainly don't want to cripple anyone<<
Perhaps that was a poor choice of words. Nevertheless, I do see SSL-mandated installations and updates as yet another barrier to entry for extension authors, the more so because of the historical problem with AMOs approval delays. It was (is?) commonplace for authors to finish an extension and not have it published for 6 weeks or more--check the archives in both this list and project...@mozdev.org. I realize AMO is a part of a non-profit, largely volunteer organization, so I am not criticizing AMO for a lack of resources, but you must take this reality into account when you are about to (practically, for many authors) make AMO a dependency in the extension publication process.
>>That said if we can make the update process a lot more secure with a very small amount of inconvenience to the add-on author then I think that would be fantastic.<<
Agreed. Please
just consider the practical consequences before you do so.
>>certificates appear to cost from $20 per year<<
It's worth mentioning that wildcard certificates are $200+/year. This might only be relevant to hosting organizations like mozdev.org, but might also be important to commercial institutions that have multiple products lines or multiple lines of business. Additionally, I've only ever seen the godaddy/starfield technologies class 2 certificate authority sell certs for $20/year. It would be nice if there was more than one option out there at that kind of price just in case that CA increases their pricing. Do you know of others?
By the way, what do you propose the extension manager do about invalid, expired, revoked, or unverifiable (e.g., self-signed) certificates? If you deny the update/installation, how do developers test their extensions without jumping through hoops, thereby increasing barriers to entry?
Eric H. Jung (Grimholtz)
Board of Directors -
Mozdev.org
[These views are mine alone and do not represent those of mozdev.org or the mozdev.org community]
Dave Townsend
> My point is this: DNS attacks like the one shown in the linked video
> (changing a system's HOSTS file) have been the source for potential
> problems for many years--indeed, well before Firefox existed. Have we
> seen browsers or other user-agents (newsreaders, ftp clients, etc)
> change because of it? No. Have we seen operating systems change
> because of it? Not to my knowledge. On the contrary, early versions
> of Windows didn't even support a HOSTS file. Later, support was added
> but IIRC one had to reboot before the changes took effect. And today,
> the HOSTS file behaves on Windows similarly to how it behaves on Unix
> (albeit, I don't know if you need administrator privileges on Windows
> to change it like you do on *nix). You'd think if HOSTS-based attacks
> were such a problem, many OS vendors would have dropped support for
> the HOSTS file--MS & *nix alike.
In terms of browsers (as in web page viewers) and newsreaders, ftp
clients etc., they are a little out of the picture here. They do not
execute the code that they retrieve from the remote site with a high
level of privileges (assuming no bugs exist in the software). Extensions
are executed with full chrome privileges which of course means being
able to do pretty much anything to the machine that the running user can.
Even then, I believe those app types all support some kind of secure
connection because even without code execution in certain situations it
is important to know that the data you are sending/receiving from the
remote site really comes from where you expect it to. Users are
(hopefully) learning to only pass certain information on to secure
sites. Why would we automatically ask a user to install code when we
cannot verify the source of that code?
The HOSTS file changing is as I understand it merely a simplification of
the threat, i.e. it proves what you can do once you intercept a DNS request.
>
>>> Who are you designing for? The user who could become potentially
>>> compromised by using a public WiFi connection, or the extension
>>> author? I think that we have no choice but to err on the side of
>>> caution and prevent insecure update by default.<<
>
> Designing what? My extension? The Extension Manager updates system? I
> don't understand your point here. In any case, you always have a
> choice, and designing for worst-case scenarios isn't always
> appropriate
I believe Benjamin's point was the design of the Extension Manager. And
I agree that designing for the worst-case is not always appropriate.
Considering the worst-case is always appropriate. We are considering
that worst-case here and finding out just what sort of impact various
solutions would have on freedom and accessibility.
>>> My main focus for the moment is the auto-update process.
>>> Installation is essentially a user initiated process, they choose
>>> an extension and have to click to install and agree that
>>> install.<<
>
> I don't see how that mitigates risk. The risk to installation vs.
> updating appear the same to me. The user is prompted in both cases.
> Yes, installation is user-initiated, but once the installation or
> update is accepted, both are subject to the exact same attacks... no?
It mitigates the risk involved with an add-on update. The plan here is
to try to reach a point where once an add-on is installed (lets ignore
how insecure that install was for the moment), the user can get prompted
for and allow updates that are almost guaranteed to come from the same
author that wrote the add-on already installed (almost because poor key
management etc. can foil the most secure of systems).
Yes it doesn't address that the initial install may be insecure and yes
that should be addressed.
>>> I think that "cripple" is a strong
> word. I certainly don't want to cripple anyone<<
>
> Perhaps that was a poor choice of words. Nevertheless, I do see
> SSL-mandated installations and updates as yet another barrier to
> entry for extension authors, the more so because of the historical
> problem with AMOs approval delays.
Agreed. Obviously with the best will in the world, improving the
security will introduce a barrier. The goal is to make that barrier as
tiny as possible and to make the security improvement large in
proportion to it.
> By the way, what do you propose the extension manager do about
> invalid, expired, revoked, or unverifiable (e.g., self-signed)
> certificates? If you deny the update/installation, how do developers
> test their extensions without jumping through hoops, thereby
> increasing barriers to entry?
This is an excellent point that needs to be taken into account. In
general if a certificate is invalid then the update information must be
rejected. Development presents a special case of course. However if some
form of certification is required for updates, surely the developer
would have that in place already before testing their update system?
Mossop
Dan Veditz
> (curiously, you only said UPDATES and not XPI INSTALLATIONS, too).
We are concerned about both, but they are separate problems and this thread
is about updates. As to installs the AMO site, for example, is completely
SSL solely for the purpose of preventing a MITM server from offering
trojaned software. The install trigger includes a cryptographic hash of the
extension so that it can be safely downloaded from a non-SSL mirror server.
Another mechanism we implemented is support for signed installations and
several companies with reputations to lose have taken advantage of this.
We have long considered requiring all .xpis to be correctly signed but that
would strangle the extension developer community.
In addition, as Benjamin notes installation is a one-time intentional act,
hard to base a wide-spread MITM attack on. Update checks, bu comparison,
happen invisibly and frequently enough to base an attack on.
-Dan Veditz
eric...@yahoo.com
connection because even without code execution in certain situations it
is important to know that the data you are sending/receiving from the
remote site really comes from where you expect it to. <<
Right, I agree. And whenever possible, extensions should be installed and updated over SSL. I just don't think this should be mandated by the extension manager.
>>We are considering that worst-case here and finding out just what sort of impact various solutions would have on freedom and accessibility.<<
I appreciate that, and I appreciate you posing this to the newsgroup.
>>However if some form of certification is required for updates, surely the developer would have that in place already before testing their update system?<<
Many developers (including me) develop in non-production environments that don't have SSL certificates or, at best, have self-signed certificates. Please at least consider a preference to disable SSL-required updates.
Finally, I'd like to make clear that I'm not in any way *against* updates/installations over SSL. Indeed, as I wrote before, I think updates/installations should occur over SSL whenever possible. My issue is only that this should not be made a *requirement*. That said, I don't hold this issue dear to my heart and life will go on regardless of the outcome :)
Thanks for asking for feedback, Mossop.
Eric
Ted Mielczarek
3 years. I stopped using AMO because it kind of sucked at the time.
I'm sure lots of things are better now, but I just haven't bothered to
go back and put my extensions there. One thing that I do like about
having things on my own server is that I can easily see the number of
downloads and update requests.
I don't use SSL because I've never needed it for anything, and it
seems like a bother to setup.
-Ted
Nils Maier
> First can you say why you don't host on AMO (doesn't need to be long
> winded, just want to get an idea of the main issues here).
* Limit audience-extensions
* sandbox-review-public system currently sucks a lot as many reviewers
lack knowledge IMO.
> On the website you host at, do you already use https to deliver the
> update.rdf and/or the xpi's.
No, as this would be a too great burden. Not the setup itself, but
acquiring and "maintaining" certs.
Self-signed certs suck in this context, so that's not an option either.
Furthermore I do not feel like getting my privacy invaded because I have
to get a commercial cert which would require me to make my data
available (yeah, I'm kinda paranoid sometimes :p).
Not to mention the associated costs. I don't feel like spending any
money for an extension that I intensionally make available to less 100
people only.
> If not what would you think of a plan to only allow automatic updates to
> extensions that host their update.rdf on a https server (certificates
> appear to cost from $20 per year), would you be happy to pay that extra
> money, or move to AMO?
No and No.
I would instead code workarounds into FX, maybe my own update service,
if I were forced to do so.
> Finally if you still want/need insecure delivery of update files, what
> would you think of adding an extra step of adding a digital signature to
> your update.rdf (hopefully just a few commands but still added work
> nontheless).
I would surely use such signatures if they were already available.
Currently signing XPIs requires a cert. The install-trigger checksums or
proposed Link-Fingerprints lack identity/authentication/authorization.
A dpkg/rpm like signature system (using GPG, self-signed critical
extension certs or the like) would be a step in the right direction IMO
(referring to the m.d.t.crypto thread).
In general I wouldn't limit the scope non-AMO extensions only.
I may happen at some point that AMO itself and/or an author account is
compromised. Signatures might help here too if done correctly.
Nils
Rob Marshall
http:// update URL, though I'm not sure why as I haven't needed to
update them yet.
I'd love to have a way of being secure without going SSL, as getting a
dedicated IP would roughly double my (admittedly cheap) hosting cost.
It'd be even nicer if I could do it automatically from PHP. ;)
Hopefully this would be adaptable to the app update service, as I'm also
running that over plain HTTP and that's probably not good either...
--
Rob Marshall [tH]
eric...@yahoo.com
Bruce Schneier, famed cryptographer, coincidentally has an apropos piece in his monthly CRYPTO-GRAM newsletter this month titled "Rare Risk and Overreactions". This gets back to my comments about the frequency of this kind of attack. I'd really like to hear your opinion about Bruce's piece:
[ originally appeared in Wired
http://www.wired.com/politics/security/commentary/securitymatters/2007/05/securitymatters_0517 ]
Rare Risk and Overreactions
Everyone had a reaction to the horrific events of the Virginia Tech
shootings. Some of those reactions were rational. Others were not.
A high school student was suspended for customizing a first-person
shooter game with a map of his school. A contractor was fired from his
government job for talking about a gun, and then visited by the police
when he created a comic about the incident. A dean at Yale banned
realistic stage weapons from the university theaters -- a policy that
was reversed within a day. And some teachers terrorized a sixth-grade
class by staging a fake gunman attack, without telling them that it was
a drill.
These things all happened, even though shootings like this are
incredibly rare; even though -- for all the press -- less than one
percent of homicides and suicides of children ages 5 to 19 occur in
schools. In fact, these overreactions occurred, not despite these facts,
but *because* of them.
The Virginia Tech massacre is precisely the sort of event we humans tend
to overreact to. Our brains aren't very good at probability and risk
analysis, especially when it comes to rare occurrences. We tend to
exaggerate spectacular, strange and rare events, and downplay ordinary,
familiar and common ones. There's a lot of research in the
psychological community about how the brain responds to risk -- some of
it I have already written about -- but the gist is this: Our brains are
much better at processing the simple risks we've had to deal with
throughout most of our species' existence, and much poorer at evaluating
the complex risks society forces us to face today.
Novelty plus dread equals overreaction.
We can see the effects of this all the time. We fear being murdered,
kidnapped, raped and assaulted by strangers, when it's far more likely
that the perpetrator of such offenses is a relative or a friend. We
worry about airplane crashes and rampaging shooters instead of
automobile crashes and domestic violence -- both far more common.
In the United States, dogs, snakes, bees and pigs each kill more people
per year than sharks. In fact, dogs kill more humans than any animal
except for other humans. Sharks are more dangerous than dogs, yes, but
we're far more likely to encounter dogs than sharks.
Our greatest recent overreaction to a rare event was our response to the
terrorist attacks of 9/11. I remember then-Attorney General John
Ashcroft giving a speech in Minnesota -- where I live -- in 2003, and
claiming that the fact there were no new terrorist attacks since 9/11
was proof that his policies were working. I thought: "There were no
terrorist attacks in the two years preceding 9/11, and you didn't have
any policies. What does that prove?"
What it proves is that terrorist attacks are very rare, and maybe our
reaction wasn't worth the enormous expense, loss of liberty, attacks on
our Constitution and damage to our credibility on the world stage.
Still, overreacting was the natural thing for us to do. Yes, it's
security theater, but it makes us feel safer.
People tend to base risk analysis more on personal story than on data,
despite the old joke that "the plural of anecdote is not data." If a
friend gets mugged in a foreign country, that story is more likely to
affect how safe you feel traveling to that country than abstract crime
statistics.
We give storytellers we have a relationship with more credibility than
strangers, and stories that are close to us more weight than stories
from foreign lands. In other words, proximity of relationship affects
our risk assessment. And who is everyone's major storyteller these
days? Television. (Nassim Nicholas Taleb's great book, "The Black
Swan: The Impact of the Highly Improbable," discusses this.)
Consider the reaction to another event from last month: professional
baseball player Josh Hancock got drunk and died in a car crash. As a
result, several baseball teams are banning alcohol in their clubhouses
after games. Aside from this being a ridiculous reaction to an
incredibly rare event (2,430 baseball games per season, 35 people per
clubhouse, two clubhouses per game. And how often has this happened?),
it makes no sense as a solution. Hancock didn't get drunk in the
clubhouse; he got drunk at a bar. But Major League Baseball needs to be
seen as doing *something*, even if that something doesn't make sense --
even if that something actually increases risk by forcing players to
drink at bars instead of at the clubhouse, where there's more control
over the practice.
I tell people that if it's in the news, don't worry about it. The very
definition of "news" is "something that hardly ever happens." It's when
something isn't in the news, when it's so common that it's no longer
news -- car crashes, domestic violence -- that you should start worrying.
But that's not the way we think. Psychologist Scott Plous said it well
in "The Psychology of Judgment and Decision Making": "In very general
terms: (1) The more *available* an event is, the more frequent or
probable it will seem; (2) the more *vivid* a piece of information is,
the more easily recalled and convincing it will be; and (3) the more
*salient* something is, the more likely it will be to appear causal."
So, when faced with a very available and highly vivid event like 9/11 or
the Virginia Tech shootings, we overreact. And when faced with all the
salient related events, we assume causality. We pass the Patriot Act.
We think if we give guns out to students, or maybe make it harder for
students to get guns, we'll have solved the problem. We don't let our
children go to playgrounds unsupervised. We stay out of the ocean
because we read about a shark attack somewhere.
It's our brains again. We need to "do something," even if that
something doesn't make sense; even if it is ineffective. And we need to
do something directly related to the details of the actual event. So
instead of implementing effective, but more general, security measures
to reduce the risk of terrorism, we ban box cutters on airplanes. And
we look back on the Virginia Tech massacre with 20-20 hindsight and
recriminate ourselves about the things we *should have done.
Lastly, our brains need to find someone or something to blame. (Jon
Stewart has an excellent bit on the Virginia Tech scapegoat search, and
media coverage in general.) But sometimes there is no scapegoat to be
found; sometimes we did everything right, but just got unlucky. We
simply can't prevent a lone nutcase from shooting people at random;
there's no security measure that would work.
As circular as it sounds, rare events are rare primarily because they
don't occur very often, and not because of any preventive security
measures. And implementing security measures to make these rare events
even rarer is like the joke about the guy who stomps around his house to
keep the elephants away.
"Elephants? There are no elephants in this neighborhood," says a neighbor.
"See how well it works!"
If you want to do something that makes security sense, figure out what's
common among a bunch of rare events, and concentrate your
countermeasures there. Focus on the general risk of terrorism, and not
the specific threat of airplane bombings using liquid explosives. Focus
on the general risk of troubled young adults, and not the specific
threat of a lone gunman wandering around a college campus. Ignore the
movie-plot threats, and concentrate on the real risks.
Irrational reactions:
http://arstechnica.com/news.ars/post/20070502-student-creates-counter-strike-map-gets-kicked-out-of-school.html
or http://tinyurl.com/2dbl67
http://www.boingboing.net/2007/05/03/webcomic_artist_fire.html
http://www.yaledailynews.com/articles/view/20843
http://yaledailynews.com/articles/view/20913
http://www.msnbc.msn.com/id/18645623/
Risks of school shootings (from 2000):
http://www.cdc.gov/HealthyYouth/injury/pdf/violenceactivities.pdf
Crime statistics -- strangers vs. acquaintances:
http://www.fbi.gov/ucr/05cius/offenses/expanded_information/data/shrtable_09.html
or http://tinyurl.com/2qbtae
Me on the psychology of risk and security:
http://www.schneier.com/essay-155.html
Risk of shark attacks:
http://www.oceanconservancy.org/site/DocServer/fsSharks.pdf
Ashcroft speech:
http://www.highbeam.com/doc/1G1-107985887.html
Me on security theater:
http://www.schneier.com/essay-154.html
Baseball beer ban:
http://blogs.csoonline.com/baseballs_big_beer_ban
Nicholas Taub essay:
http://www.fooledbyrandomness.com/nyt2.htm
http://www.telegraph.co.uk/opinion/main.jhtml?xml=/opinion/2007/04/22/do2201.xml
or http://tinyurl.com/3bewfy
VA Tech and gun control:
http://abcnews.go.com/International/wireStory?id=3050071&CMP=OTC-RSSFeeds0312
or http://tinyurl.com/25js4o
http://www.cnn.com/2007/US/04/19/commentary.nugent/index.html
VA Tech hindsight:
http://news.independent.co.uk/world/americas/article2465962.ece
http://www.mercurynews.com/charliemccollum/ci_5701552
Jon Stewart video:
http://www.comedycentral.com/motherload/player.jhtml?ml_video=85992
Me on movie-plot threats:
http://www.schneier.com/essay-087.html
Another opinion:
http://www.socialaffairsunit.org.uk/blog/archives/000512.php
This essay originally appeared on Wired.com, my 42nd essay on that site.
http://www.wired.com/politics/security/commentary/securitymatters/2007/05/securitymatters_0517
or http://tinyurl.com/26cxcs
French translation:
http://archiloque.net/spip.php?rubriques2&periode=2007-06#
Justin Dolske
> If SSL becomes required for updates, I would hope that it will only
> disable automatic updates. Continue to notify users of any available
> non-ssl updates and include an explanation of the security risk (in
> simple terms.)
I think that the vast majority of users don't want to (and shouldn't
have to) think about security and trust issues when updating an
extension, be it automatic or manual.
> In my opinion this "edit options" button should have an "authorize
> just this once" type of option similar to the popup blocker's "show it
> this time" menu option.
This isn't really the right thread to open that can of worms. Making
Firefox behave like older IE versions by allowing "Click here to install
malware from random site!" (sorry, make that "Click here to install an
important Windows update!") isn't something that should be done hastily.
If at all.
Justin
Justin Dolske
> Thanks for the link. I'm not doubting the attacks are possible. If you re-read my comment, you'll see I was questioning their frequency. But maybe that's not really the point because if they're not common now, perhaps they'll become common in the future.
I disagree strongly with the point you seem to be making.
The frequency of how often a particular attack is executed should have
NO bearing on how security issues are addressed. [Although it's fair to
consider the difficulty of executing an attack, which may happen to
correlate with the frequency.]
Comparing this issue with DNS attacks is apples and oranges. Addressing
flaws in wide-spread, entrenched protocols is enormously difficult and
complex. There's a solution here that's easy to fix and deploy (but has
negative impact for some extensions).
Justin
Nils Maier
> 20after4 wrote:
>
>> If SSL becomes required for updates, I would hope that it will only
>> disable automatic updates. Continue to notify users of any available
>> non-ssl updates and include an explanation of the security risk (in
>> simple terms.)
>
> I think that the vast majority of users don't want to (and shouldn't
> have to) think about security and trust issues when updating an
> extension, be it automatic or manual.
And I think that this vast majority of users is then better off
installing extensions just from trusted sources like AMO anyway.
I just want to point out that this is about secure update channels and
not user education.
I fully disagree with your statement that the majority of users
shouldn't have to think about security and trust issues. That's exactly
why http-only phishing sites still work and trojans requiring
user-interactions are actually installed.
Sure, reducing the number of things a user might have to care about will
prevent some issues and may create greater user satisfaction; on the
other hand there is the danger that the users stops to care all together
because he thinks the "vendor" will protect him, even from the user's
own stupidity.
>> In my opinion this "edit options" button should have an "authorize
>> just this once" type of option similar to the popup blocker's "show it
>> this time" menu option.
>
> This isn't really the right thread to open that can of worms. Making
> Firefox behave like older IE versions by allowing "Click here to install
> malware from random site!" (sorry, make that "Click here to install an
> important Windows update!") isn't something that should be done hastily.
> If at all.
>
> Justin
Firefox allowing to add "trusted" installation sites is the exact same
thing except for persistence of the choice...
Not getting your point.
However, I'm not really pro "allow once" because there is actually no
real difference and this will cause even more confusion/irritation at
best IMO.
(oh, and it's off-topic of course, but I really had to write this :p)
Nils
Nils Maier
> David,
>
> Bruce Schneier, famed cryptographer, coincidentally has an apropos piece in his monthly CRYPTO-GRAM newsletter this month titled "Rare Risk and Overreactions". This gets back to my comments about the frequency of this kind of attack. I'd really like to hear your opinion about Bruce's piece:
>
> [ originally appeared in Wired
>
> http://www.wired.com/politics/security/commentary/securitymatters/2007/05/securitymatters_0517 ]
>
> Rare Risk and Overreactions
>
I don't really see how this is about overreactions.
There is a non attack vector, admittedly not exploited much, but it is
there.
Now we're discussing possible solutions for closing this attack vector.
An overreaction would have been an immediate security update restricting
update channels to https without asking affected people (ie. extension
authors) first and without even thinking about alternatives.
Nils
eric...@yahoo.com
>>The frequency of how often a particular attack is executed should have
NO bearing on how security issues are addressed. [Although it's fair to
consider the difficulty of executing an attack, which may happen to
correlate with the frequency.]<<
Actually, it frequency does have significant bearing if you listen to highly respectable cryptographers like Bruce Schneier. See my post about that here:
http://groups.google.com/group/mozilla.dev.extensions/msg/620b08f0548d289e?
>>Comparing this issue with DNS attacks is apples and oranges.<<
I'm not the one who made this comparison. I believe it was Benjamin Smedburg who did so indirectly; he sent a link to the newsgroup of a video showing someone editing his HOSTS file to change the location from which an extension gets its updates. I'm not sure how it related to his comments about WiFi and MITM, but here it is: http://groups.google.com/group/mozilla.dev.extensions/msg/bc3361e4d199e7ea
eric...@yahoo.com
----- Original Message ----
>>I don't really see how this is about overreactions. There is a non attack vector, admittedly not exploited much, but it is there. Now we're discussing possible solutions for closing this attack vector. An overreaction would have been an immediate security update restricting update channels to https without asking affected people (ie. extension authors) first and without even thinking about alternatives.<<
That would be one kind of overreaction. However, a reaction does not have to be immediate or temporal to be judged an overreaction. Merrian-Webster defines an overreaction simply as "excessive" (note the lack of a temporal component), and Mr. Schneier's essay points to examples like like the Unites States Patriot Act which passed years after the causal event--the World Trade Center destruction. Even if you still don't consider the proposed response to the attack an overreaction, it's important to point out that Mr. Schneier's article is not just about overreaction. It's also about risk assessment, risk analysis, and risk response. For that reason, I consider it an apropos essay from a well-respected industry luminary.
Eric H. Jung
mozdev.org board of directors
foxyproxy extension author
passwordmaker extension author
Wrox Press author
Justin Dolske
>> I think that the vast majority of users don't want to (and shouldn't
>> have to) think about security and trust issues when updating an
>> extension, be it automatic or manual.
> I fully disagree with your statement that the majority of users
> shouldn't have to think about security and trust issues. That's exactly
> why http-only phishing sites still work and trojans requiring
> user-interactions are actually installed.
My comment was explicitly about extension updates, not the web as a
whole. We don't have to worry about if the extension is trustworthy or
not, because the user has already installed it. If you think users
should have to make further choices about the low-level details of how
to update their software securely, then I think we fundamentally
disagree on what kinds of security choices users should have to (and are
able to) make.
> Firefox allowing to add "trusted" installation sites is the exact same
> thing except for persistence of the choice...
My point here was that the easier you make it for a user to click and
install software from random web sites, the more likely it is that
malicious websites will start using that mechanism to distribute malware.
But, like I said, I don't think that can of works is relevant to this
thread. :-)
Justin
Nickolay Ponomarev
> Finally if you still want/need insecure delivery of update files, what
> would you think of adding an extra step of adding a digital signature to
> your update.rdf (hopefully just a few commands but still added work
> nontheless).
>
manifest to be served over HTTPS in this scenario or what?
I can understand how requiring the updated XPI to be signed with the
same certificate as the originally installed one could help, but
signing XPIs is even more of a hassle than getting an SSL cert :)
Nickolay
Neil
>how do developers test their extensions without jumping through hoops, thereby increasing barriers to entry?
>
>
Preinstall their self-signed certificate into the trusted store of their
test installation? You can do this manually by browsing to the update
location and accepting the certificate.
--
Warning: May contain traces of nuts.
Dave Townsend
> On 6/15/07, Dave Townsend <dtow...@mozilla.com> wrote:
>> Finally if you still want/need insecure delivery of update files, what
>> would you think of adding an extra step of adding a digital signature to
>> your update.rdf (hopefully just a few commands but still added work
>> nontheless).
>>
> Out of curiosity, how would it help? Will Firefox require the update
> manifest to be served over HTTPS in this scenario or what?
No, the rough plan I have right now is that the update manifest could be
served over plain http, but would require extra information in it
verifying it's authenticity. In order to validate this some extra data
would have to be distributed with the original extension (which is
already installed) that is used to verify the update.rdf file came from
the same source as the extension.
> I can understand how requiring the updated XPI to be signed with the
> same certificate as the originally installed one could help, but
> signing XPIs is even more of a hassle than getting an SSL cert :)
This is another option, and to authors it's liable to be about as much
work as the above option (even just assuming the self-signed route),
which I agree is likely more work than getting ssl on your server,
though probably less cost.
Dave
Nils Maier
Signing the XPIs might be difficult and more work ATM, but it shouldn't
be so hard to simplify it with some more/better documentation and/or
some nice tools.
The update.rdf-over-https-only way would still not protect against
compromised servers...
Therefore I would opt for signing the actual xpi.
Either way, I would make this opt-in, not opt-out or "must", as long as
there is not a requirement for "trusted installation" (i.e. signed
install XPI).
Most major extensions will use the secure way sooner than later.
Nils
Varun
homepage as well. It's a matter of flexibility and that translates to
being able to have the kind of functionality the author wants rather
than what AMO can offer. e.g. download counts/blogs/forums/rating/
voting/issue addressing etc... a host of them.
b) using https: No, but I'd very much want to identify myself with a
technology that is opensource and not like a ssl certificate that
comes at a price.
c) only allow ssl updates: No. I'd guess half the extension authoring
community will be diminished. We are creative guys that make software
for free. Personally it gives me the creative satisfaction (that my
boss doesn't appreciate or care about). Moving to AMO is a crippled
workaround.
d) digital signature: paid signature- no. I would not choose to
afford that overhead. Technical overhead/extra work- yes if it's just
a matter of a few commands. but not a SSL pls.
Question: -what's teh bug number for this one on bugzilla?
Regards
On Jun 15, 8:33 pm, Dave Townsend <dtowns...@mozilla.com> wrote:
> Hi all, we are currently investigating ways to improve the security of
> the automatic add-on update mechanism. There are a couple of proposals
> knocking about and I would like to get some feedback from you if you
> host your own add-ons and updates (on your own website, not on
> addons.mozilla.org).
>
> First can you say why you don't host on AMO (doesn't need to be long
> winded, just want to get an idea of the main issues here).
>
> On the website you host at, do you already use https to deliver the
> update.rdf and/or the xpi's.
>
> If not what would you think of a plan to only allow automatic updates to
> extensions that host their update.rdf on a https server (certificates
> appear to cost from $20 per year), would you be happy to pay that extra
> money, or move to AMO?
>
> Finally if you still want/need insecure delivery of update files, what
> would you think of adding an extra step of adding a digital signature to
> your update.rdf (hopefully just a few commands but still added work
> nontheless).
>
> There is a bug open on this however I'd ask that you keep your replies
> here, or to me directly if you prefer then I can collate some overview.
>
> Cheers
>
> Mossop
Benjamin Smedberg
> a) Why I don't prefer to host on AMO: I do, but also on my own
>
>
>
So, what is your proposed solution? Leave your users open to attacks via
compromised WiFi?
> Question: -what's teh bug number for this one on bugzilla?
Bug 378216
--BDS
Dave Townsend
> Bruce Schneier, famed cryptographer, coincidentally has an apropos
> piece in his monthly CRYPTO-GRAM newsletter this month titled "Rare
> Risk and Overreactions". This gets back to my comments about the
> frequency of this kind of attack. I'd really like to hear your
> opinion about Bruce's piece
I think it's an interesting piece which probably suffers a little for
being written for a general audience. Most of the article which is
attempting to back up his ideas is mainly noting sensational reactions
to things without presenting the other side of the coin, the reactions
that were bang on the money. I find it amusing that he has (unwittingly
or not) used the very psychology he quotes in order to make his examples
stand out as convincing.
My main issue with it is this suggestion he puts forward that
"implementing security measures to make these rare events even rarer" is
waste of time. I'm hoping that we are missing some qualification of
this point and the guy doesn't really think that.
The reality is that whether implementing the measures is a good thing to
do or not depends both on the measures and the risk (note that risk is a
combination of the chance of something happening and the impact of it
happening). You can't just say that a hole that allows someone to
remotely install and run code on your computer isn't worth fixing
because it is rare.
Here's an interesting final point he gives: "figure out what's common
among a bunch of rare events, and concentrate your countermeasures
there". I can tell you that there are a number of vulnerabilities
relating to the insecurities on the add-ons model. Perhaps if we follow
this logic we should lock down what add-ons are allowed to do and
require properly signed add-ons for install *and* updates. Maybe we even
stop allowing add-ons ;)
Dave
Varun
to find a way that the client can verify that the 'expected' file is
coming from the 'expected' source. Thus two clear points.
1) Ensure the identity of the site.
(may be verify headers/hashes of a kind/enable some kind of a
challenge-response (eg nonce generated real time)/handshake). I'm no
hacker to know how but I'm not shelling out money for SSL.
2) Ensuring the identity of the source to a large extent will
eliminate the necessity to verify the file/content. However somekind
of a check sum/signature is needed.
Or may be use some kind of an authorisation key provided by
mozilla.org to the author after registration and some identity
verification. we can generate the hash of these keys and match them
when the installation/update is offered. Else maybe let users download
the file and then install from the local drive.
Open to ideas... and still speculating...
Regards
Shivanand Sharma
> First can you say why you don't host on AMO (doesn't need to be long
> On the website you host at, do you already use https to deliver the
> If not what would you think of a plan to only allow automatic updates to
> Finally if you still want/need insecure delivery of update files, what
> There is a bug open on this however I'd ask that you keep your replies
Dave Townsend
> Thanks for the interrogative response. Accordingly you should be able
> to find a way that the client can verify that the 'expected' file is
> coming from the 'expected' source. Thus two clear points.
My posting in mozilla.dev.tech.crypto explains how I would intend to
implement something secure without ssl or any paid for certificates needed.
Dave
kazuho
> First can you say why you don't host on AMO (doesn't need to be long
> winded, just want to get an idea of the main issues here).
I do not use AMO since my extension works as a part of my web service
that support other web browsers as well. To minimize the support, I
want to keep the installation processes for all the web browsers as
equal as possible.
> On the website you host at, do you already use https to deliver the
> update.rdf and/or the xpi's.
No, not yet.
> If not what would you think of a plan to only allow automatic updates to
> extensions that host their update.rdf on a https server (certificates
> appear to cost from $20 per year), would you be happy to pay that extra
> money, or move to AMO?
Yes, but I doubt if it is technically the best way to go.
SSL certificates do not ensure the identity of the extension
distributor. It only verifies the owner of the domain name. However,
owners of domain names change over time.
IMHO, the best way to secure the users is not to use SSL, but to
verify the consistency of a digital signature attached to the XPI
files, like what is done by the known_hosts file of SSH.
> Finally if you still want/need insecure delivery of update files, what
> would you think of adding an extra step of adding a digital signature to
> your update.rdf (hopefully just a few commands but still added work
> nontheless).
Yes.