Topics

Prevent privacy being unintentionally leaked


Mike S <squeakypeep@...>
 

I would like to suggest not only the intrinsic value of privacy but
that leaking data poses unique security challenges, therefore
protecting user privacy is a valuable piece of criteria that ought to
be considered for inclusion into the program.

Example areas of concern include user data, as well as software
channel metadata subject to passive machine fingerprinting. Another
possibility being that this metadata could be used by state actors
within a hostile network to have a passively updated list of the
version numbers of front end facing components on each server. In this
example, the version numbers of software with serious bugs like
Heartbleed could be cross-referenced against which servers are running
the software without any direct interaction with the server, thus
passively revealing a list of vulnerable servers.

While I would hope this last example is not being exploited it remains
a possibility since popular distros seldom encrypt the entire
connection to software repositories. Most use unencrypted hash lists
as the sole way to ensure package integrity and many do not sign all
packages. While it is encouraging that this badge program would ensure
resolutions to this basic security flaw it would be great to see it
tackle some of the privacy issues outlined as well.

Thank you for your time,
Mike S.


Florian Weimer
 

* Mike S.:

Example areas of concern include user data, as well as software
channel metadata subject to passive machine fingerprinting. Another
possibility being that this metadata could be used by state actors
within a hostile network to have a passively updated list of the
version numbers of front end facing components on each server. In this
example, the version numbers of software with serious bugs like
Heartbleed could be cross-referenced against which servers are running
the software without any direct interaction with the server, thus
passively revealing a list of vulnerable servers.
If you care about this issue, you need to download *all* updates to a
local, trusted mirror, including those you do not need. Most
distributions already provide such mirroring scripts. Debian has so
many that it's difficult to keep track, Fedora has reposync at least.

While I would hope this last example is not being exploited it remains
a possibility since popular distros seldom encrypt the entire
connection to software repositories.
Anybody can run a mirror and contribute bandwidth, so encryption does
not help here.


Mike S <squeakypeep@...>
 

Thank you Florian, I am aware there are limited workarounds to some examples.

However we are talking about best practices here and these examples were simply to illustrate a point: Privacy is important for several reasons so transmitted data should be secure by design, rather than an afterthought.

Mike


David A. Wheeler
 

Mike S:
I would like to suggest not only the intrinsic value of privacy but that leaking data poses unique security challenges, therefore protecting user privacy is a valuable piece of criteria that ought to be considered for inclusion into the program.
Absolutely!

Example areas of concern include user data, as well as software channel metadata subject to passive machine fingerprinting. Another possibility being that this metadata could be used by state actors within a hostile network to have a passively updated list of the version numbers of front end facing components on each server. In this example, the version numbers of software with serious bugs like Heartbleed could be cross-referenced against which servers are running the software without any direct interaction with the server, thus passively revealing a list of vulnerable servers.
While I would hope this last example is not being exploited it remains a possibility since popular distros seldom encrypt the entire connection to software repositories. Most use unencrypted hash lists as the sole way to ensure package integrity and many do not sign all packages. While it is encouraging that this badge program would ensure resolutions to this basic security flaw it would be great to see it tackle some of the privacy issues outlined as well.
For our *initial* list of best practices - which I'm starting to call the "bronze" level - we want to focus on practices that are already widely practices, across many different ecosystems.

I don't think working to hide what version numbers are being downloaded is a common practice, and thus is unlikely to be at the "bronze" level. Florian Weimer noted, "Anybody can run a mirror and contribute bandwidth, so encryption does not help here." I think what he means is that many organizations use mirrors, and usually anyone can volunteer to be a mirror. Mirrors can easily track who is downloading what from them, and can easily implement fingerprinting. If you really want to hide what you're running, you probably want to run through an intermediary.

Privacy is important for several reasons so transmitted data should be secure by design, rather than an afterthought.
Agree. I'll add "privacy" as a note for potential future criteria, probably higher than the "bronze" level, as a kind of placeholder. However, that really is too vague to be useful. Can you propose a set of more specific criteria with MUST statements?

--- David A. Wheeler


Mike S <squeakypeep@...>
 

Hi David, that's great to hear.
I would hope to hear from others on specific criteria, there are plenty of use cases to consider. To start I propose this for mobile software.

Mobile apps at a minimum must use SSL and certificate pinning when transmitting data to a server. Third party code (analytics and advertising) used by an app must adhere to the highest security standards possible.

> I think what he means is that many organizations use mirrors, and usually anyone can volunteer to be a mirror.  Mirrors can easily track who is downloading what from them, and can easily implement fingerprinting.  If you really want to hide what you're running, you probably want to run through an intermediary.

If you don't mind getting offtopic I will comment on the notion of encrypting repo traffic. I believe implementing it is what some might call low hanging fruit, because the end user need not take any extra steps. Not much work for the distro either since it is already supported by apt, yum and so on. While true it does not solve the issue completely it mitigates risk of this sort of metadata profiling while en route. Sure a mirror may be hostile, on the other hand using rsync or a VPN adds complexity, or maybe your physical location makes it difficult to use these tools. Clearly neither approach is perfect but one requires no effort from end users and is therefore more practical.

