X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,FSL_FREEMAIL_1,FSL_FREEMAIL_2,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD,UNPARSEABLE_RELAY
X-Spam-Check-By:	sourceware.org
X-Yahoo-SMTP:	5dK18waswBAT5ulP1CdMKt9Jhcrn
Message-ID:	<5063E0B2.3030106@yahoo.com>
Date:	Wed, 26 Sep 2012 22:14:26 -0700
From:	Bry8 Star <bry8star AT yahoo DOT com>
Reply-To:	bry8star AT yahoo DOT com
User-Agent:	Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: include SHA1/MD5 hash/digest of setup.exe, and HTTPS
References:	<5062EDA4 DOT 9070509 AT yahoo DOT com> <033d01cd9bf0$f6cf9cf0$e46ed6d0$@motionview3d.com>
In-Reply-To:	<033d01cd9bf0$f6cf9cf0$e46ed6d0$@motionview3d.com>
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

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

- Raw text -