[Discussion] Privacy and security for IPFire updates

["Peter Müller" <peter.mueller@link38.eu>]

[-- Attachment #1: Type: text/plain, Size: 4504 bytes --]

Hello,

a few days ago, I had a discussion with Michael about
privacy and security for IPFire updates (we mainly
focused on IPFire 3.x, but some points might be
applicable to 2.x, too).

In order to get some more opinions about this, I would
like to mention the main points here and ask for comments.
Forgive me if you receive this mail twice; I'll post
it on both development and mirror list.

(a) Security
Whenever you are updating an application or an entire
operating systems, security is the most important
aspect: An attacker must not be able to manipulate update
packages, or fake information about the current patchlevel,
or something similar.

In the past, we saw several incidents here - perhaps
the most famous one was "Flame" (also known as "Flamer" or
"Skywiper"), a sophisticated malware which was detected
in Q1/2012 and spread via Windows Updates with a valid
signature - and it turned out that strong cryptography
is a very good way to be more robust here.

In IPFire 2.x, we recently switched from SHA1 to SHA512
for the Pakfire signatures, and plan to change the signing
key (which is currently a 1024-bit-DSA one) with Core
Update 121 to a more secure one.

So far, so good.

Speaking about IPFire 3.x, we plan to download updates
over HTTPS only (see below why). However, there are still
a few questions left:
(i) Should we sign the mirror list?
In 3.x, using a custom mirror (i.e. in a company network) will
be possible. If not specified, we use the public mirror
infrastructure; a list of all servers and paths will
be published as it already is today.

In my opinion, we should sign that list, too, to prevent
an attacker from inserting his/her mirror silently. On
the other hand, packages are sill signed, so a manipulation
here would not be possible (and we do not have to trust our
mirrors), but an attacker might still gather some metadata.

[The mirror list can be viewed at https://mirrors.ipfire.org/,
if anyone is interested.]

(ii) Should we introduce signers?
A package built for IPFire 3.x will be signed at the builder
using a custom key for each machine. Since malicious activity
might took place during the build, the key might became
compromised.

Some Linux distributions are using dedicated signers, which
are only signing data but never unpack or execute them. That
way, we could also move the signing keys to a HSM (example:
https://www.nitrokey.com/) and run the server at a secure
location (not in a public data centre).


(b) Privacy
Fetching updates typically leaks a lot of information (such
as your current patch level, or systems architecture, or
IP address). By using HTTPS only, we avoid information leaks
to eavesdroppers, which I consider a security benefit, too.

However, a mirror operator still has access to those information.
Perhaps the IP address is the most critical one, since it
allows tracing a system back to a city/country, or even to
an organisation.

Because of that, I do consider mirrors to be somewhat critical,
and would like to see the list singed in 3.x, too.

(i) Should we introduce mirror servers in the Tor network?
One way to solve this problem is to download updates via a
proxy, or an anonymisation network. In most cases, Tor fits
the bill.

For best privacy, some mirror servers could be operated as
so-called "hidden services", so traffic won't even leave the
Tor network and pass some exit nodes. (Debian runs several
services that way, including package mirrors: https://onion.debian.org/ .)

Since Tor is considered bad traffic in some corporate network
(or even states), this technique should be disabled by
default.

What are your opinions here?

(ii) Reducing update connections to anybody else
Some resources (GeoIP database, IDS rulesets, proxy blacklists)
are currently not fetched via the IPFire mirrors, causing
some of the problems mentioned above.

For example, to fetch the GeoIP database, all systems sooner
or later connect to "geolite.maxmind.com", so we can assume
they see a lot of IP addresses IPFire systems are located behind. :-\
Michael and I are currently working on a replacement for
this, called "libloc", but that is a different topic.

Pushing all these resources into packages (if they are
free, of course) and deliver them over our own mirrors would
reduce some traffic to third party servers here. For libloc,
we plan to do so.

Should we do this for other resources such as rulesets and
blacklists, too?


Looking forward to read your comments.

Thanks, and best regards,
Peter Müller