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

> -----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

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

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
> other free cert (various cert providers have free cert for non-profit or
> 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
> host the hash/digest/asc files of all source files under site.
> larger sized source file or binary file can be downloaded via non-https
> 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:
Unsubscribe info:

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