New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tor onion integration #37

Open
david415 opened this Issue Aug 27, 2015 · 95 comments

Comments

Projects
None yet
@david415

david415 commented Aug 27, 2015

chatting with Juan Bennet at c-base, Berlin about Tor onion service integration

here's what we've identified as necessary for proper Tor integration:

  1. adding /onion to go-multiaddr - /onion/<onion-key>/ipfs/<ipfs-key>
  2. adding /onion dialing to go-multiaddr-net
  3. make a build of go-ipfs that:
  • only uses /onion
  • only bootstrap to onion nodes
  • disable mdns service
  • disable NAT service

I know plenty of people who'd be willing to run some Tor onion bootstrap nodes.

(edited by @jbenet for links)

@whyrusleeping

This comment has been minimized.

Show comment
Hide comment
@whyrusleeping

whyrusleeping Aug 27, 2015

Member

👍 this would be pretty cool!

Member

whyrusleeping commented Aug 27, 2015

👍 this would be pretty cool!

@david415

This comment has been minimized.

Show comment
Hide comment
@david415

david415 Aug 29, 2015

OK I've written the go-multiaddr Tor onion address decoding:
multiformats/go-multiaddr#13

david415 commented Aug 29, 2015

OK I've written the go-multiaddr Tor onion address decoding:
multiformats/go-multiaddr#13

@leif

This comment has been minimized.

Show comment
Hide comment
@leif

leif Aug 29, 2015

This sounds like a good plan for location-anonymous tor users to have a persistent identity and announce themselves to peers, but it doesn't cover the use case of anonymously (unlinkably?) accessing data from ipfs.

For that we'll need a mode that doesn't transmit any linkable identifiers (which includes not announcing pieces to the DHT).

leif commented Aug 29, 2015

This sounds like a good plan for location-anonymous tor users to have a persistent identity and announce themselves to peers, but it doesn't cover the use case of anonymously (unlinkably?) accessing data from ipfs.

For that we'll need a mode that doesn't transmit any linkable identifiers (which includes not announcing pieces to the DHT).

@david415

This comment has been minimized.

Show comment
Hide comment
@david415

david415 Aug 30, 2015

@leif, Good point. The only "pieces" we'll be announcing to the DHT is .onion addresses. I suspect it will be very easy for us to create a readonly client mode for non-onion using Tor users to access any IPFS storage server without announcing any identity at all.

david415 commented Aug 30, 2015

@leif, Good point. The only "pieces" we'll be announcing to the DHT is .onion addresses. I suspect it will be very easy for us to create a readonly client mode for non-onion using Tor users to access any IPFS storage server without announcing any identity at all.

@david415

This comment has been minimized.

Show comment
Hide comment
@david415

david415 Aug 30, 2015

Today I wrote a TorDialer and OnionListener; This repo also includes examples programs which can be used as an integration test with your system Tor. However it should soon have more ways to use Tor other than just the control port protocol with the system tor:

  • new ephemeral onion services via control port
  • "just launch me my own tor instance for this Dialer/Listener"

https://github.com/david415/oniondialer

Although oniondialer could be improved, we can do this later now that we have the basic interface implementations working. Therefore the next step should be to see how this Dialer and Listener can fit into go-multiaddr ... Probably oniondialer will have to change slightly to get it to fit into go-multiaddr.

david415 commented Aug 30, 2015

Today I wrote a TorDialer and OnionListener; This repo also includes examples programs which can be used as an integration test with your system Tor. However it should soon have more ways to use Tor other than just the control port protocol with the system tor:

  • new ephemeral onion services via control port
  • "just launch me my own tor instance for this Dialer/Listener"

https://github.com/david415/oniondialer

Although oniondialer could be improved, we can do this later now that we have the basic interface implementations working. Therefore the next step should be to see how this Dialer and Listener can fit into go-multiaddr ... Probably oniondialer will have to change slightly to get it to fit into go-multiaddr.

@david415

This comment has been minimized.

Show comment
Hide comment
@david415

david415 Aug 30, 2015

I've been looking closely at the source for go-multiaddr and go-multiaddr-net...
However I'm not sure if Tor onion service multiaddr string should look like this:
/onion/timaq4ygg2iegci7.onion:80
or this
/onion/fufu.onion/tcp/80

Whereas the "readonly Tor-ified" multiaddr looks like this:
/tor/example.com/tcp/80

or should the /tor/ multiaddr not encapsulate and instead look like this?
/tor/example.com:80

What do IPFS developers think of all this?

david415 commented Aug 30, 2015

