Re: Freenet in Whonix

On 2016-12-17 19:01, Arne Babenhauserheide wrote:
> [email protected] writes:
> 
>> On 2016-12-16 22:06, Arne Babenhauserheide wrote:
>>> [email protected] writes:
>>> 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:
>>> http://127.0.0.1:8888/freenet:USK@ED3bT6ngiUE1RayB9N~aQz6iIrc4Gwj-ubnaw22s~aY,kN3gtmcb9pHa2FKrVPw1U5209WvB7vvuQ7oC42gt6ic,AQACAAE/wats-dieh/17/freenet-over-tor.html
>>> 
> …
>> I do not doubt Freenet's anonymity capabilities.
> …
>> 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?
> 
> The issue is not only performance. It is implementation. Switching from
> UDP to TCP would require restructuring of the whole transport layer. It
> is on the longterm roadmap, but as long as no one new takes it up, it
> will take time.
> 
> So not routing over Tor is not about advantage or strategy.
> 
> However if you just need to reach the users, you could simply establish
> Tor hidden services which provide the content from Freenet over
> Tor. This then uses Freenet as distributed storage and provides several
> views on the site — only one of which needs to be available to get the
> information.
> 
> Here in an example of this:
> 
> http://127.0.0.1:8888/USK@1ORdIvjL2H1bZblJcP8hu2LjjKtVB-rVzp8mLty~5N4,8hL85otZBbq0geDsSKkBK4sKESL2SrNVecFZz9NxGVQ,AQACAAE/bluishcoder/37/2015/09/14/using-freenet-for-static-websites.html
> 
> These sites can be run by any Whonix user who has access to both 
> Freenet
> and Tor. Then those who only have access to Tor due to needing hidden
> bridges and pluggable transports can check the different hidden
> services to get the data.
> 
> Whonix users who can run Freenet will then get the full cryptographic
> guarantees that the site was uploaded from someone with the private 
> key,
> while Whonix users who can only run Tor will need to rely on the
> integrity of the hidden services (depending on the protocol you
> establish, corruption of one of the services will simply cause fallback
> to another one).

I see. Thanks for your thoughts.

> 
> What I forgot to ask: Do you have information about Users for whom the
> Freenet friend-to-friend mode is blocked? This is similar to hidden
> bridges, and the Freenet protocol is not trivial to detect.

I don't have literature I can refer to in Freenet's specific case but 
unless Freenet is capable of morphing its protocol to resemble other 
whitelisted ones it would be trivial to fingerprint and block with Deep 
Packet Inspection (feel free to correct me). Also I'm speaking about 
connections in pure F2F mode because an adversary can easily build an IP 
blacklist by trawling Opennet.

> 
>>> Also you can modify the configuration from pyFreenet but I did not 
>>> test
>>> that in a long time:
>>> https://github.com/ArneBab/lib-pyFreenet-staging/blob/py3/fcp3/node.py#L1132
>>> See also: https://wiki.freenetproject.org/FCPv2/ModifyConfig
>> 
>> Good to know. Thanks.
>> 
>>> You can have a look at my work with auto-spawning of Freenet nodes in
>>> fcpupload and babcom. See
>>> http://www.draketo.de/light/english/freenet/pyfreenet-041-autospawn
> …
>>> fcpupload --spawn --fcpPort 9486 testfile
>>> 
>>> ^ spawn a node, uploads testfile into Freenet. Provides the key to 
>>> the
>>>   file when the upload finishes and tears down the node again.
> …
>>> 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:
>> 
>> Does that happen when updating Freenet?
> 
> Updates of Freenet are downloaded directly over Freenet, so they never
> touch the clearnet.
> 
> Therefore the requirement to use a proxy only exists for spawning a 
> node
> on a computer which does not have Freenet yet.
> 
> The current way to install Freenet and keep it up to date is to install
> it once, start it at boot or login and then let it update itself
> automatically.

ACK

> 
>>>> * Before including pyFreenet we would need it to be signed by its
>>>> respective dev so we can validate it before running anything of
>>>> course.
>>> 
>>> I’m the current maintainer. Do you need gpg signed git revisions or
>>> tags, signed release tarballs or signed Mercurial commits?
>>> 
>> 
>> Ideally we need a signed deb
> …
>>> 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.
> 
> I understand not wanting to rely on pip. I would not expect you to: The
> instructions are just for those who want to skip manual steps.
> 
> Providing Freenet itself as a signed deb is on the roadmap, but not yet
> done. The main problem in the past was that some of our requirements
> were unavailable in Debian.

What I meant a standalone .deb we can drop in our repo since I know that 
putting a package into Debian is unrealistic with your rapid dev cycle.

> 
>> Debian reprepo tool works nicely for packaging and really helpful
>> upstream that can be contacted by mail.
>> 
>> https://mirrorer.alioth.debian.org/
> 
> I just checked this, but the howto and manual were unavailable.
> 
> Did they move to a new place?

Hm. Not sure whats happened. I can see the How-To and the manual though 
the latter is sprinkled with HTML tags.

> 
> Best wishes,
> Arne
> _______________________________________________
> Devl mailing list
> [email protected]
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
_______________________________________________
Devl mailing list
[email protected]
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl