> -----Original Message----- > Sent: Wednesday, September 26, 2012 11:57 > Subject: include SHA1/MD5 hash/digest of setup.exe, and HTTPS > > Hello, > Please include SHA1/MD5 hash/digest code of "setup.exe" file, on webpage > next to "setup.exe" download url-link. > so we can know for sure, if we have a correct file or not, and someone in > middle (MITM) has not changed it.
What good is that? Unless the web page itself containing the hash is served over secure HTTP, a MITM attack could just change the hash on your web page too. I'd argue that the only approaches that might provide a real element of security would be: 1. Host setup.exe on secure HTTP. 2. Host setup.exe on regular HTTP, but provide a hash, public key, whatever over secure HTTP. (less convenient for users due to manual verification after download) 3. Sign setup.exe with Authenticode signature (convenient for users and you don't need secure HTTP, but you have to trust the CA). A combination wouldn't hurt. Currently the web page provides this option for verification of setup.exe: "The signature [link to signature] for setup.exe [link to setup] can be used to verify the validity of this binary using this [link to public key] public key." All the links go over standard HTTP. It might protect against accidental file corruption, but I don't see how it can protect against a MITM attack. The link to the public key is over standard HTTP and this is not a secure channel. So there's definitely room for improvement on the Cygwin web site - but maybe not the exact improvements you had in mind. I'm just going to *guess* that it's low priority for the maintainers, though! > No need for a paid/purchased SSL/TLS certificate. A self-signed or CAcert or > other free cert (various cert providers have free cert for non-profit or open- > source developers), is more than enough & suffice. > Much much better than using no encryption at all. Actually no, it's not much better in this case. It's arguably worse because it provides a false sense of security and demonstrates fundamental misunderstanding of what makes public key cryptography & SSL work. The only real security offered by SSL is a certificate originally signed by a trusted root CA. Read up on this topic more, but start by thinking about it: if you're trying to protect against a MITM attack, what's to stop the attacker from sending you their own self-signed certificate? You'd never be able to tell the difference unless you had prior knowledge of what the self-signed certificate was supposed to be. The only way self-signed certs can work is if the certs can be exchanged over another secure channel before attempting the SSL connection. That isn't generally realistic for public web sites. > > Does the "setup.exe" connect to Internet/mirror sites using https or SSL/TLS > encrypted connections ? > if not please, change "setup.exe" codes further, so that at least initial > connections while obtaining hash/digest/asc code of other source files are > obtained via using SSL/TLS (if that source site supports). You should have or > host the hash/digest/asc files of all source files under cygwin.com site. A > larger sized source file or binary file can be downloaded via non-https way, > ONLY if the hash/digest/asc codes were already obtained through > SSL/TLS/HTTPS connection in early. SSL would be much too slow for this. Hashes made with unbroken algorithm, obtained over a trusted channel, are perfectly adequate. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