I've been looking closely at the source for go-multiaddr and go-multiaddr-net...
However I'm not sure if Tor onion service multiaddr string should look like this:
/onion/timaq4ygg2iegci7.onion:80
or this
/onion/fufu.onion/tcp/80

Whereas the "readonly Tor-ified" multiaddr looks like this:
/tor/example.com/tcp/80

or should the /tor/ multiaddr not encapsulate and instead look like this?
/tor/example.com:80

What do IPFS developers think of all this?

@lgierth

This comment has been minimized.

Show comment
Hide comment
@lgierth

lgierth Aug 30, 2015

Member

from chat:

  • /onion/fufu.onion/ip4/tcp/80
  • /tor/example.com/ip6/tcp/80

Similar to /dns in multiformats/go-multiaddr#7 (comment)

A more explicit, but very bloated option for /tor: /ip4/127.0.0.1/tcp/9050/socks5/dns/example.net/ip4/tcp/80

Member

lgierth commented Aug 30, 2015

from chat:

  • /onion/fufu.onion/ip4/tcp/80
  • /tor/example.com/ip6/tcp/80

Similar to /dns in multiformats/go-multiaddr#7 (comment)

A more explicit, but very bloated option for /tor: /ip4/127.0.0.1/tcp/9050/socks5/dns/example.net/ip4/tcp/80

@whyrusleeping

This comment has been minimized.

Show comment
Hide comment
@whyrusleeping

whyrusleeping Aug 31, 2015

Member

maybe:
/onion/fufu.onion/tcp4/80
and
/tor/example.com/tcp6/80

Member

whyrusleeping commented Aug 31, 2015

maybe:
/onion/fufu.onion/tcp4/80
and
/tor/example.com/tcp6/80

@david415

This comment has been minimized.

Show comment
Hide comment
@david415

david415 Aug 31, 2015

hi. I chatted with Juan last night on #ipfs and we decided that onion multiaddrs will look like this:

  • /onion/timaq4ygg2iegci7/80

Tor doesn't transport IP or TCP... but is a realiable stream transport. We don't need DNS. Tor clients use a local SOCKS proxy; therefore the remote end does the DNS resolution. I hope I've cleared up the confusion regarding this. If not then I'm afraid this ticket will grow too big with my explainations. Perhaps find me on irc instead of commenting here with queries.

For the Tor exit node case I think it should be represented like so:

  • /tor/example.com/80

So I think this sort of breaks the multiaddr parser model... and so I made my multiaddr/net dev branches do this:

  • /onion/timaq4ygg2iegci7:80

That is the colon separates the embedded onion port number.

david415 commented Aug 31, 2015

hi. I chatted with Juan last night on #ipfs and we decided that onion multiaddrs will look like this:

  • /onion/timaq4ygg2iegci7/80

Tor doesn't transport IP or TCP... but is a realiable stream transport. We don't need DNS. Tor clients use a local SOCKS proxy; therefore the remote end does the DNS resolution. I hope I've cleared up the confusion regarding this. If not then I'm afraid this ticket will grow too big with my explainations. Perhaps find me on irc instead of commenting here with queries.

For the Tor exit node case I think it should be represented like so:

  • /tor/example.com/80

So I think this sort of breaks the multiaddr parser model... and so I made my multiaddr/net dev branches do this:

  • /onion/timaq4ygg2iegci7:80

That is the colon separates the embedded onion port number.

@whyrusleeping

This comment has been minimized.

Show comment
Hide comment
@whyrusleeping

whyrusleeping Aug 31, 2015

Member

@david415 doing /onion/timaq4ygg2iegci7:80 makes sense to me, all the parameters needed by the onion protocol are in the path element following it. Using the / is strange, as the 80 then doesnt have a label, and its not super clear what its trying to be. @jbenet thoughts?

Member

whyrusleeping commented Aug 31, 2015

@david415 doing /onion/timaq4ygg2iegci7:80 makes sense to me, all the parameters needed by the onion protocol are in the path element following it. Using the / is strange, as the 80 then doesnt have a label, and its not super clear what its trying to be. @jbenet thoughts?

@jbenet

This comment has been minimized.

Show comment
Hide comment
@jbenet

jbenet Aug 31, 2015

Member

we'll already have things like:

/ip4/1.2.3.4/tcp/80/http
/dns/foo.com/A/ip4/tcp/80/http

if we made the restriction that only one component be used, why not then:

/ip4:1.2.3.4/tcp:80/http
/dns:foo.com:A:ip4/tcp:80/http

o/ this is actually harder to impl and does not layer well on a FS approach like 9P or linux proc files, which the former one does

Member

jbenet commented Aug 31, 2015

we'll already have things like:

