Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 21 Aug 2013 14:13:55 -0600
From: Kurt Seifried <>
Subject: Re: HTTPS

Hash: SHA1

On 08/16/2013 10:28 PM, Pavel Labushev wrote:
> On Thu, 15 Aug 2013 02:44:33 -0400 Donald Stufft <>
> 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.

Right now the bar is so low as to be in the negative scale. Using
HTTPS instead of HTTP raises it, the attacker now has to compromise
the server, if they can do that, they could have also done it before
most likely, so adding HTTPS doesn't make things any worse/riskier.

I'm honestly tired of the "we shouldn't change the status quo of no
security because we might not do the new security perfectly", guess
what: you're not going to get any better at this without practise,
when I was in my early 20's O bought a copy of stronghold and an SSL
cert for, Thawte had no idea how to sell a certificate to
an individual (as opposed to a company), we compromised on a scan of
my passport (since I had no business papers for it, being that it was
just my name and not a company). Did I deploy SSL properly? in
retrospect not really. But that's why we do things, find the mistakes
and then correct them. And the only way to find a lot of these
mistakes is to actually do it. We can sit around and discuss possible
issues till the cows come home but that's not going to really help anyone.

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Version: GnuPG v1.4.14 (GNU/Linux)


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.