The signature files, are, erm, SIGNED by mozilla.org's PGP key. If they were forged, then GPG would warn me that the signature on the file didn't check out.
Next time, engage brain before bashing out a response.
My point is that it is already possible to confirm that a download of Firefox has not been tampered with. That the user can not, or will not, take steps to verify this fact is not the fault of Firefox, or the other tools involved. Remember, you can bring a horse to water...
You are giving people the wrong idea! How do you know those MD5sums are trustworthy?
You must check their trustworthynes by finding a copy on the openoffice.org site that has been signed with a certificate or PGP key, and then verifying the chain of trust between you and that certificate/key.
To be balanced, you should point out that Firefox does not check that update.mozilla.org is the *real* Mozilla Update site. At a minimum, update.mozilla.org should *only* operate using TLS.
> If either site has been compromised, the MD5 sums won't match - either the > binary or the MD5 were altered, or both.
The attacker has regenerated a new MD5SUMS file to match their altered distributions of Mozilla.
> A man-in-the-middle attack would require that BOTH sites be compromised, and in > the same fashion.
Run a traceroute to either of your two site. Any one of the routers between you and them, that they have in common (or not, if two separate routers were compromised by the same cracker) could be replacing all the traffic to your two sites with their own, poisined information.
The point of all this is that you CAN NOT trust _just_ the MD5 sums to make the call whether the file you have downloaded is safe. You _must_ verify that the sums are correct, and unless you can take a bus to a mozilla.org admin's workplace and ask them personally (but what if the attacker has kidnapped the admin and is impersonating them?), this means using a cryptographically secure method.
> This whole thing is a non-issue. Nothing is 100% secure, and a cert from > verisign won't make it more secure. They'll sell certs to anyone.
Now you've hit the nail on the head. PGP is the more trustworthy, for my money's worth.
It doesn't matter where the key came from, because it has been signed by other keys, which I can trace back to keys that I have signed. More info if you're interested.
No no no no. The MD5 hash (or sha1, etc) is a checksum. If the file matches the checksum, you know that *provided the checksum is trusted*, the file is also trusted.
The certificate is where trusting the checksum comes in. Two examples:
1. Mozilla.org provides a MD5SUMS file that lists the MD5 sums of the files that it hosts. This file is signed by a PGP key. If you can verify the chain of trust between yourself and this key (and check that the md5sums match the file you downloaded) you know that the file you downloaded is safe.
2. The file you downloaded comes with an extra piece of data, a signed checksum. If you can verify the chain of trust between yourself and the certificate used to produce the signature, then you know that the file is safe.
How do you verify the chain of trust? The following is *not* an exclusive list. I am not a security expert.
Can you trust the OS you are running on? Can you trust the programs you use to generate the checksum of the file you downloaded? Did you get them from a trusted place? Can you be sure they behave as advertised? Can you trust your computer to display the results acuratly? Do you trust the certificate that matches the key that the file was signed with? Do you trust all intermediate certificates, up to the root CA certificate? Do you trust that these certificates are actually being used acuratly, or even at all? The OS might say one thing and secretly do another... Do you trust other programs running on your computer to not tamper with this process?
This is all true. No one should see "MD5" and assume the software is safe. The chain of trust must always be verified.
However, I think that it is necessary to point out to those who may read this and get the wrong idea, that mozilla.org _does_ provide digital signatures for the files that they host--despite what the author of the original article claims.
> Opens Source was designed, like the internet protocols, for people who trust > each other
Irrelevant and incorrect.
> the developers of shrink-wrap executables need to learn to think > paranoid when they deal in user binaries.
Mozilla.org already provides digital signatures for files that it hosts, despite what the author of the original "article" claims.
> Don't make the same errors again - if the designers of SMTP had thought about > the users rather than the implementers, they woudl have built > signature/encryption/sender authentication straight into the protocol and > prevented the spam issue from ever arising.
Because the many methods already available for signing email, on all the various levels, have eliminated spam, right?
This is because signing a program, whether with a GPG key (like Mozilla does, despite what the author of the original "article" claims) or with a certificate (like spyware does) does _not_ indicate that the program is useful for a particular purpose (golly, now I sound like an EULA!).
It means that the person who owns the key/certificate _says_ that the program is trustworthy. No more, no less.
If you trust the keyholder or certificate holder*, then you can trust the software. If not, then you can't.
Until people learn this simple fact, they will continue, and deserve, to be screwed by malware authors.
* and this means, the chain of trust that connects you to the trustee. If the user doesn't know what this means, then the user must learn.
True. But DNS is itself not secure. Fortunatly, TLS (which mozilla.org does not appear to provide) and digital signatures (which they do, despite what the original article claims) solves this problem.
> This guy makes some good points. His main point is that the distribution process for FireFox is very insecure.
Unfortunatly, since he doesn't appear to know his arsehole from his elbow WRT security, his entire argument is invalidated.
> The "traditional open source approach" of voluntary mirrors (perhaps with manual MD5 checks) isn't good enough
No, it's not. That's why mozilla.org (and most other projects) provide digital signatures of their source archives, and (if distributed) binaries.
> for high-volume end user products.
What the hell does that mean?
> The FireFox team needs to work out a much more secure install sequence.
No they don't. Users need to learn how to check digital signatures.
> One approach might be to have users download an small installer from "firefox.org" (only!)
Thanks for breaking the way files are normally distrubuted accross the 'net. I goddamn *hate* programs that think they are *so good* that you can't actually download them yourself... you have to download a special downloader program that is invariably a buggy piece of crap. I'll stick to wget, thanks.
> The download site on "firefox.org" should have an SSL certificate good enough for code signing.
Feel free to pay for it. In the mean time, I'll continue to check the signatures with GPG.
> > A signed binary ensures that the package that was created by Mozilla.org has not been modified
> So does an MD5 sum taken from a second site (not the site that the download came from).
No, it does not. You can not trust that *either* site has not been compromised (or, more likely, that someone is main-in-the-middling you).
If you verify the files you download against the digital signatures (that have already been provided by mozilla.org, a pity the guy who wrote the original article didn't notice them), you can be sure that the file you downloaded is safe.
If the user wants to shoot himself in the foot, he is damn well going to shoot himself in the foot. Unfortuantly, neither Firefox nor IE can prevent this.
> He's got a point though. I could volunteer my services as a random Firefox mirror and who's to know if I'm distributing doctored copies?
Yup. This is not Firefox's problem; this is the problem of the fuckwits who run software from untrusted software, and *time and time again* get exploited because of it.:)
> And where's the digital signature? How can you trust that binary from 207.177.45.61?
Well if you're mirroring "Firefox Setup 1.0.exe" then I would expect to see "Firefox Setup 1.0.exe.asc" right along beside it. If it was missing this would look suspicious, but I could still fetch the appropriate file from ftp.mozilla.org.
Remind me never to use utilities written by you. It means I won't be able to pipe the output through awk and get sensible results, without wasting my time addint corner cases to strip out the row and column headings. Thanks a bunch!
How can the extension possibly claim that it is compatible with a version of the extensions API that didn't even exist when the extension was written?
You have the choice between extensions being disabled (big deal--wait for them to be updated), or extensions breaking horribly, possibly causing data loss, when you upgrade...
It will work in Windows if you create an "ad hoc" network. After you add a third node the connection quality degrades drastically though, from what I've heard.
If you use Linux you can run one card in "Master" mode, which basically makes it into a base station. Obviously you then don't need a real base station, etc.
Slashdot Mirror
Please read what I wrote.
The signature files, are, erm, SIGNED by mozilla.org's PGP key. If they were forged, then GPG would warn me that the signature on the file didn't check out.
Next time, engage brain before bashing out a response.
My point is that it is already possible to confirm that a download of Firefox has not been tampered with. That the user can not, or will not, take steps to verify this fact is not the fault of Firefox, or the other tools involved. Remember, you can bring a horse to water...
You are giving people the wrong idea! How do you know those MD5sums are trustworthy?
You must check their trustworthynes by finding a copy on the openoffice.org site that has been signed with a certificate or PGP key, and then verifying the chain of trust between you and that certificate/key.
To be balanced, you should point out that Firefox does not check that update.mozilla.org is the *real* Mozilla Update site. At a minimum, update.mozilla.org should *only* operate using TLS.
> If either site has been compromised, the MD5 sums won't match - either the
> binary or the MD5 were altered, or both.
The attacker has regenerated a new MD5SUMS file to match their altered distributions of Mozilla.
> A man-in-the-middle attack would require that BOTH sites be compromised, and in
> the same fashion.
Run a traceroute to either of your two site. Any one of the routers between you and them, that they have in common (or not, if two separate routers were compromised by the same cracker) could be replacing all the traffic to your two sites with their own, poisined information.
The point of all this is that you CAN NOT trust _just_ the MD5 sums to make the call whether the file you have downloaded is safe. You _must_ verify that the sums are correct, and unless you can take a bus to a mozilla.org admin's workplace and ask them personally (but what if the attacker has kidnapped the admin and is impersonating them?), this means using a cryptographically secure method.
> This whole thing is a non-issue. Nothing is 100% secure, and a cert from
> verisign won't make it more secure. They'll sell certs to anyone.
Now you've hit the nail on the head. PGP is the more trustworthy, for my money's worth.
It doesn't matter where the key came from, because it has been signed by other keys, which I can trace back to keys that I have signed. More info if you're interested.
No no no no. The MD5 hash (or sha1, etc) is a checksum. If the file matches the checksum, you know that *provided the checksum is trusted*, the file is also trusted.
The certificate is where trusting the checksum comes in. Two examples:
1. Mozilla.org provides a MD5SUMS file that lists the MD5 sums of the files that it hosts. This file is signed by a PGP key. If you can verify the chain of trust between yourself and this key (and check that the md5sums match the file you downloaded) you know that the file you downloaded is safe.
2. The file you downloaded comes with an extra piece of data, a signed checksum. If you can verify the chain of trust between yourself and the certificate used to produce the signature, then you know that the file is safe.
How do you verify the chain of trust? The following is *not* an exclusive list. I am not a security expert.
Can you trust the OS you are running on?
Can you trust the programs you use to generate the checksum of the file you downloaded?
Did you get them from a trusted place?
Can you be sure they behave as advertised?
Can you trust your computer to display the results acuratly?
Do you trust the certificate that matches the key that the file was signed with?
Do you trust all intermediate certificates, up to the root CA certificate?
Do you trust that these certificates are actually being used acuratly, or even at all? The OS might say one thing and secretly do another...
Do you trust other programs running on your computer to not tamper with this process?
This is all true. No one should see "MD5" and assume the software is safe. The chain of trust must always be verified.
However, I think that it is necessary to point out to those who may read this and get the wrong idea, that mozilla.org _does_ provide digital signatures for the files that they host--despite what the author of the original article claims.
> Opens Source was designed, like the internet protocols, for people who trust
> each other
Irrelevant and incorrect.
> the developers of shrink-wrap executables need to learn to think
> paranoid when they deal in user binaries.
Mozilla.org already provides digital signatures for files that it hosts, despite what the author of the original "article" claims.
> Don't make the same errors again - if the designers of SMTP had thought about
> the users rather than the implementers, they woudl have built
> signature/encryption/sender authentication straight into the protocol and
> prevented the spam issue from ever arising.
Because the many methods already available for signing email, on all the various levels, have eliminated spam, right?
This is because signing a program, whether with a GPG key (like Mozilla does, despite what the author of the original "article" claims) or with a certificate (like spyware does) does _not_ indicate that the program is useful for a particular purpose (golly, now I sound like an EULA!).
It means that the person who owns the key/certificate _says_ that the program is trustworthy. No more, no less.
If you trust the keyholder or certificate holder*, then you can trust the software. If not, then you can't.
Until people learn this simple fact, they will continue, and deserve, to be screwed by malware authors.
* and this means, the chain of trust that connects you to the trustee. If the user doesn't know what this means, then the user must learn.
True. But DNS is itself not secure. Fortunatly, TLS (which mozilla.org does not appear to provide) and digital signatures (which they do, despite what the original article claims) solves this problem.
> This guy makes some good points. His main point is that the distribution process for FireFox is very insecure.
Unfortunatly, since he doesn't appear to know his arsehole from his elbow WRT security, his entire argument is invalidated.
> The "traditional open source approach" of voluntary mirrors (perhaps with manual MD5 checks) isn't good enough
No, it's not. That's why mozilla.org (and most other projects) provide digital signatures of their source archives, and (if distributed) binaries.
> for high-volume end user products.
What the hell does that mean?
> The FireFox team needs to work out a much more secure install sequence.
No they don't. Users need to learn how to check digital signatures.
> One approach might be to have users download an small installer from "firefox.org" (only!)
Thanks for breaking the way files are normally distrubuted accross the 'net. I goddamn *hate* programs that think they are *so good* that you can't actually download them yourself... you have to download a special downloader program that is invariably a buggy piece of crap. I'll stick to wget, thanks.
> The download site on "firefox.org" should have an SSL certificate good enough for code signing.
Feel free to pay for it. In the mean time, I'll continue to check the signatures with GPG.
No computer system in the world will magically grant a Clue to lusers.
> > A signed binary ensures that the package that was created by Mozilla.org has not been modified
> So does an MD5 sum taken from a second site (not the site that the download came from).
No, it does not. You can not trust that *either* site has not been compromised (or, more likely, that someone is main-in-the-middling you).
If you verify the files you download against the digital signatures (that have already been provided by mozilla.org, a pity the guy who wrote the original article didn't notice them), you can be sure that the file you downloaded is safe.
I don't care which is the official one, because the signature file verified with the GPG keys I have on record for Mozilla devs.
If the user wants to shoot himself in the foot, he is damn well going to shoot himself in the foot. Unfortuantly, neither Firefox nor IE can prevent this.
You can sign the file that contains the md5sums...
> Installing Firefox requires downloading an unsigned binary from a random web server
:)
Someone should tell guy about the signature files that go right alongside the setup exe.
> He's got a point though. I could volunteer my services as a random Firefox mirror and who's to know if I'm distributing doctored copies?
:)
Yup. This is not Firefox's problem; this is the problem of the fuckwits who run software from untrusted software, and *time and time again* get exploited because of it.
> And where's the digital signature? How can you trust that binary from 207.177.45.61?
Well if you're mirroring "Firefox Setup 1.0.exe" then I would expect to see "Firefox Setup 1.0.exe.asc" right along beside it. If it was missing this would look suspicious, but I could still fetch the appropriate file from ftp.mozilla.org.
Remind me never to use utilities written by you. It means I won't be able to pipe the output through awk and get sensible results, without wasting my time addint corner cases to strip out the row and column headings. Thanks a bunch!
Oh my god! In order to use a system I have to read a MANUAL?
Oh, and I found out about man pages in the install guide that came with my distribution.
How can the extension possibly claim that it is compatible with a version of the extensions API that didn't even exist when the extension was written?
You have the choice between extensions being disabled (big deal--wait for them to be updated), or extensions breaking horribly, possibly causing data loss, when you upgrade...
It will work in Windows if you create an "ad hoc" network. After you add a third node the connection quality degrades drastically though, from what I've heard.
If you use Linux you can run one card in "Master" mode, which basically makes it into a base station. Obviously you then don't need a real base station, etc.
Works great with Nvidia, however if I try to use Xorg 6.8 rather than XFree86 4.3, it dies. So I guess it depends on driver+xserver(+hardware?)
How much of the money goes to the lawyers concerned?