/ip4/1.2.3.4/tcp/80/http
/dns/foo.com/A/ip4/tcp/80/http

if we made the restriction that only one component be used, why not then:

/ip4:1.2.3.4/tcp:80/http
/dns:foo.com:A:ip4/tcp:80/http

o/ this is actually harder to impl and does not layer well on a FS approach like 9P or linux proc files, which the former one does

@whyrusleeping

This comment has been minimized.

Show comment
Hide comment
@whyrusleeping

whyrusleeping Aug 31, 2015

Member

thats not quite what I was getting at, i'm not saying that we require only one component. I'm saying that we combine the onion address and port into one as they both are given meaning by the /onion path element.

Member

whyrusleeping commented Aug 31, 2015

thats not quite what I was getting at, i'm not saying that we require only one component. I'm saying that we combine the onion address and port into one as they both are given meaning by the /onion path element.

@david415

This comment has been minimized.

Show comment
Hide comment
@david415

david415 Sep 5, 2015

Any suggestions for changes to go-multiaddr-net?
Do you not want Tor/Onion related stuff in DialArgs since it is not a thin-waist protocol?
See here:
https://github.com/jbenet/go-multiaddr-net/blob/master/convert.go#L142-L144

david415 commented Sep 5, 2015

Any suggestions for changes to go-multiaddr-net?
Do you not want Tor/Onion related stuff in DialArgs since it is not a thin-waist protocol?
See here:
https://github.com/jbenet/go-multiaddr-net/blob/master/convert.go#L142-L144

@jbenet

This comment has been minimized.

Show comment
Hide comment
@jbenet

jbenet Sep 6, 2015

Member

@david415 right, DialArgs is for net.Dial mostly.

What we should do is:

  • make an onion Dialer + Listener
  • make the main Dialer + Listener extensible (so users can "add" protocols they want to allow. key is user adds it because users may not want to allow any dialing, only certain protocols. in this case, regular net dialing should also be done this way as some users would not want to allow arbitrary TCP/UDP dialing...)

(i unfort dont have time to work directly on this until after Sep 15. but can CR)

Member

jbenet commented Sep 6, 2015

@david415 right, DialArgs is for net.Dial mostly.

What we should do is:

  • make an onion Dialer + Listener
  • make the main Dialer + Listener extensible (so users can "add" protocols they want to allow. key is user adds it because users may not want to allow any dialing, only certain protocols. in this case, regular net dialing should also be done this way as some users would not want to allow arbitrary TCP/UDP dialing...)

(i unfort dont have time to work directly on this until after Sep 15. but can CR)

@david415

This comment has been minimized.

Show comment
Hide comment
@david415

david415 Sep 18, 2015

  • yes... we have a basic tor dialer + onion listener that we can improve more later
    https://github.com/david415/oniondialer
  • go-multiaddr-net needs a "pluggable transport system"...
    and i think we can make iterative progress here wherein the first phase for Tor support you can:
  1. remove all transport plugins
  2. load the tor plugin
  3. do stuff with tor + ipfs!!!

However... later it would be nice to have more granular policy for operating heterogeneous ipfs nodes/gateways/proxies.

david415 commented Sep 18, 2015

  • yes... we have a basic tor dialer + onion listener that we can improve more later
    https://github.com/david415/oniondialer
  • go-multiaddr-net needs a "pluggable transport system"...
    and i think we can make iterative progress here wherein the first phase for Tor support you can:
  1. remove all transport plugins
  2. load the tor plugin
  3. do stuff with tor + ipfs!!!

However... later it would be nice to have more granular policy for operating heterogeneous ipfs nodes/gateways/proxies.

@david415

This comment has been minimized.

Show comment
Hide comment
@david415

david415 Sep 26, 2015

I'm looking at go-multiaddr-net and go-ipfs to see how things work... and it makes sense for thin-waist protocols... but this type of thing isn't going to work for the OnionListener use case:
https://github.com/ipfs/go-ipfs/blob/master/core/corehttp/corehttp.go#L50-L55

The onion multiaddr isn't enough information to create an onion listener. We need to know the tor process control port in order to create the onion service... then after we auto-create the onion service key material the control port tells us the onion address as well.

Perhaps in this case we need an onion + multiaddr helper function to create a new onion service and it's respective multiaddr? But how to plug it into the normal usage of go-multiaddr-net where the API user expects a multiaddr Listener to be created by only feeding it the multiaddr?

david415 commented Sep 26, 2015

I'm looking at go-multiaddr-net and go-ipfs to see how things work... and it makes sense for thin-waist protocols... but this type of thing isn't going to work for the OnionListener use case:
https://github.com/ipfs/go-ipfs/blob/master/core/corehttp/corehttp.go#L50-L55

