Re: HTTPS (was: rubygems insecure download (and other problems))

[Pavel Labushev <pavel.labushev () runbox no>]

On Thu, 15 Aug 2013 02:44:33 -0400
Donald Stufft <donald () stufft io> wrote:

> Content signing is preferred but that is a much harder problem to solve
> in general for a repository like Rubygems than simple using TLS which
> is a pretty good approximation.

If Rubygems users feel the gems are being obtained securely over HTTPS,
and no one tells them it may be otherwise, and no one proactively
provides them with the tools and guidelines, no one tries to turn their
attention to the problem, why would they bother to sign anything or
check the signatures, even if they're available?

And one more thing: the fact that the problem is harder to solve doesn't
make HTTPS a pretty good approximation. It's just something, but how
good is it, or is it good at all? Even if HTTPS would be a perfect
solution to transfer data securely, it would hardly add anything to
security of the web service applications and the other parts of the
infrastructure, including people.

The next issue is with automated content signing, which already was
proposed as a better alternative by some people in this thread. It
again may be better than nothing, but barely good at all. Users still
would be forced to trust the whole infrastructure, or more
specifically: its many parts, which, being compromised, would allow the
attacker access to the keys used for automatic signing.

Last but not least... How many times did you hear about some open source
project hosting was compromised? And how many times did you hear about
relevant SSL certificate tampering incidents? There's a risk assessment
issue here, which is IMHO underestimated and much more important than
all these talks about pros and cons of HTTPS.

Attachment: _bin
Description: