Greetings.....to another episode

Have you ever thought about the possibility that when downloading some famous server software (regardless of it's purpose) apache for example,
that the download that you get can be tampered with in mid-transfer so that you receive a "different" thing than the original one ?

I bet you've thought about that as i did.

most likely some brilliant dude would come up with the notice that most respectable publishers actually offer a hash code to compare against the finished download's hash ones it's on your box , BUT....

Have you actually thought also about the possibility that , this nasty "motherfunner in the middle" can easily tamper with the md5 code that is presented on the website , while he is laughing at the poor jerk who believed that checking hashes beats intended data corruption ?

I don't know about you guys , But if you folks wanna know about me...

I pray every time i get into such situations of downloading software off the net (keep in mind that i only download from or thru sourceforge , rpmfind , packman and very rarely from nobodies) that the TCP/IP Gods are on my side and hope for the best that they don't get furious and plague me with some rodent hidden on a load of bits and bytes....

So to conclude this with a constructive question :

What is a better alternative to comparing hashes , bringing 100% assurance that what you get on the box is what the author had actually sent to you???

and thanks as usual in advance.

P.S I hope that the phrase "100% assurance" doesn't raise your eyebrows in the vein of "security is never 100%"

Well, the distributor could make the hash accessible via HTTPS instead of HTTP. Then you can be pretty sure the hash hasn't been tampered with on it's way from the server to your PC. But still, how do you know the server wasn't cracked and the hash replaced with the one for the trojaned package? Digital signatures address this, but you'd likely want to enter a Web of Trust. As an example, to accomplish this when downloading Apache it would go like this.

OK , now before talking about web of Trust let's stay a little bit with something that I've dealt with before which is the md5 over the Https .

now considering that the remote host is OK , but the in-between is not , then probably https would help.
but i guess there is a nasty problem which actually deals with https in general i think.

If we assume that the host puts the hash on ssl then what makes us sure that when getting this file , that we aren't actually redirected to 'another' https host containing the hash of the rodent?
at that point we can't know whether this is the real https host or a fake one , unless we know in advance about the public key of the real host which puts us back at the problem of the "pre-shared secret" ...etc

if we managed to share a secret in advance with the real author then it would make more sense to share the md5 hash directly , right?

as far as i know , signed ssl certificates are nothing more than public RSA keys who are associated with a certain host ,ip, domain , etc....
and which can be verified from an honest third party , but since big brother can redirect any traffic then why shouldn't he redirect us to a fake third party ...etc.

of course if I missed something feel free to correct

cheers

P.S i'd like to talk about this web of trust after finishing the issue about md5 over https.

You can probably find the certificates from an older version of a distro you downloaded. A company or organization will have the same certificates and ofter a signature will be made as well as the md5sums. MD5sums are useful in detecting transmission errors but if a hacker can put their payload near the beginning of an image, it wouldn't take as long calculating md5sums on the altered part (compared to the entire image), modifying a "junk" number, in the hope of finding a collision with the md5sum of the original. MD5sum has a weekness in that if the md5sum of two messages M1 & M2 are the same, then md5sum(M1|S) = md5sum(M2|S). This allows for example adding the same (S) to two boilerplates to create two postscript documents that display different information but have identical md5sums.

If you have both the md5sums and a signature signing a different type of hash, I don't think that has ever been defeated.

AFAIK, he could - but he'd need access to the CA's private key.

Not really , big brother would have the ability to redirect all my traffic (for example) and alter it in the following way.

1) tamper with the download (now that gotta be straight forward)
2) generate an md5 hash key of the fake download and put it on an https server that big brother owns
3) the moment you wanna get the hash from the author big brother redirects your https packets to his evil fake https server with the fake md5 hash of his fake infested download. (of course big brother is smart enough to change back the source ip of his https server to make it look like they came from whom you think you are talking to...etc etc)

4) you arrive at the point where you got to authenticate the ssl session with the fake https server , you Get the public key of the fake one.

5) now you check with a third party like VeriSign whether this public key belongs to Mr.Author , BuT....

6) Big Brother intervenes again to redirects your connection from VeriSign to his fake VeriSign server , which tells you that this RSA public key belongs to Mr.Author , where in reality it belongs to Big Brother .

and the funny thing would be that the author wouldn't actually know that all this mess happened under his name , because you know ....

...you simply got redirected!

and knowing the private RSA key of Mr.author wouldn't be neccesary at all to accomplish this cheat.

again i'm open to receive corrections if something was wrong in my "presentation"

Cheers

And at that moment your browser should spit-out a giant warning. I mean, redirecting HTTPS implies that you had already validated the non-BB site's certificate and you were both using your session key to communicate. Your session key itself is encrypted using the server's public key before uploading it. So for the BB server to understand anything encrypted using your session key, they would need access to the non-BB's private key. If they do have access to this key then the non-BB server has been owned and HTTPS isn't designed to protect you against owned servers.

There is no reason for you to connect to VeriSign in order to validate a VeriSign certificate.

Your browser has the VeriSign public keys built-in.