The onion multiaddr isn't enough information to create an onion listener. We need to know the tor process control port in order to create the onion service... then after we auto-create the onion service key material the control port tells us the onion address as well.

Perhaps in this case we need an onion + multiaddr helper function to create a new onion service and it's respective multiaddr? But how to plug it into the normal usage of go-multiaddr-net where the API user expects a multiaddr Listener to be created by only feeding it the multiaddr?

@jbenet

This comment has been minimized.

Show comment
Hide comment
@jbenet

jbenet Sep 27, 2015

Member

@david415 maybe the listen onion multiaddr could be different, could include more information, like the proxy:

/ip4/127.0.0.1/tcp/<control-port>/onion/<onion-address>

but it still should be advertised to others as:

/onion/<onion-address>

Perhaps in this case we need an onion + multiaddr helper function to create a new onion service and it's respective multiaddr?

yeah that's definitely doable. harder to make things plug in nicely. the other option is to create a "listener-maker" and mount that onto multiaddr, like:

c := maonion.NewController(NewMultiaddr("/ip4/127.0.0.1/tcp/<control-port>"))
c.NewListener(NewMultiaddr("/onion/<onion-addr>"))

// mount onto a multiaddr-net 
manet.Listen("/onion/<onion-addr>") // doesn't work
manet.AddProtocol("onion", c)
manet.Listen("/onion/<onion-addr>") // now works
// 

but this is kind of "magical" in a way i dont like (i.e. static), probably makes much more sense to rework how multiaddr-net works into something like this:

n := manet.NewNetwork()
n.Add(manet.IP4)
n.Add(manet.IP6)
n.Add(manet.TCP)
n.Add(manet.UDP)
n.Add(onion.Onion)

l, err := n.Listener("/ip4/1.2.3.4/tcp/1234")
c, err := n.Dial("/onion/<onionaddr>") 

// with shortcuts like:
n := manet.NewThinWaistNetwork()
n.Add(onion.Onion)

"network" is a bit odd name, but does give the idea that these networks are stacked and makes more sense why mulriaddrs work the way they do. "transport" is another possible name, but may not capture the full meaning of "network".

Member

jbenet commented Sep 27, 2015

@david415 maybe the listen onion multiaddr could be different, could include more information, like the proxy:

/ip4/127.0.0.1/tcp/<control-port>/onion/<onion-address>

but it still should be advertised to others as:

/onion/<onion-address>

Perhaps in this case we need an onion + multiaddr helper function to create a new onion service and it's respective multiaddr?

yeah that's definitely doable. harder to make things plug in nicely. the other option is to create a "listener-maker" and mount that onto multiaddr, like:

c := maonion.NewController(NewMultiaddr("/ip4/127.0.0.1/tcp/<control-port>"))
c.NewListener(NewMultiaddr("/onion/<onion-addr>"))

// mount onto a multiaddr-net 
manet.Listen("/onion/<onion-addr>") // doesn't work
manet.AddProtocol("onion", c)
manet.Listen("/onion/<onion-addr>") // now works
// 

but this is kind of "magical" in a way i dont like (i.e. static), probably makes much more sense to rework how multiaddr-net works into something like this:

n := manet.NewNetwork()
n.Add(manet.IP4)
n.Add(manet.IP6)
n.Add(manet.TCP)
n.Add(manet.UDP)
n.Add(onion.Onion)

l, err := n.Listener("/ip4/1.2.3.4/tcp/1234")
c, err := n.Dial("/onion/<onionaddr>") 

// with shortcuts like:
n := manet.NewThinWaistNetwork()
n.Add(onion.Onion)

"network" is a bit odd name, but does give the idea that these networks are stacked and makes more sense why mulriaddrs work the way they do. "transport" is another possible name, but may not capture the full meaning of "network".

@jbenet jbenet referenced this issue Sep 27, 2015

Closed

Pluggable design #7

@jbenet

This comment has been minimized.

Show comment
Hide comment
@jbenet

jbenet Sep 27, 2015

Member

Sorry, let's move multiaddr pluggable-ness discussion to multiformats/go-multiaddr-net#7

Member

jbenet commented Sep 27, 2015

Sorry, let's move multiaddr pluggable-ness discussion to multiformats/go-multiaddr-net#7

@jbenet

This comment has been minimized.

Show comment
Hide comment
@jbenet

jbenet Dec 14, 2015

Member

hey @david415 -- @whyrusleeping has made transport changes to go-ipfs libp2p and to https://github.com/jbenet/go-multiaddr-net/ -- chances are we can resume the tor work!

Member

jbenet commented Dec 14, 2015

