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
