Freenet in Whonix

Development
1

I was thinking on implementing the Freenet protocol and since Whonix is much more that just a Tor gateway due to its security hardening I thought maybe it would be a good idea to use Whonix as a base. At the time of implementing freenet, I would take into consideration other protocols that could also be added in the future. (So, make sure any changes required to allow Freenet to operate would be flexible enough to also be able to plug in others).

I imagine that a user would not want to use the same gateway to run both Tor and Freenet at the same time. Am I correct in this assumption? If so, then the user can run an additional gateway for Freenet, where Tor will be disabled. This really would not be an issue in Qubes, since we can just set property on the virtual machine so that bot Tor and Freenet can share the same base template without modification.

The Workstation can then be modified to handle either type of traffic, specifically the browser and possible addition of disk encryption.

Does anyone see any issues with this approach, and if so, any possible solutions.

2

Freenet - Is it alive? Just a clueless question.

I was thinking on implementing the Freenet protocol and since Whonix is much more that just a Tor gateway due to its security hardening I thought maybe it would be a good idea to use Whonix as a base. At the time of implementing freenet, I would take into consideration other protocols that could also be added in the future. (So, make sure any changes required to allow Freenet to operate would be flexible enough to also be able to plug in others).
Great!

Others have been partly thought through. Has been archived here for historical purposes:

It “just” needs someone caring deeply enough to develop it.

Yeah, Chaining Anonymizing Gateways would be great:

Pluggable Gateways. :slight_smile:

I imagine that a user would not want to use the same gateway to run both Tor and Freenet at the same time. Am I correct in this assumption?
I don't think so. Users want all sorts of things, combinations. Once one feature exists, they request more. That of course doesn't mean you ought to attempt the impossible: make everyone happy.

I speculate, that most would trust Tor more and would like to tunnel Freenet through Tor.

From Dev/Inspiration - Whonix

Freenet on the Whonix-Gateway (FreenetBOX)

Can be also potentially only be used parallel to Tor. It’s impossible to tunnel Freenet through Tor (see above). Also replacing Tor with Freenet is impossible, as freenet is a separated network, not designed to exit the network. Apt-get couldn’t work.

Not written yet.


The “see above” is apparently broken. I guess it was because freenet is UDP-only and Tor is TCP-only? You’ll soon find out, I guess.

Does anyone see any issues with this approach, and if so, any possible solutions.
The build script now supports --flavor whonix-gateway and so forth. Would be interesting to have a --flavor free-gateway or so that installs a different package selection. Or better separate flavors can be avoided and which mode could be configured in whonix-setup-wizard or a special boot parameter / hardware info (virtualbox setextradata alike) or so.

(I would avoid using literal ‘freenet’ in subproject names as long as trademark issues aren’t sorted out because renaming this later is a lot hassle.)

3

That is a good question :slight_smile: I think so. I downloaded it yesterday to check it out and seemed like a difficult task to secure and configure it so thought it may be a good fit to sit within Whonix since most all the functionality is already within Whonix such as firewall, etc and would be easier to implement a Qubes proxyvm using Whonix.