hey @david415 -- @whyrusleeping has made transport changes to go-ipfs libp2p and to https://github.com/jbenet/go-multiaddr-net/ -- chances are we can resume the tor work!

@david415

This comment has been minimized.

Show comment
Hide comment
@david415

david415 Jan 2, 2016

cool! i'll take a look.

david415 commented Jan 2, 2016

cool! i'll take a look.

@jbenet

This comment has been minimized.

Show comment
Hide comment
@jbenet

jbenet Jan 13, 2016

Member

I can put some effort toward this in feb too.
On Sat, Jan 2, 2016 at 08:27 David Stainton notifications@github.com
wrote:

cool! i'll take a look.


Reply to this email directly or view it on GitHub
#37 (comment).

Member

jbenet commented Jan 13, 2016

I can put some effort toward this in feb too.
On Sat, Jan 2, 2016 at 08:27 David Stainton notifications@github.com
wrote:

cool! i'll take a look.


Reply to this email directly or view it on GitHub
#37 (comment).

@kumavis

This comment has been minimized.

Show comment
Hide comment
@kumavis

kumavis Feb 17, 2016

does running an ipfs server as a tor hidden service work by default?
I guess there are quite a few dimensions to the intersection of tor and ipfs, and its difficult to tell what works out of the box and what needs development

kumavis commented Feb 17, 2016

does running an ipfs server as a tor hidden service work by default?
I guess there are quite a few dimensions to the intersection of tor and ipfs, and its difficult to tell what works out of the box and what needs development

@david415

This comment has been minimized.

Show comment
Hide comment
@david415

david415 Feb 21, 2016

No. IPFS does not "work by default" as a Tor onion service.

It is not difficult to tell the state of the IPFS + Tor integration because it is utterly non-existent; That's why we have this ticket!

david415 commented Feb 21, 2016

No. IPFS does not "work by default" as a Tor onion service.

It is not difficult to tell the state of the IPFS + Tor integration because it is utterly non-existent; That's why we have this ticket!

@cryptix

This comment has been minimized.

Show comment
Hide comment
@cryptix

cryptix Feb 21, 2016

@david415 👍

To reiterate what @leif posted: It might work for dialing an IPFS node from a censored location but you better have a custom ipfs build that doesn't scream your identity to everybody in it's vicinity. I hope we can see different flavors of ipfs nodes before 1.0. A privacy preserving client is much needed otherwise every content you share and spread becomes a tracking cookie. I personally already have that barbed-wire in my head stopping me from using it to share music with my family and that's only a 1st world problem.

cryptix commented Feb 21, 2016

@david415 👍

To reiterate what @leif posted: It might work for dialing an IPFS node from a censored location but you better have a custom ipfs build that doesn't scream your identity to everybody in it's vicinity. I hope we can see different flavors of ipfs nodes before 1.0. A privacy preserving client is much needed otherwise every content you share and spread becomes a tracking cookie. I personally already have that barbed-wire in my head stopping me from using it to share music with my family and that's only a 1st world problem.

@kumavis

This comment has been minimized.

Show comment
Hide comment
@kumavis

kumavis Feb 22, 2016

@david415 @cryptix thanks -- I look forward to seeing this ticket progress. If I get some time I will try to pick up some tasks

kumavis commented Feb 22, 2016

@david415 @cryptix thanks -- I look forward to seeing this ticket progress. If I get some time I will try to pick up some tasks

@seanlynch

This comment has been minimized.

Show comment
Hide comment
@seanlynch

seanlynch Apr 21, 2016

I just posted a $100 bounty expiring in six months. Also paid to get it tweeted from @bountysource to hopefully get it some more attention. If there are blocker issues, let me know and maybe I can post bounties for those as well. https://www.bountysource.com/issues/26255361-tor-onion-integration

seanlynch commented Apr 21, 2016

I just posted a $100 bounty expiring in six months. Also paid to get it tweeted from @bountysource to hopefully get it some more attention. If there are blocker issues, let me know and maybe I can post bounties for those as well. https://www.bountysource.com/issues/26255361-tor-onion-integration

@leycec

This comment has been minimized.

Show comment
Hide comment
@leycec

leycec Jun 12, 2017

As expected from an open issue spanning several years, the thread of discussion has become fairly impenetrable to the lay outsider – namely, me.

Would one or more IPFS developers be willing to supply a high-level status update on both this and I2P integration? My gut intuition is that development on both has stalled out, for arcane reasons I'll probably never understand. (I'd love to be demonstrated wrong on that.)

I note that david415's ipfs-onion-transport purports to implement Tor integration support as an external gx package. Naturally, development on that appears to have stalled out as well. It also fails to provide even the thinnest veneer of usage or installation documentation. Naturally.

