Is "cygwin.com" domain DNSSEC signed yet ? can "setup.exe" be able to re-programmed to connect with dnssec signed cygwin.com (by using a builtin dnssec supported basic dns resolver) ? and can also be made to use the pre-included self-signed cert's key for a secured & encrypted connections (for obtaining just the digest/has-list of all supported/included packs) ? ?
-- Bry8Star On 9/27/2012 12:34 AM, Bry8 Star wrote: Sorry, i have failed arrange my thoughts & requests properly and then post. i have been requesting in IRC, but no one seems to care a bit. if it is too hard for devs, to do any of the mentioned things/requests/improvements, PLEASE at-least show the SHA1 (over http) next to setup.exe. . think of, how hard it will be to do just that ? ! ? 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 (non-proxied) web-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. doing super-perfect solution will probably not last for long. so at least use what is little bit better. no need for the mirror(s) or others to serve over https, if you allow cygwin setup.exe to connect with cygwin site over https at-least during downloading the digest-list of currently supported or included packages. such uptodate list need to be served for setup.exe, which cygwin devs will have to collect in early, as soon as developer releases a new release, and add in that https based digest database file. You are better in these areas, so please come up with a better solution, so that, those who uses proxies, even those users will get at-least the package digest-list securely, and then obtain main package via any method, but check package against securely obtained list, before installing. i have an idea, if setup.exe itself has root-zone DNS KEY built into it, then can it verify during downloading the package digest-list that it is actually getting it from authentic cygwin.com's IP-address ? and not from some other IP-addrees ? another idea, can a self-signed CERT's FINGERPRINT (& other info) be already included inside setup.exe ? and made necessary change in setup.exe to check if the SSL/TLS cert is being used is authentic or not ? even sha1 has weakness, so sha-256 is better at this moment, as far as i can recall. -- Bry8Star. On 9/26/2012 6:42 AM, Ryan Johnson wrote: > tl;dr: publishing a checksum for setup.exe is a good idea, https makes > little or no sense in this setting, and cryptographic signatures for > packages would be nice to have but would burden volunteers while > providing incomplete protection. > > (response follows) > > On 26/09/2012 2:22 AM, Bry8 Star wrote: >> Please include SHA1/MD5 hash/digest code of "setup.exe" file, on webpage >> next to "setup.exe" download url-link. > Providing a digest for setup.exe is probably a good idea, and probably > not too hard. > >> so we know for sure, if we have a correct file or not, and someone in >> middle (MITM) has not changed it. >> >> Windows users prefer to verify files rather with sha1/md5 etc, than >> using asc, as asc verification is more complicated. > Cygwin packages already provide MD5 signatures, but those only really > protect against accidental corruption during the download [1]. ASC would > provide a bit more protection [2], but it's apparently too inconvenient > for you to use. This is good, because it would be severely inconvenient > for cygwin devs and package maintainers to provide it to you. > >> please distribute the setup.exe, via using a HTTPS based URL/site. > Why do want https? There are exactly zero bytes of sensitive traffic to > protect, and attackers would still know you're visiting the site (use a > VPN to prevent that). > >> 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. > A self-signed certificate provides a dangerous false sense of security > when verifying site identity [3]; no certificate can protect you from a > hacked cygwin.com (should that ever occur), nor from malicious > developers and package maintainers (c.f. [2]). The encryption aspect of > https is irrelevant because no sensitive information is exchanged. > >> Does the "setup.exe" connect to Internet/mirror sites using https or >> SSL/TLS encrypted connections ? > It makes no sense for mirrors to provide https [4], and most probably > couldn't even if they wanted to. > > $0.02 > Ryan > > [1] There are good technical reasons why setup.exe will never pull > checksums for mirrored packages from cygwin.com, so forget that idea. > Further, several recent collision attacks have shown MD5 to be utterly > broken when an attacker wants it to be (SHA-1 might be better, I don't > remember). > > [2] Cryptographic signatures would prevent mirrors from tampering with > packages after release, but do nothing to establish trust in the myriad > volunteers who write the software and compile the packages in the first > place. I seriously doubt RedHat would open itself to liability by > vouching for the identity or character of non-employees. > > [3] An attacker willing/able to spoof your DNS will be perfectly capable > of providing a convincing self-signed certificate as well. They might > even provide a "proper" certificate, in light of recent attacks on > gmail, et al. > > [4] A mirror needs only to provide unmodified copies of packages; > cryptographic signatures are both necessary and sufficient to achieve > that goal. It doesn't matter who (or how malevolent) the mirror operator > is as long as the signatures check out. > > > -- > 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 -- 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
