This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: include SHA1/MD5 hash/digest of setup.exe, and HTTPS

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
>> 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 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:
> FAQ:         
> Documentation:
> Unsubscribe info:

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]