Fwd: Leaking data over HTTP

[Steve Dodier-Lazaro]

Hi everyone,

This email is for all app/plugin devs whose app requires an Internet
connection. Read the email below from GNOME's security mailing list. It'd
be a great idea to catalogue how our apps use APIs and how other apps or
third parties could spy on our users. I'm not suggesting we take action yet
-- the design SIG and everyone else is busy, but at some point we can look
at how we can secure API channels and put users in control of remaining
privacy leaks.

Catalogue here: https://wiki.xfce.org/security/api-privacy/start

Cheers,

---------- Forwarded message ----------
From: Elad Alfassa <elad at fedoraproject.org>
Date: 24 January 2015 at 18:31
Subject: Leaking data over HTTP
To: "safety-list at gnome.org" <safety-list at gnome.org>


Hi all.

During GUADEC 2014 (wow, that was a long time ago) we discussed
problems with applications leaking private or otherwise uniquely
identifiable user data over plain text.

I did some testing today, and it seems that we improved in that
regard, so that's great!
However, there are still some cases for which we need to find a
solution. Some of the external APIs GNOME apps use do not support
HTTPS, others support HTTPS but have a certificate which is only valid
for other CNs.

So far, I have found that two apps still suffer from this problem, but
my testing was very limited so assume there are more.

The first one is GNOME Weather (or rather, libgweather): the weather
APIs it uses are not available over HTTPS. This means every time you
open this app, the recent locations you viewed in it will be sent to
various weather services and anyone listening on your wifi network
(for example) can get that list.

Since these weather services are not available over https, there's not
much we can do about it, unless gnome (or another trusted party) sets
up an https reverse proxy server for these services.

Another app that suffers from this problem is GNOME Music[1]. Every
time you open GNOME Music, it will query last.fm for data about your
albums in plain text. Since each of us has a unique taste in music and
a different set of albums, this data can be used to identify you on
the network.

Unlike the other case, last.fm does support HTTPS, but the CDN where
it serves the images from serves a certificate with a CN valid for
something.something.akamai.net and not the actual domain name we use,
so even if we switch to using the HTTPS last.fm API endpoint, we will
still end up leaking data over HTTP.

A solution for this problem would be being able to define what CNs we
are expecting when making the request using libsoup, so we could
request, for example, userserve-ak.last.fm/foo/bar and tell libsoup to
accept, for example, *.e.akamai.net as a valid CN.


Unfortunately, I'm not optimistic about either of these solutions
happening, and Weather and Music will continue to leak this kind of
data in plain text... And there's no way for us to communicate this in
the UI for the users in a way that won't scare them too much, I think.

Thoughts?

[1] Via grilo plugins - specifically the last.fm one. I've also
submitted a patch to make other, less used grilo plugins use HTTPS:
https://bugzilla.gnome.org/show_bug.cgi?id=743449
--
-Elad Alfassa.
_______________________________________________
safety-list mailing list
safety-list at gnome.org
https://mail.gnome.org/mailman/listinfo/safety-list



-- 
Steve Dodier-Lazaro
PhD Student
University College London
Free Software Developer
OpenPGP : 1B6B1670
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.xfce.org/pipermail/xfce4-dev/attachments/20150126/48d72bde/attachment.html>