I'll be blunt. IPFS without anonymity is functionally useless for me.

I doubt I'm the only one. Thanks to the overtly DMCA-friendly jurisdiction in which I live, merely running a deanonymized IPFS node would unacceptably increase my risk profile. Default denylists would do little to nothing (...probably nothing) to ameliorate this risk and obviate the entire motivation for using IPFS in the first place. After all, pseudo-decentralized, censorship-resistant, fully anonymized file sharing protocols already exist (e.g., I2P-enabled BitTorrent).

IPFS was supposed to be something more – not less.

leycec commented Jun 12, 2017

As expected from an open issue spanning several years, the thread of discussion has become fairly impenetrable to the lay outsider – namely, me.

Would one or more IPFS developers be willing to supply a high-level status update on both this and I2P integration? My gut intuition is that development on both has stalled out, for arcane reasons I'll probably never understand. (I'd love to be demonstrated wrong on that.)

I note that david415's ipfs-onion-transport purports to implement Tor integration support as an external gx package. Naturally, development on that appears to have stalled out as well. It also fails to provide even the thinnest veneer of usage or installation documentation. Naturally.

I'll be blunt. IPFS without anonymity is functionally useless for me.

I doubt I'm the only one. Thanks to the overtly DMCA-friendly jurisdiction in which I live, merely running a deanonymized IPFS node would unacceptably increase my risk profile. Default denylists would do little to nothing (...probably nothing) to ameliorate this risk and obviate the entire motivation for using IPFS in the first place. After all, pseudo-decentralized, censorship-resistant, fully anonymized file sharing protocols already exist (e.g., I2P-enabled BitTorrent).

IPFS was supposed to be something more – not less.

@cpacia

This comment has been minimized.

Show comment
Hide comment
@cpacia

cpacia commented Jun 12, 2017

I've had it working for a while now https://github.com/OpenBazaar/go-onion-transport

@leycec

This comment has been minimized.

Show comment
Hide comment
@leycec

leycec Jun 12, 2017

But... there's no documentation. On the other hand, go-onion-transport is at least well-maintained. On the gripping hand, lgierth of ipfs/infrastructure fame admits that:

Not gonna run an /onion bootstrapper until go-onion-transport has been audited.

So, we're back to square one.

My running assumption is that, like ZeroNet's official Tor integration, go-onion-transport requires (A) a system-wide installation of Tor (as opposed to the Tor instance bundled with Tor Browser), (B) the Tor control port to be enabled, and (C) the cookie authentication file for access to that port to be enabled. I suppose I should probably forward this query to go-onion-transport's issue tracker. </sigh>

Regardless, the larger issue remains: anonymity is a first-class issue. The difference between a cryptographically secure anonymity stack and an unofficial, undocumented, ad-hoc third-party plugin is citizens locked in cages at gunpoint. This is not hyperbole. Anonymity is not a trivial consumer preference to be idly left to unofficial, unverified, unaudited vendors with possibly dubious motives.

ZeroNet provides out-of-the-box support for Tor-based encapsulation with additional support for I2P on the way. So should IPFS.

In the long twilight of the 21st century, anonymity is no longer an option. It's a necessity.

leycec commented Jun 12, 2017

But... there's no documentation. On the other hand, go-onion-transport is at least well-maintained. On the gripping hand, lgierth of ipfs/infrastructure fame admits that:

Not gonna run an /onion bootstrapper until go-onion-transport has been audited.

So, we're back to square one.

My running assumption is that, like ZeroNet's official Tor integration, go-onion-transport requires (A) a system-wide installation of Tor (as opposed to the Tor instance bundled with Tor Browser), (B) the Tor control port to be enabled, and (C) the cookie authentication file for access to that port to be enabled. I suppose I should probably forward this query to go-onion-transport's issue tracker. </sigh>

Regardless, the larger issue remains: anonymity is a first-class issue. The difference between a cryptographically secure anonymity stack and an unofficial, undocumented, ad-hoc third-party plugin is citizens locked in cages at gunpoint. This is not hyperbole. Anonymity is not a trivial consumer preference to be idly left to unofficial, unverified, unaudited vendors with possibly dubious motives.

ZeroNet provides out-of-the-box support for Tor-based encapsulation with additional support for I2P on the way. So should IPFS.

In the long twilight of the 21st century, anonymity is no longer an option. It's a necessity.

@flyingzumwalt

This comment has been minimized.

Show comment
Hide comment
@flyingzumwalt

flyingzumwalt Jun 12, 2017

