Mail Archives: cygwin/2010/03/18/22:22:54
On 2010/03/18 8:38 AM, Warren Young wrote:
> Your proposed solutions don't really work.
I disagree. Granted, they are not 100% effective, but since when is
perfection the standard by which all solutions are judged?
> They're crutches which may
> help in some cases, but they don't absolutely and finally fix the
> problem.
So? Mitigating a problem means that fewer people will experience that
problem. Provided that a significant proportion of the cases experience
some mitigation, it can be worth implementing even an "imperfect" solution.
> Therefore you're proposing that someone else do work on a
> "maybe".
Jeez. A guy can't throw ideas out here without people assuming they're
demands for action. I was looking for a discussion of the relative
merits of a few ideas.
> Why are you surprised when he says "no"?
I wasn't surprised.
> Re the idea that SSL will defeat brain-dead and broken proxies: only the
> most brain-dead among them. Corporate filtering proxies are often set
> up to unwrap SSL at the proxy then re-sign the outbound request; they
> see the plaintext request. Such things aren't common at the low end
> because it requires adding the proxy as a trusted CA to every SSL using
> program on the system, but it's common enough.
Are most proxies proxying HTTPS? What proportion of them do? If a
significant proportion do not, then using HTTPS can still benefit a
great number of users, and it may be worth implementing (especially
since HTTPS has other nice properties).
> Re MITM mitigation: If that's what you're trying to guard against, how
> does putting hashes on a non-HTTPS web page help? A MITM could modify
> the hashes in transit just as well as he could modify setup.exe.
I don't believe I proposed hashes on their own as a defense against
MITM. I proposed signatures and/or authenticated transports (HTTPS) for
that. Hashes can still be useful for verifying that a downloaded file is
corrupt. The OP of this thread could have used a hash to verify that his
file was bad, for example.
> Re the MITM risk to begin with: is this actually happening, or are we
> just speculating here? I pay some attention to security issues, and
> haven't seen any reports of random in-flight exes over HTTP being
> replaced by a MITM with malware. Could it be done? Of course. But
> *is* it, and with what frequency?
Good questions. I don't think there are any credible statistics on this,
since it is very difficult to define and measure. The fact that MITM is
feasible in several common scenarios is enough to warrant looking at
simple mitigation techniques. If (some combination of) the techniques
aren't too expensive when weighed against the potential risks, then they
ought to be implemented.
The intended use-case of setup.exe---namely, to download and run it from
cygwin.com every time you want to use it---is especially vulnerable to a
targeted MITM attack, since it affords the attacker any number of
opportunities to deliver you an evil setup.exe. If an attacker knows
you're a Cygwin user, and he's in a position to act as a MITM between
you and cygwin.com at least some of the time, then you'd better
carefully check every setup.exe you download before you run it.
Cygwin has already implemented signatures for setup.exe (yes, I
completely missed that before; Dave K. set me straight), and that is a
very good thing.
Detecting a MITM isn't the only problem to deal with when downloading
files. Knowing when your file is truncated or otherwise corrupted---for
any reason, not just malice---is also a good thing.
Thinking about it some more, bypassing a web filter (regardless of
whether it is well- or ill-configured) is probably not a goal to strive
for. It is better to give the user some way of verifying whether the
file he got is actually the file that Cygwin intended to deliver.
Signatures fully cover that need, and hashes are a less expensive
partial measure. HTTPS would make it simpler for more users to trust the
files they do get, since verifying signatures requires additional
knowledge and software that relatively few people actually have.
Obviously, I'm not going to hold my breath waiting for HTTPS to appear
on cygwin.com, but there is no disputing that it would improve the
security of downloads.
Best regards,
-SM
--
--
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 -