Also, SSL is used with the equivalent software channels of all the other major operating systems (windows update, google play, mac app store). If you were updating your OS within a hostile network like China's, using these other systems could be an improvement if you were doing system updates because the Chinese would not have access to your metadata as part of their state-sponsored hacking programs. This could be true regardless of whether those official servers were considered trustworthy.

And honestly even if this were extremely implausible I just find it annoying to think that an OS like windows might be subtly superior to my favorite distros when it comes to protecting privacy and implementing encryption. So to my mind the question is not why encrypt repo traffic, it is why not?

Mike S.


David A. Wheeler
 

Mike S:

> Mobile apps at a minimum must use SSL and certificate pinning when transmitting data to a server.

Okay, let’s use that as a starting point, and see where we can get.  A few comments first. (1) You need to state an objective – why do this?  (2)  SSL (well, really TLS) is only one way to do this; I’d say “use encryption to maintain confidentiality and integrity”.  (3) This really isn’t limited to mobile apps.  I would expect this to apply to any clients. (4) ANY data to a server?  Surely there are many web sites that ONLY support unencrypted connections (e.g., http, ntp), and what about web browsers that can connect to unencrypted sites?  (5) Cert pinning is great, but it’s a *specific* approach, and there are problems doing so (captive portals, etc., all play havoc with it).  That said, it’s certainly one of the practical ones, and we can point to useful info like this: https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning (6) IETF keywords like “MUST” are usually capitalized.

Here’s an attempt to tweak the text, with the goal of making it general & achievable:

Client applications (including mobile applications) MUST by default use an encrypted channel to communicate over a network to protect confidentiality and integrity of all data exchanged with any specific site they are configured to connect to.  Applications SHOULD by default use this communication to all sites.  This channel would often be implemented using TLS, but other encryption protocols (such as IPSEC) MAY  be used.  This implementation SHOULD use certificate pinning.

> Third party code (analytics and advertising) used by an app must adhere to the highest security standards possible.

I have no idea what that means.  I’m sure they’ll say they’re already doing it J.  Can you be a LOT more specific so that people can rigorously say “yes it’s doing that” or “no it is not doing that”?

>> I think what he means is that many organizations use mirrors, and usually anyone can volunteer to be a mirror.  Mirrors can easily track who is downloading what from them, and can easily implement fingerprinting.  If you really want to hide what you're running, you probably want to run through an intermediary.

>If you don't mind getting offtopic I will comment on the notion of encrypting repo traffic. I believe implementing it is what some might call low hanging fruit, because the end user need not take any extra steps. Not much work for the distro either since it is already supported by apt, yum and so on. While true it does not solve the issue completely it mitigates risk of this sort of metadata profiling while en route. Sure a mirror may be hostile, on the other hand using rsync or a VPN adds complexity, or maybe your physical location makes it difficult to use these tools. Clearly neither approach is perfect but one requires no effort from end users and is therefore more practical.

I like the idea, however, I have concerns.  In particular, it’s NOT low-hanging fruit to a lot of folks.  Yes, the systems you listed already do it.  However, a lot of distribution systems do NOT support encrypting all repo traffic.  Cygwin, for example, uses mirrors of files with all data (and all downloads) public; they distribute a set of SHA-512 hashes, and sign that set to ensure that you’re only downloading valid files.  Changing that is *NOT* a low-hanging fruit to them.  I think organizations like this are very afraid of the overhead; encrypting individual files doesn’t take much, but it kills a lot of caching systems, which DOES create a lot of overhead.

So this “low-hanging fruit” is actually hard for a number of folks *AND* it doesn’t help against nation-states anyway.  If your worry is a nation-state, really the *ONLY* way is to pre-copy everything separately, since you probably can trust no one else anyway.  I guess maybe we *could* require it at an upper level, but I wouldn’t want to require it at a “basic” level.

That said, maybe we can write up something that described the specific requirements about supporting full encryption & integrity checking for software download/update, similar to the text above, and give it a spin.  Suggested text?

--- David A. Wheeler

 


Mike S <squeakypeep@...>
 

> starting point
Sounds good, I reached out to Holmes Wilson of FFTF and last year's privacy-focused Reset the Net campaign, he's joined the mailing list to help refine the criteria. I have no doubt he can propose better wording than I could.

I based the initial proposed criteria off an excellent article he wrote for developers wishing to implement privacy in their software, here's the article:
http://resetthenet.tumblr.com/post/84327981750/how-we-secure-our-phones-ssl-cert-pinning-pfs
In it 3rd party code is characterized as the weakest link in security so it appeared particularly relevant, but I am not sure what specific criteria could address this.

As to our conversation about fully encrypting software downloads/updates, I had not considered those points. Especially overhead, which makes sense considering the only distros I have seen encrypting all transmitted data from the software channel are run by Red Hat, who can no doubt afford it. I appreciate you educating me on the subject and if you believe it impractical I understand.