Not sure if its even worth while to do, so that prompted the topic question. I would need to create a Debian package for it and provide some type of default configuration as well as a configuration scripts to enable / disable it which I was planning to use salt for that as I have already written a Debian and Fedora package for it as well (Hehe, was really thinking where else can I use this new salt package I put together to configure stuff :slight_smile:

[quote]I was thinking on implementing the Freenet protocol and since Whonix is much more that just a Tor gateway due to its security hardening I thought maybe it would be a good idea to use Whonix as a base. At the time of implementing freenet, I would take into consideration other protocols that could also be added in the future. (So, make sure any changes required to allow Freenet to operate would be flexible enough to also be able to plug in others).[/quote] Great!

Others have been partly thought through. Has been archived here for historical purposes:

It “just” needs someone caring deeply enough to develop it.

Yeah, Chaining Anonymizing Gateways would be great:

Pluggable Gateways. :slight_smile:

I don’t think so. Users want all sorts of things, combinations. Once one feature exists, they request more. That of course doesn’t mean you ought to attempt the impossible: make everyone happy.

I speculate, that most would trust Tor more and would like to tunnel Freenet through Tor.

From Dev/Inspiration - Whonix

[quote]Freenet on the Whonix-Gateway (FreenetBOX)

Can be also potentially only be used parallel to Tor. It’s impossible to tunnel Freenet through Tor (see above). Also replacing Tor with Freenet is impossible, as freenet is a separated network, not designed to exit the network. Apt-get couldn’t work.

Not written yet. [/quote]
The “see above” is apparently broken. I guess it was because freenet is UDP-only and Tor is TCP-only? You’ll soon find out, I guess.

The build script now supports --flavor whonix-gateway and so forth. Would be interesting to have a --flavor free-gateway or so that installs a different package selection. Or better separate flavors can be avoided and which mode could be configured in whonix-setup-wizard or a special boot parameter / hardware info (virtualbox setextradata alike) or so.

(I would avoid using literal ‘freenet’ in subproject names as long as trademark issues aren’t sorted out because renaming this later is a lot hassle.)

I will take a look at the links you provided, thanks.

I do believe you are correct in stating it uses UDP packets, I think i2p also has that limitation; too bad. Maybe there are other networks it can be routed over other than Tor as most people would not have access to using a VPN to tunnel UDP traffic though Tor?

4

The onioncat may be useful, since there may be something wrong with the -U option.

5
I would need to create a Debian package for it and provide some type of default configuration
See also: - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481163 - https://wiki.debian.org/Freenet
as well as a configuration scripts to enable / disable it which I was planning to use salt for that
I am skeptical if non-standard ways to maintain Debian packages won't be causing issues later during maintenance.
as I have already written a Debian and Fedora package for it as well (Hehe, was really thinking where else can I use this new salt package I put together to configure stuff :)
Can you please post a link to that package using salt? I would like to check it out.
I do believe you are correct in stating it uses UDP packets, I think i2p also has that limitation; too bad.
i2p has a TCP-only mode and works over Tor, documented here: https://www.whonix.org/wiki/I2p
Maybe there are other networks it can be routed over other than Tor
JonDo perhaps. But with limitations. And there is no package of JonDo in Debian. And I am not sure it's worthwhile either or if development of it kinda stalled. Tor over JonDo on Whonix-Gateway would not be that hard, as per https://www.whonix.org/forum/index.php/topic,1116.0.html, just needs someone to document it.

Otherwise last time I checked there were not that many worthwhile networks that motivated me to do it.

The ones that are known to exist are listed here:

Perhaps there are others, but no one ever suggested them, which would indicate, that those aren’t worthwhile.

Often discussed are VPNs. Followed by proxies. So I guess a gateway for those would be more worthwhile. Anyhow. It’s up to you and I find any of these endeavors interesting.

as most people would not have access to using a VPN to tunnel UDP traffic though Tor?
(https://www.whonix.org/wiki/Tunnel_UDP_over_Tor) Yes and this requirement is also quite cumbersome.
6

See also:

[quote]as well as a configuration scripts to enable / disable it which I was planning to use salt for that[/quote] I am skeptical if non-standard ways to maintain Debian packages won't be causing issues later during maintenance.
You are so skeptical about everything :) For the most part when dealing with packages and repos, etc salt uses the functionality of the distribution it is installed on. Therefore it would be considered standard compared to non-standard I would think.
[quote]as I have already written a Debian and Fedora package for it as well (Hehe, was really thinking where else can I use this new salt package I put together to configure stuff :)[/quote] Can you please post a link to that package using salt? I would like to check it out.
Currently I have 2 packages. One that installs the latest 'supported (as in supported by my implementation)' version of salt [url=https://github.com/nrgaway/qubes-app-salt]https://github.com/nrgaway/qubes-app-salt[/url]

and the configuration files (which included installing them in proper locations)
https://github.com/nrgaway/qubes-app-salt-config

Note the configuration files are still work-in-progress and are not finalized as this is considered a proof-of-concept at this stage, but they are mostly functional for Fedora, Wheezy and Jessie and are designed for Qubes dom0 and AppVMs at the moment.

The AppVM modules should also work on bare metal or other VMs such as Virtualbox.

[quote]I do believe you are correct in stating it uses UDP packets, I think i2p also has that limitation; too bad. [/quote] i2p has a TCP-only mode and works over Tor, documented here: https://www.whonix.org/wiki/I2p

JonDo perhaps. But with limitations. And there is no package of JonDo in Debian. And I am not sure it’s worthwhile either or if development of it kinda stalled.
Tor over JonDo on Whonix-Gateway would not be that hard, as per Whonix Forum, just needs someone to document it.

Otherwise last time I checked there were not that many worthwhile networks that motivated me to do it.

The ones that are known to exist are listed here:

Perhaps there are others, but no one ever suggested them, which would indicate, that those aren’t worthwhile.

Often discussed are VPNs. Followed by proxies. So I guess a gateway for those would be more worthwhile. Anyhow. It’s up to you and I find any of these endeavors interesting.

(Tunnel UDP over Tor - Whonix) Yes and this requirement is also quite cumbersome.


This also interests me as well. I will be looking at it in between compiles and such and would not expect to implement it until I complete the ‘app-salt-config’ package and Whonix 10 build and would also depend on the PITA factor of maintaining the Debian package for freenet. I think it may be worthwhile to find out why it was abandoned in the first place.

7
Nice! Seems like someone created a Debian package a few years ago an abandoned it. May be a good starting point for creating a new package that would also build freenet
Yes.
You are so skeptical about everything :)
Yes, but not because I am evil, because breakage easily happens. ;)

