> -----Original Message----- > Behalf Of Bry8 Star > Sent: Thursday, September 27, 2012 05:14 > Subject: Re: include SHA1/MD5 hash/digest of setup.exe, and HTTPS > > 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).
This would seem like a reasonable idea, except for the fact you allow transmission over HTTP, which then renders the entire idea pointless. If the attacker can tamper with the setup EXE itself, they can tamper with the provided hash as well so that it matches the tampered EXE. Serving the hash over plaintext HTTP creates a false illusion of security, which is arguably more dangerous than not having any illusion of security at all. (Note that this also renders the existing setup EXE signature and public key on Cygwin.com pointless as well, for the same reasons. I'm not sure why they bother signing setup EXE, since the signature just goes on plaintext HTTP. How do I know the public key itself hasn't been replaced with one from an attacker?) > > those who are using (apparent) direct connection with cygwin site, for them, > even a self-signed cert is more than enough. This is just as pointless as serving over plaintext HTTP and creates a false illusion of security. In this case, the attacker need only replace Cygwin's self-signed certificate with their own malicious certificate and the visitor won't know the difference. The only two ways I'm aware of for securely transmitting Cygwin setup to a clean installation of Windows would be to have the data signed by a trusted root certificate authority that comes preinstalled on Windows. This could be done via one of the following two methods: 1. Serve either the setup EXE itself or a digital signature of the setup EXE via secure HTTP. The SSL certificate must be ultimately signed by a trusted root CA (i.e. not self-signed). 2. Sign the setup EXE with Authenticode certificate; no need for secure HTTP in this case. I say do the job right or don't even attempt it. That would mean do one of the previous, or don't even pretend to run something secure when you're not (i.e. remove the existing signature served over plaintext HTTP). > 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. What do proxies have to do with anything? The issues are the same whether or not an intentional proxy is involved. In reality, an attacker can insert a transparent "proxy" whenever they want to and you'd never know it, and then tamper with your data. -- 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
