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-----
> 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 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
> 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
> on the main page over http, would be better. Then users who are using
> when prompted to accept a self-signed cert, can use another browser and
> main/home page just to see the self-signed cert's fingerprint. and then
> 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:
Unsubscribe info:

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