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