ID: 114PHID: PHID-TASK-k7j6lm6si5yenz4byylzAuthor: JasonJAyalaPStatus at Migration Time: openPriority at Migration Time: Normal
Implement the Permanent Takedown Attack Defender Proposal into #whonixcheck .
Or better. Upstream the whole thing; Create an emergency news notification mechanism including a Permanent Takedown Attack Defender implementation that Debian would adapt.
2015-06-05 05:25:22 UTC
2015-06-05 13:52:41 UTC
2016-12-16 16:06:42 UTC
2016-12-16 16:28:42 UTC
2016-12-16 16:50:08 UTC
Maybe if they see the potential to grow their userbase they may be convinced.
DRAFT:
Hi. Whonix [0] dev here.
We are looking for a censorship-resistant and decentralized way to communicate notifications about critical situations [1] to our users and host the project metadata and files themselves to resist a Permanent Takedown Attack threat.[2] Freenet meets our needs perfectly but unfortunately as documented it cannot work over Tor. If this changes in the short term we will be able to ship it in our distro to a userbase of 15K users by conservative estimates.
Other points:
pyFreenet is very convenient in communicating with Freenet with scripts. Is there a similar mechanism that we can use to customize node settings?
Before including pyFreenet we would need it to be signed by its respective dev so we can validate it before running anything of course.
[0] Whoix is an anonymous Debian based OS (whonix.org )
[1] Apt CVE-2016-1252: During apt-get upgrading signature verification can be
[2] Dev/Permanent Takedown Attack Defender - Kicksecure
2016-12-16 17:09:37 UTC
2016-12-16 18:16:19 UTC
2016-12-16 19:02:26 UTC
2016-12-17 01:13:11 UTC
Got a reply: https://emu.freenetproject.org/pipermail/devl/2016-December/039438.html
My response (Please make suggestions/necessary additions) :
There is a way to route connections over Tor, but it isn’t tested regularly and currently only works in friend-to-friend mode. For details see:
While a neat workaround unfortunately its days are numbered. The upstream development of onioncat is dead and with the Tor project’s upgrading of the Hidden Service crypto (within the upcoming year) onioncat will no longer function. We also don’t want every user to run a Hidden Service by default since some deanonymization attacks become easier to do.
I do not doubt Freenet’s anonymity capabilities. You should be proud of the fact that you got the NSA’s attention. However for this to work we need it to run for all our users out of the box and a number of them live behind state firewalls that block Freenet and Tor without bridges. So without a solution that is compatible with Tor, it won’t be enough - an emergency notification system is of little use if it works for some users some of the time.
Another point is that even in “free” societies the police are convincing the courts to give them warrants with fraudulent data to raid people running Freenet. A couple of high coverage arrests are enough to scare away a number of people. While running nodes over Tor with TCP support is not optimal for Freenet network performance it is still to your advantage than not having those nodes run at all IMHO.
I am not conceited to assume that your priorities are planned around our wishlist. I also understand that building an alternative transport is a major task. If it wasn’t for this obstacle we could immediately use Freenet for our purposes. Thank you for the work you have put into creating a better internet.
Also you can modify the configuration from pyFreenet but I did not test that in a long time:
Good to know. Thanks.
auto-spawning currently downloads Freenet over the internet, though. Doing this download over Tor shouldn’t be hard. In fact it just requires setting the proxy:
Is that when updating Freenet?
I’m the current maintainer. Do you need gpg signed git revisions or tags, signed release tarballs or signed Mercurial commits?
Signed tarballs should do it.
Tell me how I can easily integrate that into my release process and I can do that.
[This is the part where Patrick shares his packaging expertise]
pyFreenet consist purely of Python packages, without need of compilation steps.
I understand. We can’t rely on pip because it lacks GPG support. Please also consider providing Freenet in signed .deb form so we can easily provide that package via our repos.
2016-12-17 01:13:55 UTC
! In T114#11035, @HulaHoop wrote:https://emu.freenetproject.org/pipermail/devl/2016-December/039438.html
My response (Please make suggestions/necessary additions) :
There is a way to route connections over Tor, but it isn’t tested regularly and currently only works in friend-to-friend mode. For details see:
While a neat workaround unfortunately its days are numbered. The upstream development of onioncat is dead and with the Tor project’s upgrading of the Hidden Service crypto (within the upcoming year) onioncat will no longer function. We also don’t want every user to run a Hidden Service by default since some deanonymization attacks become easier to do.
Although I could not read his link (no freenet running), but I guess this is valid since onionshare deprecated, everyone running hidden service deal breaker indeed.
“Ideally” we need Freenet in open mode over Tor so it just works. Otherwise if infrastructure maintenance is required it could take a very long time until we get there.
I do not doubt Freenet’s anonymity capabilities. You should be proud of the fact that you got the NSA’s attention. However for this to work we need it to run for all our users out of the box and a number of them live behind state firewalls that block Freenet and Tor without bridges. So without a solution that is compatible with Tor, it won’t be enough - an emergency notification system is of little use if it works for some users some of the time.
Yes.
Another point is that even in “free” societies the police are convincing the courts to give them warrants with fraudulent data to raid people running Freenet. A couple of high coverage arrests are enough to scare away a number of people. While running nodes over Tor with TCP support is not optimal for Freenet network performance it is still to your advantage than not having those nodes run at all IMHO.
Maybe make the last sentence a question instead.
Also you can modify the configuration from pyFreenet but I did not test that in a long time:
Good to know. Thanks.
auto-spawning currently downloads Freenet over the internet, though. Doing this download over Tor shouldn’t be hard. In fact it just requires setting the proxy:
Is that when updating Freenet?
Good question.
I’m the current maintainer. Do you need gpg signed git revisions or tags, signed release tarballs or signed Mercurial commits?
Signed tarballs should do it.
We need a signed deb.
Tell me how I can easily integrate that into my release process and I can do that.
[This is the part where Patrick shares his packaging expertise]
Well, not something I can do in 5 minutes.
reprepro - https://mirrorer.alioth.debian.org/
Works really nice and really nice upstream that can be contacted by mail.
“If you have problems and/or suggestions, just write me an email. (You can read the FAQ first if you fear to ask a stupid question, but I really get few enough mails that some more will not harm).”
Can be be scripted. Once Debian packaging is done - not easy - I never packages anything-java - I can certainly help with write some bash scripts to automate reprepro debian repository creation.
The bigger blocker for now is getting freenet to work in “easy” mode, i.e. in open mode directly over Tor. Also other modes where we need to set up infrastructure may be doable - one day. Or modes where freenet runs in parallel to Tor on the gateway (probably hard and a lot to think about, bridges, liabilities and whatnot). The “harder” mode just make the implementation of this ticket even less realistic anytime soon - unless someone takes the lead on this one.
pyFreenet consist purely of Python packages, without need of compilation steps.
I understand. We can’t rely on pip because it lacks GPG support. Please also consider providing Freenet in signed .deb form so we can easily provide that package via our repos.
Yes.
2016-12-17 04:12:27 UTC
Sent. https://emu.freenetproject.org/pipermail/devl/2016-December/039440.html
Although I could not read his link (no freenet running), but I guess this is valid since onionshare deprecated, everyone running hidden service deal breaker indeed.
Its a mirror of this post:
Using Freenet over Tor
And since it depends on onioncat its not a solution. Neither does the suggestion to roll our own infrastructure since that too depends on onioncat and running everyone as a HS - both a no go.
2016-12-18 01:18:49 UTC
2016-12-18 01:49:15 UTC
Huzzah. Unto the GNUnet. Could be our ace in the hole.
Advantages:
Packaged in Debian
Clean/extremely modular design
Been around forever (since 2001)
Co-op between some of their devs and TPO’s
A hybrid protocol that supports both stream communication (like Tor) and shifting data blocks around.
A large selection of [[ https://gnunet.org/transport-service | transports ]]: TCP, UDP, HTTP, HTTPS, heck even Bluetooth
I’m planning a mail for the GNUnet [[ https://gnunet.org/contact_information | list ]]. As usual add any points you care about.
DRAFT:
Hi. I am a Whonix [0] developer.
We are looking for a decentralized and censorship-resistant storage network to communicate notifications about critical situations [1] to our users and host the project metadata and files themselves to resist a Permanent Takedown Attack.[2]
GNUnet seems a perfect match for our purposes. I have some questions:
Is the GNUnet version in stable current enough to connect with the live network or is it usually obsolete because of stable’s freeze policy? (I haven’t been able to connect with it in Whonix yet) If its the latter could you please consider running your own standalone repo?
We have approx. 15K users - are you okay with us adding such a number of users to your current network?
Since we are Tor based (and we need our notifications to reach users who live behind firewalls) we will be tunneling our GNUnet communications over Tor. Has anyone experimented with this so far with the TCP transports?
What tools can be used to customize GNUnet node settings via scripting in Bash/Python?
[0] Whonix is an anonymous Debian based OS (whonix.org ) Some of you may know us from the Tor lists
[1] Apt CVE-2016-1252: During apt-get upgrading signature verification can be
[2] Dev/Permanent Takedown Attack Defender - Kicksecure
2016-12-18 13:21:25 UTC
re freenet reprepro
sudo apt-get install reprepro yelp
yelp man:reprepro
Is the GNUnet version in Debian stable (currently: jessie) current enough to connect with the GNUnet live network or is it usually obsolete because of Debian’s stable freeze policy?
^ modified that sentence a bit.
I haven’t been able to connect GNUnet over Tor in Whonix yet (user → Tor → GNUnet). Did anyone manage to run GNUnet over Tor using the TCP based transports?
^ modified that sentence a bit.
Otherwise ready to go.
Nice overview on anonymous p2p and similar (it was nice when I compared them like 4 years ago):https://www.planetpeer.de/wiki/index.php/Main_Page
2016-12-18 16:34:20 UTC
2016-12-18 17:50:27 UTC
2016-12-18 21:03:20 UTC
2016-12-19 01:06:46 UTC
My reply: Re: [GNUnet-developers] GNUnet in Whonix
I suggested that we’ll look at torservers hosting some GNUnet nodes at some point. Do you want to contact them? Work on a draft for this in this ticket?
Hm. Friendly reply, looks like not ready for prime time. Looking forward to a stable release.
+1
Dunno. Perhaps Filesharing and Torrenting ?
No that page seems more about torrenting over Tor than anything else. I’ll tack it on the Freenet intro.
2016-12-21 12:31:04 UTC
Got another reply: Re: [GNUnet-developers] GNUnet in Whonix
Turns out that Carlo tested running Tor thru a GNUnet exit with good results (yes its not a closed network). In principle we do not need dedicated GNUnet nodes for this to work but it would be helpful for their network.
Talked with Moritz and they are open to running nodes and have looked at doing so before but they need more recent versions released in packaged form.
2016-12-24 14:59:18 UTC
2016-12-27 14:08:29 UTC
2017-01-08 23:13:18 UTC
2018-02-27 01:36:24 UTC
Whonix project metadata could be distributed using Tahoe-LAFS - a redundant, encrypted storage array accessible over Tor. Instructions to users about alternative download mechanisms of the project’s code and documentation can be passed thru this channel.
*Tahoe-LAFS runs a public grid for testing. The latest introducer is listed on their IRC channel which you would point Tahoe clients to.
*Tahoe-LAFS is packaged in Debian and includes support for running over Tor cleanly.
*Whonixcheck would need to be changed to poll Tahoe shares for updates and display the emergency warning it fetches to users.
*Alternative distribution of project files includes and is not limited to: regular torrent magnet links or I2P Snark (I2P’s torrenting application)
Completing this task satisfies this ticket.
2018-02-27 17:34:07 UTC
2018-02-28 18:17:55 UTC
2018-04-29 14:39:44 UTC
The public tahoeLAFS introducer is dormant:"public testgrid" page
An alternative is to use I2P’s grid instead but only in the event that whonix news messages stop for some reason. Here’s how this can be implemented:
2 types of whonixnews messages: one normal the other, a silent “ping” type.
If the local news daemon does not receive a ping within say 30 days then it would activate I2P/tahoe and check for updates at a preset address.