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 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 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
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=inspec...@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¤tAppVersion=3.1b3pre
Justin
___
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
Re: Firefox extensions updated over plain HTTP (not HTTPS)
On Sun, 04 Jan 2009 23:10:52 -0600 Bil Corry 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 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
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 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
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 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
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. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
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 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