For qubes-9.x for example we now have the “stable rather than wheezy” upgrade issue as well as the “/etc/hosts immutable” issue. Once users run into these, those are difficult to resolve. Those can most times be resolved, aka “edit this postinst script, add ‘exit 0’ below ‘#!/bin/bash’” or such instructions, but that’s cumbersome for users to do and for us to support.

Maybe we have different assumptions, goals. My goal is to maintain a super simple linux distribution that is easily upgradeable, ideally without need for special commands other than the usual upgrade commands. Any package manger issues generates lots of, partly concerned, support requests. The more users, the more support requests.

We could very well end up in a situation where we need to say “no, you cannot [easily] upgrade qubes-whonix 9 to qubes-whonix-10 [unsupported]”. This is not the end of days, but bad. Then users wonder why that is and how to migrate and run into migration issues and so forth. And other users who stick with old versions and then create invalid bug reports. Otherwise we need to maintain special instructions for upgrading and then helping lots of users with special cases. Or just write the instructions and then give a damn about it. Let users figure out themselves and ignore the questions. All non-ideal.

I think non-clean solutions, packaging issues lead to a lot bugs that generate a lot extra work. Therefore it’s my strategy to try getting up real solutions [upstream] rather than distribution specific hacks and workarounds. Because those hacks and workarounds pile up. I fear they pile up to a state where complexity gets unmanageable. Each special case needs explanation, gets questioned every now and then, is prone to interaction bugs with other packages and still needs to be understood in two years from now. Therefore it’s my strategy to use existing tools rather than reinventions if sane, using standard tools, policy conform, lintian clean packages, again with the goal of having very few bugs, simplicity and no package manager upgrade issues.

For the most part when dealing with packages and repos, etc salt uses the functionality of the distribution it is installed on. Therefore it would be considered standard compared to non-standard I would think.
Doesn't sounds too bad.
and would also depend on the PITA factor of maintaining the Debian package for freenet.
I think it may be worthwhile to find out why it was abandoned in the first place.
Yes.

By the way, there is this team that might be interested:
https://wiki.debian.org/Teams/AnonymityTools

Once you created a Debian policy conform, lintian clean Debian package, they might takeover the regular maintenance upgrades.

8

if the gateways run in paraallel it would be nice to have one browser or browser profile with a custom theme for visual distinguishability for each gateway. like proposed here to distinguish tor and normal browser:

9

Could you review Freenet: Difference between revisions - Whonix please? @HulaHoop

1 Like
10

Looks legit. Did a few more tocuch ups.

1 Like
11

Could you review Freenet: Difference between revisions - Whonix please? @HulaHoop

1 Like
12

Could you review Freenet: Difference between revisions - Whonix please? @HulaHoop

1 Like
13

Could you review Freenet: Difference between revisions - Whonix please? @HulaHoop

1 Like
14

Looks good

1 Like