Page MenuHomePhabricator

Permanent Takedown Attack Defender
Open, NormalPublic

Description

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.

Details

Impact
Needs Triage

Event Timeline

JasonJAyalaP raised the priority of this task from to Normal.
JasonJAyalaP updated the task description. (Show Details)

apt-listchanges and Whonix-News are similar?

Should I attempt to talk with Freenet devs and see if they will make the necessary changes so we can use it?

Freenet does not work directly over Tor. Do you think they would change
that?

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
tricked resulting in arbitrary package installation, system compromise. We would have liked a way to notify users to avoid running apt entirely and instead the necessary manual steps to download/verify the patched binaries.

[2] https://www.whonix.org/wiki/Dev/Permanent_Takedown_Attack_Defender

Patrick added a subscriber: Ego.
Patrick added a subscriber: entr0py.

Ready to go.

(We'd also need something else very important: freenet entering packages.debian.org, otherwise, oh well... But can be communicated later.)

Not some custom package repo. packages.debian.org

Never mind, thanks for posting!

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.

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.

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.

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:

https://bluishcoder.co.nz/2016/08/18/using-freenet-over-tor.html

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.

Updates:
https://emu.freenetproject.org/pipermail/devl/2016-December/039451.html
https://emu.freenetproject.org/pipermail/devl/2016-December/039452.html

Not happening anytime soon. Though I decided to discuss FreenetBox and see if its possible with the way Freenet works.

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 transports: TCP, UDP, HTTP, HTTPS, heck even Bluetooth

I'm planning a mail for the GNUnet 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
tricked resulting in arbitrary package installation, system compromise. We would have liked a way to notify users to avoid running apt entirely and instead the necessary manual steps to download/verify the patched binaries.

[2] https://www.whonix.org/wiki/Dev/Permanent_Takedown_Attack_Defender

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

HulaHoop (HulaHoop):

HulaHoop added a comment.

Posted:

https://lists.gnu.org/archive/html/gnunet-developers/2016-12/msg00032.html

Very good!


> Nice overview on anonymous p2p and similar

+1 Where should we add it?

Dunno. Perhaps https://www.whonix.org/wiki/File_Sharing?

Got a reply by project lead Christian Grothoff:

https://lists.gnu.org/archive/html/gnunet-developers/2016-12/msg00033.html

Hm. Friendly reply, looks like not ready for prime time. Looking forward
to a stable release.

My reply: https://lists.gnu.org/archive/html/gnunet-developers/2016-12/msg00034.html

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 https://www.whonix.org/wiki/File_Sharing?

No that page seems more about torrenting over Tor than anything else. I'll tack it on the Freenet intro.

Got another reply: https://lists.gnu.org/archive/html/gnunet-developers/2016-12/msg00035.html

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.

Ticket reply:

https://bugs.debian.org/849236#10

No he won't being doing it. Was worth a try.

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.

*Most recet info on test grid can be found from their freenode IRC channel

  • As far as configuration goes, there is no config.d and there is work to improve config file abstraction. As far as the current way to do things:

The main file is named “tahoe.cfg”, and is an “.INI”-style configuration file (parsed by the Python stdlib ConfigParser module: “[name]” section markers, lines with “key.subkey: value”, RFC822-style continuations). There are also other files containing information that does not easily fit into this format. The “tahoe create-node” or “tahoe create-client” command will create an initial tahoe.cfg file for you. After creation, the node will never modify the tahoe.cfg file: all persistent state is put in other files.

https://tahoe-lafs.readthedocs.io/en/latest/configuration.html

The public tahoeLAFS introducer is dormant:
https://tahoe-lafs.org/pipermail/tahoe-dev/2018-April/009913.html

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:

  1. 2 types of whonixnews messages: one normal the other, a silent "ping" type.
  1. 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.
Patrick updated the task description. (Show Details)