Thank you to @david415 @cpacia and all of the other contributors who have been directing their time, creativity and determination towards this feature. Making IPFS and the whole decentralized web support Reader and Writer privacy certainly is one of the many first-class issues we have to tackle. There will be terrible consequences for some users if we don't achieve Reader and Writer privacy soon.

Building IPFS is a huge open source community effort involving hundreds of contributors who are building technology that will impact millions of people. The core IPFS maintainers are constantly forced to choose between many equally relevant features. It often falls to individual contributors (or their employers) to prioritize the features that they need most urgently.

I'm confident that these features will get the attention they need in the coming months because IPFS continues to gain traction worldwide and we keep making it easier for people anywhere to run IPFS nodes. This forces the issue of Reader & Writer privacy.

flyingzumwalt commented Jun 12, 2017

Thank you to @david415 @cpacia and all of the other contributors who have been directing their time, creativity and determination towards this feature. Making IPFS and the whole decentralized web support Reader and Writer privacy certainly is one of the many first-class issues we have to tackle. There will be terrible consequences for some users if we don't achieve Reader and Writer privacy soon.

Building IPFS is a huge open source community effort involving hundreds of contributors who are building technology that will impact millions of people. The core IPFS maintainers are constantly forced to choose between many equally relevant features. It often falls to individual contributors (or their employers) to prioritize the features that they need most urgently.

I'm confident that these features will get the attention they need in the coming months because IPFS continues to gain traction worldwide and we keep making it easier for people anywhere to run IPFS nodes. This forces the issue of Reader & Writer privacy.

@cpacia

This comment has been minimized.

Show comment
Hide comment
@cpacia

cpacia Jun 12, 2017

My running assumption is that, like ZeroNet's official Tor integration, go-onion-transport requires (A) a system-wide installation of Tor (as opposed to the Tor instance bundled with Tor Browser),

Either or. Browser bundle works fine.

(B) the Tor control port to be enabled, and

Yes

(C) the cookie authentication file for access to that port to be enabled.

I believe at this time only pw based authentication is supported.

cpacia commented Jun 12, 2017

My running assumption is that, like ZeroNet's official Tor integration, go-onion-transport requires (A) a system-wide installation of Tor (as opposed to the Tor instance bundled with Tor Browser),

Either or. Browser bundle works fine.

(B) the Tor control port to be enabled, and

Yes

(C) the cookie authentication file for access to that port to be enabled.

I believe at this time only pw based authentication is supported.

@ig0rsky

This comment has been minimized.

Show comment
Hide comment
@ig0rsky

ig0rsky Aug 12, 2017

Any updates on this?

ig0rsky commented Aug 12, 2017

Any updates on this?

@flyingzumwalt

This comment has been minimized.

Show comment
Hide comment
@flyingzumwalt

flyingzumwalt Aug 12, 2017

The onion transport for IPFS still has not been audited yet. Until it has been audited you should consider it experimental and should not assume that it guarantees anonymity. When we audit it, we will announce the results. In the meantime, people are welcome to conduct their own audits, or arrange for third parties to conduct audits. That would not be wasted effort; It's good to have multiple entities audit systems like this.

flyingzumwalt commented Aug 12, 2017

The onion transport for IPFS still has not been audited yet. Until it has been audited you should consider it experimental and should not assume that it guarantees anonymity. When we audit it, we will announce the results. In the meantime, people are welcome to conduct their own audits, or arrange for third parties to conduct audits. That would not be wasted effort; It's good to have multiple entities audit systems like this.

@david415

This comment has been minimized.

Show comment
Hide comment
@david415

david415 commented Aug 13, 2017

ugh.

@seanlynch

This comment has been minimized.

Show comment
Hide comment
@seanlynch

seanlynch Aug 14, 2017

Anyone have suggestions for professional code auditors and/or know the general price range for such a thing?

seanlynch commented Aug 14, 2017

Anyone have suggestions for professional code auditors and/or know the general price range for such a thing?

@ian-gtv

This comment has been minimized.

Show comment
Hide comment
@ian-gtv

ian-gtv Aug 14, 2017

Personally I would use Cure53 and I would guess of the order of 10,000 pounds depending on the scope, could easily go up to 40,000.

ian-gtv commented Aug 14, 2017

Personally I would use Cure53 and I would guess of the order of 10,000 pounds depending on the scope, could easily go up to 40,000.

@seanlynch

This comment has been minimized.

Show comment
Hide comment
@seanlynch

seanlynch Aug 14, 2017

seanlynch commented Aug 14, 2017

@Kelketek

This comment has been minimized.

Show comment
Hide comment
@Kelketek

Kelketek Aug 14, 2017

