We host our own infrastructure here and use multiple mirror servers to cope with the amount of downloads and also to provide good redundancy. After all it is not too bad to host this project from the bandwidth’s perspective since most people update anyway and for our new users, the OS image is not too large. It only has about ~150-200MB depending on the image you are downloading.
However, we still provide torrent downloads which are useful for people who cannot reach our website which unfortunately seems to be blocked in some countries. Just getting the magnet URL is enough to download it.
They are also useful because we do not have to provide 100% of the bandwidth and they also check the integrity of the downloaded file.
To provide communication between the multiple peers that want to download a torrent file and the seeders who have some parts of the file or the entire file ready to be uploaded again, a database called the tracker is being used. It just exchanges IP addresses and the peers spin up a peer-to-peer network and transfer the data directly.
That tracker was implemented in our webapp that is hosting the website, this blog, fireinfo and some more things, but it was not really the best implementation there is. It was stable, it was good, but it was not too efficient by using a PostgreSQL backend and unfortunately had some bugs when it came to peers with IPv6 access as well as IPv4 access.
So to make our infrastructure leaner, faster and generally better, I installed opentracker which we used to use in the past before we wrote our own implementation. Since then it has grown a bit and is now available in repositories of CentOS which we use on many of our servers. Hence I installed it quickly, configured it and did the switch. For a few weeks now, the torrent tracker has been running on opentracker and it just works.
The tracker part of the webapp has been removed which takes quite a load off of it and we switched from an open tracker to a closed one which will only accept our own torrent files. On top of the HTTP protocol, we also support contacting the tracker over UDP and we are running two instances of opentracker; one for IPv4 and one for IPv6.
Next time maybe, you might want to use the torrent network to download a disk image of IPFire. I still find it a very fascinating way to exchange data and although people instantly think about sharing the wrong things, the torrent network is used a lot to distribute files like this and even commercial vendors of games and similar large files use it.
Since we have never really been to good to put news about this project into the press, we are now starting to implement a few things that we are becoming better at this. It is a pitty to me that we are having such a nice project here but too few people know about it.
It is nice to read stories talking about their problems that they have had for years and that end with “until I found out about IPFire”, but why didn’t they find out about it earlier?
We have a new mailing list now for the press now which is for journalists, editors and writers where we will pre-announce things that are going on. For example the release of a new major version of IPFire or just the next Core Update. There is no need to subscribe for our regular users since you won’t miss out on anything as long as you make sure to be subscribed on the announcement mailing list.
The press list is non-public (since we don’t want to ruin the surprise for everyone) but open to subscribe for everyone. Subscriptions need to be approved, so please make sure to use the email address for the newspaper/magazine/blog you are writing for. It is open to post for everyone in case there are any questions.
Please forward this message to everyone you think should be subscribed and please everyone help us to make our project better-known.
Just days after releasing Core Update 115 with our brand new Captive Portal, we already have the next one in the testing tree which brings some fixes for security vulnerabilities in
wget as well as some bug fixes.
The original announcement of the OpenSSL project states two security vulnerabilities with one being of moderate and one being of low severity:
bn_sqrx8x_internal carry bug on x86_64 (CVE-2017-3736)
There is a carry propagating bug in the x86_64 Montgomery squaring procedure. No
EC algorithms are affected. Analysis suggests that attacks against RSA and DSA
as a result of this defect would be very difficult to perform and are not
believed likely. Attacks against DH are considered just feasible (although very
difficult) because most of the work necessary to deduce information
about a private key may be performed offline. The amount of resources
required for such an attack would be very significant and likely only
accessible to a limited number of attackers. An attacker would
additionally need online access to an unpatched system using the target
private key in a scenario with persistent DH parameters and a private
key that is shared between multiple clients.
This only affects processors that support the BMI1, BMI2 and ADX extensions like
Intel Broadwell (5th generation) and later or AMD Ryzen.
Note: This issue is very similar to CVE-2017-3732 and CVE-2015-3193 but must be
treated as a separate problem.
This issue was reported to OpenSSL on 10th August 2017 by the OSS-Fuzz project.
The fix was developed by Andy Polyakov of the OpenSSL development team.
Malformed X.509 IPAddressFamily could cause OOB read (CVE-2017-3735)
If an X.509 certificate has a malformed IPAddressFamily extension,
OpenSSL could do a one-byte buffer overread. The most likely result
would be an erroneous display of the certificate in text format.
This bug has been present since 2006.
This issue was found by Google’s OSS-Fuzz project on August 22.
The fix was developed by Rich Salz of the OpenSSL development team.
snorthas been updated to version 2.9.11.
wgetalso suffered from two security vulnerabilities that allowed an attacker to execute arbitrary code. They are referenced under CVE-2017-13089 and CVE-2017-13090.
apachewas updated to version 2.4.29 which fixes a number of bugs.
xzhas also been updated to version 5.2.3 which brings various improvements.
We are going to release this update as soon as possible and hope to hear any feedback from you in case you find any problems or new bugs in it.
Finally, we have made the move to host all of our services over TLS only. That means that any website or file that is being downloaded, any email that is being sent or received is being encrypted. Everything is secure now! Well… not really. This is a brief article about TLS considerations and some real-world issues with it.
Up until about two weeks ago, none of the IPFire web services had a certificate – with a few exceptions. If you went onto our main website, you would have just connected over HTTP and that is it. There was no TLS involved whatsoever. It didn’t need it really. At no time any personal data was being transferred. It was just our website which is publicly available for everyone.
For some web services like Bugzilla and some more we used our own CA. That allowed us to issue our own certificates with what ever settings we wanted and we could deploy them very easily. One main incentive was to avoid paying for a number of certificates at a public CA which wasn’t possible for such a number of certificates and being as underfunded as we are it was a wrong place to invest the money. I toyed around with DANE for a little bit, but since no web browser implements this, this is nothing better than a trial.
But those days are gone now. Over the last weeks I abandoned the IPFire CA and replaced any existing certificates by certificates from Let’s Encrypt. It has been suggested many times by many users but I refused to do it because I do not really see the point of just encrypting everything for the sake of encryption. Encryption is from my point of view very useless in the case of our main website and mirror servers.
In addition to the sites that already had a certificate, I set up Let’s Encrypt for literally everything else, too. And since this only makes sense if everyone is using TLS, we now redirect every HTTP request to HTTPS first before having our web server replying to it. That means any website, any download is now going over HTTPS.
To enforce that, we use HTTP Strict Transport Security (or HSTS) which lets every browser remember, that “www.ipfire.org” is only available over HTTPS. The next time, you enter that domain into your address bar, the browser will remember to connect over HTTPS only.
Additionally, we use OCSP Stapling, which will help to improve the speed of setting up the first TLS connection. The browser would contact the CA which is Let’s Encrypt in our case and check if the certificate that has been received from the web server is still valid or has been revoked. That takes some time since it is an extra TCP connection and the CA has to respond to a large number of these OCSP requests.
Instead, our web server does this for you and staples the OCSP response to the TLS handshake. It is signed and therefore the browser can trust it without having to contact the CA to verify.
On top of that, we cache TLS sessions to resume them faster.
We only allow the browsers to use TLS 1.2. Anything else is not possible since they are considered broken or cryptographically weak.
And finally, we reviewed the list of allowed ciphers and removed anything else but AES256 and AES128 in GCM mode or in CBC mode with SHA384 or SHA256. We introduced using ChaCha20 with Poly1305.
The key handshare is only possible using either the Elliptic Curve Diffie Hellman algorithm or ECDSA. None of which rely on a discrete logarithm.
This is now all new and shiny with icing on top. Latest cryptography. Strongest ciphers. What could go wrong?
We will inevitably kick out a number of users here to enforce these new things. That is at least: Firefox 26 and older, Chrome 29 and older, IE 10 and older, Opera 16 and older, Safari 8 and older and Android 4 and older. Those devices and browser won’t be able to contact our web servers securely and more and since we insist using TLS only, they won’t be able to connect with us at all.
The idea is to try this out now. If you have issues connecting and it should work, please let us know. This will need to be a trade-off of what is good security and what people actually use. But I do have the intention to force you XP users out there to finally upgrade. It’s 2017.
All these things happened during our yearly security review and updating where we check if every part of our infrastructure is using the best possible security that is available to us.
Of course we also added Let’s Encrypt certificates to our other services like Mail and XMPP. But we are not fully done and will need to improve more when ever there is time to do so.