Mike S.

On Sun, Aug 23, 2015 at 6:57 PM, Wheeler, David A <dwheeler@...> wrote:

Mike S:

> Mobile apps at a minimum must use SSL and certificate pinning when transmitting data to a server.

Okay, let’s use that as a starting point, and see where we can get.  A few comments first. (1) You need to state an objective – why do this?  (2)  SSL (well, really TLS) is only one way to do this; I’d say “use encryption to maintain confidentiality and integrity”.  (3) This really isn’t limited to mobile apps.  I would expect this to apply to any clients. (4) ANY data to a server?  Surely there are many web sites that ONLY support unencrypted connections (e.g., http, ntp), and what about web browsers that can connect to unencrypted sites?  (5) Cert pinning is great, but it’s a *specific* approach, and there are problems doing so (captive portals, etc., all play havoc with it).  That said, it’s certainly one of the practical ones, and we can point to useful info like this: https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning (6) IETF keywords like “MUST” are usually capitalized.

Here’s an attempt to tweak the text, with the goal of making it general & achievable:

Client applications (including mobile applications) MUST by default use an encrypted channel to communicate over a network to protect confidentiality and integrity of all data exchanged with any specific site they are configured to connect to.  Applications SHOULD by default use this communication to all sites.  This channel would often be implemented using TLS, but other encryption protocols (such as IPSEC) MAY  be used.  This implementation SHOULD use certificate pinning.

> Third party code (analytics and advertising) used by an app must adhere to the highest security standards possible.

I have no idea what that means.  I’m sure they’ll say they’re already doing it J.  Can you be a LOT more specific so that people can rigorously say “yes it’s doing that” or “no it is not doing that”?

>> I think what he means is that many organizations use mirrors, and usually anyone can volunteer to be a mirror.  Mirrors can easily track who is downloading what from them, and can easily implement fingerprinting.  If you really want to hide what you're running, you probably want to run through an intermediary.

>If you don't mind getting offtopic I will comment on the notion of encrypting repo traffic. I believe implementing it is what some might call low hanging fruit, because the end user need not take any extra steps. Not much work for the distro either since it is already supported by apt, yum and so on. While true it does not solve the issue completely it mitigates risk of this sort of metadata profiling while en route. Sure a mirror may be hostile, on the other hand using rsync or a VPN adds complexity, or maybe your physical location makes it difficult to use these tools. Clearly neither approach is perfect but one requires no effort from end users and is therefore more practical.

I like the idea, however, I have concerns.  In particular, it’s NOT low-hanging fruit to a lot of folks.  Yes, the systems you listed already do it.  However, a lot of distribution systems do NOT support encrypting all repo traffic.  Cygwin, for example, uses mirrors of files with all data (and all downloads) public; they distribute a set of SHA-512 hashes, and sign that set to ensure that you’re only downloading valid files.  Changing that is *NOT* a low-hanging fruit to them.  I think organizations like this are very afraid of the overhead; encrypting individual files doesn’t take much, but it kills a lot of caching systems, which DOES create a lot of overhead.

So this “low-hanging fruit” is actually hard for a number of folks *AND* it doesn’t help against nation-states anyway.  If your worry is a nation-state, really the *ONLY* way is to pre-copy everything separately, since you probably can trust no one else anyway.  I guess maybe we *could* require it at an upper level, but I wouldn’t want to require it at a “basic” level.

That said, maybe we can write up something that described the specific requirements about supporting full encryption & integrity checking for software download/update, similar to the text above, and give it a spin.  Suggested text?

--- David A. Wheeler

 



David A. Wheeler
 

Mike S:

Sounds good, I reached out to Holmes Wilson of FFTF and last year's privacy-focused Reset the Net campaign, he's joined the mailing list to help refine the criteria. I have no doubt he can propose better wording than I could.
Thanks! Wording things precisely is tricky, so the more the help the better.

I based the initial proposed criteria off an excellent article he wrote for developers wishing to implement privacy in their software, here's the article:
http://resetthenet.tumblr.com/post/84327981750/how-we-secure-our-phones-ssl-cert-pinning-pfs
In it 3rd party code is characterized as the weakest link in security so it appeared particularly relevant, but I am not sure what specific criteria could address this.

Thanks. I've added that link to the "background" page.

As to our conversation about fully encrypting software downloads/updates, I had not considered those points. Especially overhead, which makes sense considering the only distros I have seen encrypting all transmitted data from the software channel are run by Red Hat, who can no doubt afford it. I appreciate you educating me on the subject and if you believe it impractical I understand.
Don't get me wrong, I *like* the idea! But if the criteria are too hard, people won't implement the criteria at all. So for the moment I'm proposing that this be a higher-level "silver" criteria. Here's my first try:
Releases MUST be downloadable through a channel that both encrypts and authenticates (e.g., TLS).
That way, third parties will not be able to determine
exactly what version is being downloaded, and this also provides some verification that the correct software is being downloaded from the site.

How's that? Suggestions welcome.

--- David A. Wheeler