headers
Alexander Konovalenko | 4 Jan 2009 23:18
Picon

Firefox extensions updated over plain HTTP (not HTTPS)

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? 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
Permalink | Reply | 0 comments |
headers
Nelson Bolyard | 5 Jan 2009 01:52

Re: Firefox extensions updated over plain HTTP (not HTTPS)

Alexander Konovalenko wrote, On 2009-01-04 14:18:
> 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.
Permalink | Reply | 0 comments |
headers
Justin Dolske | 5 Jan 2009 04:48
Gravatar

Re: Firefox extensions updated over plain HTTP (not HTTPS)

On 1/4/09 2:18 PM, Alexander Konovalenko wrote:
> 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
Permalink | Reply | 3 comments |
headers
Bil Corry | 5 Jan 2009 06:10

Re: Firefox extensions updated over plain HTTP (not HTTPS)

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?

- Bil
Permalink | Reply | 2 comments |
headers
Reed Loden | 5 Jan 2009 07:06
Gravatar

Re: Firefox extensions updated over plain HTTP (not HTTPS)

On Sun, 04 Jan 2009 23:10:52 -0600
Bil Corry <bil <at> 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 <reed <at> reedloden.com>
Permalink | Reply | 1 comment |
headers
Justin Dolske | 5 Jan 2009 07:17
Gravatar

Re: Firefox extensions updated over plain HTTP (not HTTPS)

On 1/4/09 9:10 PM, Bil Corry wrote:

>> 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:

https://versioncheck.addons.mozilla.org/update/VersionCheck.php?reqVersion=2&id=inspector <at> mozilla.org&version=2.0.1&maxAppVersion=3.2a1pre&status=userEnabled&appID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&appVersion=3.1b3pre&appOS=Darwin&appABI=x86-gcc3&locale=en-US&currentAppVersion=3.1b3pre

Justin
Permalink | Reply | 0 comments |
headers
Bil Corry | 5 Jan 2009 18:19

Re: Firefox extensions updated over plain HTTP (not HTTPS)

Reed Loden wrote on 1/5/2009 12:06 AM: 
> On Sun, 04 Jan 2009 23:10:52 -0600
> Bil Corry <bil <at> 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.

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
Permalink | Reply | 0 comments |
headers
Sid Stamm | 5 Jan 2009 20:52
Picon

Re: Content Security Policy feedback

Gervase Markham <g... <at> mozilla.org> wrote:
> Security is a multi-faceted beast.
Point taken, and I agree, it was a crappy analogy.

> Again, CSP is here being used as a front line of
> defence, and it shouldn't be.
I agree with you... optimally, CSP should not be front-line defense.
But for it to be helpful in practice, there must be a motivation for
people to put it on their sites.

What worries me is that with no assurance that they're enforced, CSP
policies won't be provided by web sites since it takes time (granted,
not much of it) to compose them.  It's likely that a profit-driven
company might rather have their engineers spend time fuzzing or bug
fixing than designing a good CSP string that may or may not ever be
used.

One point of view is, screw 'em... sites that don't provide CSP will
just be vulnerable to more XSS attacks, and it is only skin off their
own back.  On the other hand, the client through his browser is
usually the real victim, not the site, and I think we want to
encourage sites to give as much protection to the client as possible.
This might mean tailoring CSP a bit to give companies motivation to
put CSP into their sites.

Though, perhaps in the long run a good policy can help them later
identify possible vulnerabilities, it may not be obviously beneficial
in the short run and won't be enough to make up for the fact that the
site can't tell whether or not if their CSP is helping out at all (and
so they won't provide it).
(Continue reading)

Permalink | Reply | 4 comments |
headers
Bil Corry | 7 Jan 2009 04:59

Re: HTTPOnly cookies specification

Bil Corry wrote on 12/16/2008 6:55 PM: 
> One option I'm considering is doing as you suggest, writing an entire
> cookie spec as it exists now, then add the features to cookies
> necessary to provide integrity and privacy.  I spoke with Ian
> Hickson, he said IETF is the proper place for this work, not WHATWG.

There is now an official list for discussing changes to the cookie spec here:

	https://www.ietf.org/mailman/listinfo/http-state

- Bil
Permalink | Reply | 0 comments |
headers
D3|\||\|!$ | 8 Jan 2009 14:10
Picon

A / V / Text encryption methods

Hi All!

I am looking for real-time encryption methods/protocols for streaming
A / V / Text data. I plan to build an app similar to Skype and since
Skype doesn't really reveal much about its security architecture, I'm
looking for ingenious solutions. Any suggestions/help would be
welcome.

From whatever research I did about Skype, I found the following
things:

Skype has implemented majority of its encryption modules by itself and
which are built to comply with standards but applied in their own
ingenious ways such as the AES block cipher, the RSA public-key
cryptosystem, the ISO 9796-2 signature padding scheme, the SHA-1 hash
function, and the RC4 stream cipher.

It uses 256-bit encryption in order to actively encrypt the data in
each Skype call or instant message. Skype uses 1024 bit RSA to
negotiate symmetric AES keys. User public keys are certified by the
Skype server at login using 1536 or 2048-bit RSA certificates.
The key size used for signing here is 1536-2048, which is
significantly greater than 1024-bit keys that are a global norm.

It has also set up its own CA for authentication. On first usage, a
client contacts Skype's master server which issues a certificate from
its indigenous CA.

Besides the above cryptographic algorithms, Skype has also implemented
its own proprietary key-exchange protocol which it uses for key
(Continue reading)

Permalink | Reply | 0 comments |

Gmane