Hi,

I'm more hardware oriented, so I'm not so familiar with this kind of
security structures, but...

On 10.04.2018 19:15, Peter Müller wrote:
> 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.]

Jm2c:
Sounds reasonable. Agreed. Mirrors should be as secure as possible. Yes.

> (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).

Being more on the hardware side, I must confess, I don't know what the
main consequences would be. No firm opinion...

> 
> (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.

ACK.

> 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.

ACK.

> (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?

I never used Tor and don't plan to use it in the future, so I can't say
much about this.

> (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?

Same as above: I don't know what the main consequences would be and how
'libloc' really works. But it sounds reasonable. Yes.

> Looking forward to read your comments.

Since you didnt' get much answers until now, I hope this one helps a
bit... ;-)

> Thanks, and best regards,
> Peter Müller
> 

Best,
Matthias