Firefox extensions updated over plain HTTP (not HTTPS)
Alexander Konovalenko
plain HTTP, not over HTTPS. My Firefox 3.0 had found a new version of
the NoScript extension and fetched it from some https:// URI on
addons.mozilla.org. But that URI redirected to another, unencrypted
http:// URI from where the .xpi file was actually downloaded.
Is this known behavior? Is it considered a security issue that should be fixed?
A malicious extension being installed in your browser via some IP or
DNS hijacking attack would be a disaster for many. So it would make
sense for Firefox to require HTTPS when downloading extensions, at
least for those coming from addons.mozilla.org.
If there is a more appropriate place to discuss this, please let me know.
-- Alexander
Nelson Bolyard
> I noticed that some addons.mozilla.org extensions were updated over
> plain HTTP, not over HTTPS. My Firefox 3.0 had found a new version of
> the NoScript extension and fetched it from some https:// URI on
> addons.mozilla.org. But that URI redirected to another, unencrypted
> http:// URI from where the .xpi file was actually downloaded.
>
> Is this known behavior?
Yes.
> Is it considered a security issue that should be fixed?
No. The scheme for authenticating updates for addons has several means,
each of which works. One is to use SSL. Another is to use signed updates.
Signed updates may be downloaded over an unencrypted channel. Their
authenticity is verified using the digital signature, before they are
applied.
Justin Dolske
> I noticed that some addons.mozilla.org extensions were updated over
> plain HTTP, not over HTTPS.
The update check, which happens over SSL, includes a hash in the reply.
When the update is then downloaded (without SSL), the data is checked
against the hash from the update check. If the data was tampered with,
the hash won't match and the bad update won't be applied.
This allows update bandwidth to be pushed to mirrors, without requiring
them to support SSL.
Justin
Bil Corry
> The update check, which happens over SSL, includes a hash in the reply.
> When the update is then downloaded (without SSL), the data is checked
> against the hash from the update check. If the data was tampered with,
> the hash won't match and the bad update won't be applied.
Which hash algorithm is used?
- Bil
Reed Loden
Bil Corry <b...@corry.biz> wrote:
> Justin Dolske wrote on 1/4/2009 9:48 PM:
> > The update check, which happens over SSL, includes a hash in the
> > reply. When the update is then downloaded (without SSL), the data
> > is checked against the hash from the update check. If the data was
> > tampered with, the hash won't match and the bad update won't be
> > applied.
>
> Which hash algorithm is used?
SHA-1, though I have a patch submitted (bug 419906) to change it to use
SHA-256 instead, but I need to rework my patch to address some
pre-review comments.
~reed
--
Reed Loden <re...@reedloden.com>
Justin Dolske
>> If the data was tampered with,
>> the hash won't match and the bad update won't be applied.
>
> Which hash algorithm is used?
SHA-1.
Example link:
Justin
Bil Corry
> On Sun, 04 Jan 2009 23:10:52 -0600
> Bil Corry <b...@corry.biz> wrote:
>
>> Justin Dolske wrote on 1/4/2009 9:48 PM:
>>> reply. When the update is then downloaded (without SSL), the data
>>> is checked against the hash from the update check. If the data was
>>> tampered with, the hash won't match and the bad update won't be
>>> applied.
>
> SHA-256 instead, but I need to rework my patch to address some
> pre-review comments.
Thanks for pursuing the patch; Bruce Schneier has been advocating moving away from SHA-1 for a number of years now:
http://www.computerworld.com/printthis/2004/0,4814,95343,00.html
- Bil