Sorry, my 1st post got downloaded later on my side, so i re-posted (again, this), mistakenly.
James, you are right, a combination approach would be better. But before doing any major changes (on setup.exe), for now, at-least, a sha1/md5 should be shown over http (better if over https), and if setup.exe has asc, then a link to asc (over https, preferably). those who are using (apparent) direct connection with cygwin site, for them, even a self-signed cert is more than enough. if someone connecting via proxies, then, a CA signed cert would be better. but any of those, will be better than nothing at all, the current condition. and self-signed solution can be implemented quickly. and in case of using self-signed cert, showing the self-signed cert's fingerprint on the main page over http, would be better. Then users who are using proxies, when prompted to accept a self-signed cert, can use another browser and visit main/home page just to see the self-signed cert's fingerprint. and then match the fingerprint shown on proxy based web-browser to verify & accept. On 9/26/2012 7:12 AM, James Johnston wrote: >> -----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 > -- 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
