[Pidgin] #14565: Link to .asc file and offer download over TLS
Pidgin
trac at pidgin.im
Tue Sep 25 21:08:33 EDT 2012
#14565: Link to .asc file and offer download over TLS
-------------------------------------------------+-------------------------
Reporter: ioerror | Owner: rekkanoryo
Type: task | Status: new
Milestone: | Component:
Version: | unclassified
Keywords: security https tls pgp signature | Resolution:
win32 |
-------------------------------------------------+-------------------------
Comment (by ioerror):
Replying to [comment:13 datallah]:
> Replying to [comment:10 ioerror]:
> > Replying to [comment:8 datallah]:
> > > Since the 2.10.6 was released on 2012-07-06, there have been ~615K
downloads.
> > > The vast majority (530K) of these are the Windows installer, which
is about 10MB.
> > > On the top day for downloads, ~20K downloads, which means there was
~200GB downloaded on that day.
> > > The first month after it was released saw ~280K downloads, ~ 2.8TB.
> > >
> >
> > Ok - that isn't very much at all. I can imagine that if you offer a
secure mirror, you could get a good idea of how many people might use it.
> >
>
> > > I guess I'm wondering what real benefit SSL downloads will offer. I
understand the need for the ability to validate that the download hasn't
been tampered with, but SSL can't really do that in the same way that a
signature does.
> > >
> >
> > The main benefit is that nearly no one checks signatures other than
people who package software. Signatures are good and in some ways, they
are the best defense when the downloading party understands them. However,
most users in my experience and in looking at various stats on the
subject, simple do not check them - there is no easy way to do it on two
of the major platforms.
> >
> >
> > So the real benefit is that the bar is raised from an attacker who can
MITM HTTP (trivial) to an attacker who can MITM HTTPS (less than trivial
but still possible). Practically, I think this really improves the entire
stack of things, even one would need to check the gpg signature to
*really* know if things were as expected.
>
> I have no doubt that you're right - most users don't verify signatures.
It is shockingly bad but I guess that browsers, where most people download
software for the first time, is what they have. The browsers usually do
not take this into consideration, I think.
>
> Sure, it does raise the bar for MITM situations, but from a real
security perspective, it seems to me that hosting with a third party over
HTTPS vs. over HTTP doesn't really offer much more than the appearance of
being secure. I think I'd almost rather people notice that they're
downloading over "unsecure HTTP" and be worried about (and hopefully
verify signatures) it than for someone to see the little padlock on their
browser and think that everything is magically ok.
>
That is counter to reality though - hardly anyone verifies anything, even
over unsecure HTTP because verification of software is meaningless to
normal users. They expect the developers to do this stuff for them... just
like checking buffers or properly allocation of heap items. :)
It offers several things.
The first thing is that you can isolate a given mirror or download site;
you can create infrastructure that while you don't *trust* it per se, we
can *isolate it* easily. A downloading program can pin against the cert
and actually, we can automate *updates* to ensure that they are
*automatically* validated. We can cut the user out of the picture out of
the first leap of faith, I think. Justin Cappos has done a lot of work on
this topic - TUF being his crowning product.
The next thing is that it makes it harder for someone to be targeted or
for it to fail in a way that results in a user being less safe.
There are lots of other aspects but the most important is that it becomes
possible to detect tampering because it requires a lot more tampering by
an attacker.
For example - we could write scripts to browse all the secure mirrors to
look for compromised releases of software. We'd also be able to know that
it would be hard for an attacker to fool us and also target users if we
were able to isolate each server without having to worry much about the
network path.
This example doesn't require SSL but it sure can help - any other tls
certificate is just a MITM, plain and simple. That means we can tell a
user "hey, your network isn't working properly, sorry, we can't update" or
a browser can tell a user "hey, this cert is wrong - sorry, we're failing
to download what could be bad software."
I don't want to bash on source forge here but I think compromised mirrors
and network interception are a reality. The compromised mirror is
something that HTTPS doesn't resolve; the interception/injection proxies
are mostly solved by offering HTTPS.
Pidgin has to deal with both threats. If you haven't heard the news - I
guess this might concern you:
http://sourceforge.net/blog/phpmyadmin-back-door/
> >
> > > Sourceforge, for all it's warts, has done a good job of providing
redundant hosting with lots of mirrors located on several continents. I
feel like unless there is a compelling reason to reinvent the wheel, we
shouldn't be doing that.
> > >
> >
> > I suggest augmenting the wheel and seeing if there is demand. By
making an option, we'll be able to see if anyone cares to use the option.
As I stated, I'd be happy to run a secure mirror and I bet we can find
some others - the Tor Project does mirror some related projects on
https://archive.torproject.org/ - we might be able to do the same for
Pidgin.
>
> I'm not opposed to adding an SSL mirror if it were available and not too
painful to maintain. I do have some concerns about how to deal with
making the download pages not horribly busy and confusing with the
addition of additional SSL download links, the links to the GPG signatures
and the link to the page about signatures.
>
I agree - care must be taken here and I'm totally willing to help. You do
the windows builds, right? If you were to open a git mirror of the Pidgin
repo on github - it would be possible to post the latest build on their
HTTPS pages. I believe it will be served over HTTPS but I admit, I have
seen them re-direct to HTTP. :(
Tor would probably be willing to run a secure mirror - if we had a way to
automatically sync the packages, I'd be more than happy to write a program
to automate that process. Our users overlap with your users and we'd like
to try to help all of the Pidgin users, if we are able to do so.
Is there a way to rysnc data from a server of yours? Is it possible to
meet or verify GPG/PGP fingerprints of Pidgin people so that we might have
a connection in the web of trust?
> > Oh, my suggestion is a project in itself that will help all projects
who are in the current position. Tor has the same need - as does Pidgin -
Windows users need a way to verify signatures and currently, it is
basically not happening. I was suggesting a basic Windows application,
perhaps with wget and gpg embedded that perhaps will fetch a thing,
certainly verify it and we can make the website for it quite secure. That
is, we could embed the website's public key in Chrome (as is done for
Tor's https certs), enable HSTS, and create a unified tutorial for the
process. I realize it is out of scope for Pidgin but if such a tool is
interesting to you, I can imagine it might be worth considering...
>
> Sure, if there were such a tool available and it was functional and
practical, we'd certainly be interested in looking at it.
We have designed a tool sorta like this but it does a lot more - it is
called Thandy. It is based on Justin Cappos's work. The url for the basic
idea is here: https://www.updateframework.com/
In theory, I guess Thandy could be extended to take different key formats
and then handle nearly all of this stuff.
--
Ticket URL: <https://developer.pidgin.im/ticket/14565#comment:17>
Pidgin <http://pidgin.im>
Pidgin
More information about the Tracker
mailing list