@seanlynch It might be possible to use crowdfunding. I'd chip in a bit. Could notify a few mailing lists and subreddits or what have you.

Kelketek commented Aug 14, 2017

@seanlynch It might be possible to use crowdfunding. I'd chip in a bit. Could notify a few mailing lists and subreddits or what have you.

@seanlynch

This comment has been minimized.

Show comment
Hide comment
@seanlynch

seanlynch Aug 14, 2017

seanlynch commented Aug 14, 2017

@ianopolous

This comment has been minimized.

Show comment
Hide comment
@ianopolous

ianopolous Aug 14, 2017

Member

The first thing to do would be to contact cure53 and ask for a quote:
https://cure53.de/#services-analysis
You can also look into funding sources like the Open Technology Fund.

Member

ianopolous commented Aug 14, 2017

The first thing to do would be to contact cure53 and ask for a quote:
https://cure53.de/#services-analysis
You can also look into funding sources like the Open Technology Fund.

@jbenet

This comment has been minimized.

Show comment
Hide comment
@jbenet

jbenet Aug 14, 2017

Member

Protocol Labs is now capable of funding independent audits of the whole IPFS stack. We have started some work and RFPs on this and we can accelerate it to cover this part first. This shouldn't hold back any other groups wanting to audit. we can take care of at least one of the bills. I think our ETA was in the next few months (IPFS is big), but we can see what's needed.

cc @diasdavid.

Member

jbenet commented Aug 14, 2017

Protocol Labs is now capable of funding independent audits of the whole IPFS stack. We have started some work and RFPs on this and we can accelerate it to cover this part first. This shouldn't hold back any other groups wanting to audit. we can take care of at least one of the bills. I think our ETA was in the next few months (IPFS is big), but we can see what's needed.

cc @diasdavid.

@braderhart

This comment has been minimized.

Show comment
Hide comment
@braderhart

braderhart commented Oct 20, 2017

@notzoom

This comment has been minimized.

Show comment
Hide comment
@notzoom

notzoom Dec 20, 2017

So what's up with this ? How do we run it over TOR ?

notzoom commented Dec 20, 2017

So what's up with this ? How do we run it over TOR ?

@Stebalien

This comment has been minimized.

Show comment
Hide comment
@Stebalien

Stebalien Dec 21, 2017

We want to get all of IPFS and libp2p audited before we start encouraging people to use it with TOR. Unfortunately, this will take a while.

Stebalien commented Dec 21, 2017

We want to get all of IPFS and libp2p audited before we start encouraging people to use it with TOR. Unfortunately, this will take a while.

@llgoer

This comment has been minimized.

Show comment
Hide comment
@llgoer

llgoer Mar 30, 2018

Has there been any recent progress?

llgoer commented Mar 30, 2018

Has there been any recent progress?

@Stebalien

This comment has been minimized.

Show comment
Hide comment
@Stebalien

Stebalien Mar 30, 2018

@llgoer we've been pushing through a large refactor of how transports work that'll make this simpler. We've also made some progress internally towards auditing the IPFS stack. However, you shouldn't expect a blessed and fully functional/recommended tor transport for a while.

Stebalien commented Mar 30, 2018

@llgoer we've been pushing through a large refactor of how transports work that'll make this simpler. We've also made some progress internally towards auditing the IPFS stack. However, you shouldn't expect a blessed and fully functional/recommended tor transport for a while.

@cretz

This comment has been minimized.

Show comment
Hide comment
@cretz

cretz May 23, 2018

An issue on https://github.com/OpenBazaar/go-onion-transport just reminded me to update this issue...I wrote https://github.com/cretz/bine which may make it easier to use go-ipfs over Tor. Granted a simple SOCKS5 proxy is enough to reach the public web out of an exit node, but if you want to start ephemeral onion services or statically link Tor, give that project a look.

cretz commented May 23, 2018

An issue on https://github.com/OpenBazaar/go-onion-transport just reminded me to update this issue...I wrote https://github.com/cretz/bine which may make it easier to use go-ipfs over Tor. Granted a simple SOCKS5 proxy is enough to reach the public web out of an exit node, but if you want to start ephemeral onion services or statically link Tor, give that project a look.

@andyli

This comment has been minimized.

Show comment
Hide comment
@andyli

andyli May 24, 2018

For the record, Tor 0.3.3.6 was released earlier this week:

There is now a documented stable API for programs that need to embed Tor. See tor_api.h for full documentation and known bugs.

andyli commented May 24, 2018

For the record, Tor 0.3.3.6 was released earlier this week:

There is now a documented stable API for programs that need to embed Tor. See tor_api.h for full documentation and known bugs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment