Re: [tor-dev] Onioncat and Prop224
On 27/04/16 22:31, grarpamp wrote:
On 4/25/16, Tim Wilson-Brown - teor <teor2345@gmail.com> wrote:
On 22 Apr 2016, at 17:03, grarpamp <grarpamp@gmail.com> wrote:
FYI: The onioncat folks are interested in collaborating with tor folks regarding prop224.
https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.tx...
I'm interested in what kind of collaboration onioncat would like to do on prop224, next-generation hidden services. It would be great to work this out in the next few weeks, as we're coding parts of the proposal right now.
Yep :) And I know Bernhard was hoping to get in touch with Roger on this before long.
Basically, prop224 HS being wider than 80 bits will break onioncat's current HS onion <---> IPv6 addressing mechanism.
They're looking at various backward compatibility options, as well as possibly making side use of the HSDir DHT, or even integrating more directly with the tor client.
Just FYI, I recently migrated all of I2P's spec proposals to the website, and came across a seven-year-old proposal that Bernhard wrote about improving I2P support in GarliCat: https://geti2p.net/spec/proposals/105-garlicat-name-translation I don't know how well it has aged, but given that Tor is now facing the same issues that I2P has, perhaps it can be of some use if resurrected from the dead :)
But the tor-onions mailing list is to discuss the technical details running onion services.
Readers of tor-onions / newbies may have been unfamiliar with onioncat. It's a way to get non-TCP between TorHS onions, thus in the thread "Hidden datagram service".
I think there are a nontrivial number of users interested in, and using, non-strictly-TCP transport over an IPv6 tunnel interface. For example, look at users of CJDNS...
For which we should try to continue a way, in v2, to do that over anonymous overlay network Tor / I2P.
There is already some work on doing this in I2P: https://github.com/majestrate/i2p-tools/tree/master/i2tun https://github.com/majestrate/i2p-tools/tree/master/pyi2tun I2P also natively supports non-TCP protocols if that helps (only datagrams implemented thus far). str4d
On 4/30/16, str4d <str4d@i2pmail.org> wrote:
On 27/04/16 22:31, grarpamp wrote:
Yep :) And I know Bernhard was hoping to get in touch with Roger on this before long.
Basically, prop224 HS being wider than 80 bits will break onioncat's current HS onion <---> IPv6 addressing mechanism.
They're looking at various backward compatibility options, as well as possibly making side use of the HSDir DHT, or even integrating more directly with the tor client.
Just FYI, I recently migrated all of I2P's spec proposals to the website, and came across a seven-year-old proposal that Bernhard wrote about improving I2P support in GarliCat:
https://geti2p.net/spec/proposals/105-garlicat-name-translation
I don't know how well it has aged, but given that Tor is now facing the same issues that I2P has, perhaps it can be of some use if resurrected from the dead :)
Thanks str4d, I think I remember that one. There''s certainly a difference between underlying cryptographic addressing, and human "DNS style" naming. Onion addresses, even at 16 char or 80 bit, were always beyond most human scope. I'm not too concerned about human addressing since that can always be a layer in userland (though not as strong as something tracing back to the underlying crypto), of course if it comes along with any side layer deemed necessary for getting the crypto addressing working between nodes under IPv6, that's a good bonus.
But the tor-onions mailing list is to discuss the technical details running onion services.
Fyi, I'm still waiting to hear back on the status of the onioncat list.
onioncat. It's a way to get non-TCP between TorHS onions, thus in the thread "Hidden datagram service".
I think there are a nontrivial number of users interested in, and using, non-strictly-TCP transport over an IPv6 tunnel interface. For example, look at users of CJDNS...
For which we should try to continue a way, in v2, to do that over anonymous overlay network Tor / I2P.
There is already some work on doing this in I2P:
https://github.com/majestrate/i2p-tools/tree/master/i2tun https://github.com/majestrate/i2p-tools/tree/master/pyi2tun
I2P also natively supports non-TCP protocols if that helps (only datagrams implemented thus far).
You mean just UDP? How would you move ICMP, GRE, raw IP/packets? Do you have to implement each one? That seems more work than implementing a generic data conduit, or an IPv6 conduit (as a more specific, host stack oriented, interoperable form). Though yes UDP would be the most useful for people after TCP.
Freenet has talk on their lists of adding 100 new onioncat nodes to tor and i2p as linked to in this thread... https://lists.torproject.org/pipermail/tor-dev/2016-June/011108.html Is anyone working on resurrecting the onioncat mailing list and archives?
Hi Jeremy. In regard your post 'Tor and Namecoin' here... https://lists.torproject.org/pipermail/tor-dev/2016-July/011245.html In this thread prefixed 'Onioncat and Prop224' started and spanning from here through now... https://lists.torproject.org/pipermail/tor-dev/2016-April/010847.html Onioncat is interested in finding way to extend IPv6 addressing past prop224 for use by IPv6 native user applications. There are some purely internal ideas for that. Yet to extent an internal tor+onioncat solution may be difficult, onioncat may need to develop or shell out to a non-native mapping and lookup layer. Namecoin has been mentioned among prebuilt potential solutions. Note clearly namecoin usage here *not* for human DNS style naming such as myeasyname.onion. But as a mapping between crypto key of onion (descriptor, hsdir, etc) and character string of (in format of) IPv6 address for use in IP / tunnel addressing. And most certainly any external layer must be capable of having nodes binding natively in the Tor / I2P / etc networks, and preferably being strictly private entirely within them (like how private Tor / I2P / Bitcoin nets can be deployed by generating new authorities, keys, genesis, etc). Outproxy is not an option. It's also not ideal to be expending resources on mining whereas other form of simpler distributed registry network may suffice onioncat purpose. Anyhow, fyi as to this thread and any ideas / collab :)
grarpamp:
Hi Jeremy.
Hey grarpamp, Sorry for the delayed reply.
In regard your post 'Tor and Namecoin' here... https://lists.torproject.org/pipermail/tor-dev/2016-July/011245.html
In this thread prefixed 'Onioncat and Prop224' started and spanning from here through now... https://lists.torproject.org/pipermail/tor-dev/2016-April/010847.html
Thanks for the pointer. For some reason I wasn't aware of that thread, even though those messages did hit my inbox. Probably because in April 2016 I was busy finishing semester projects and wasn't spending much time reading email.
Onioncat is interested in finding way to extend IPv6 addressing past prop224 for use by IPv6 native user applications.
There are some purely internal ideas for that. Yet to extent an internal tor+onioncat solution may be difficult, onioncat may need to develop or shell out to a non-native mapping and lookup layer. Namecoin has been mentioned among prebuilt potential solutions.
Hmm, this is indeed an interesting use case.
Note clearly namecoin usage here *not* for human DNS style naming such as myeasyname.onion. But as a mapping between crypto key of onion (descriptor, hsdir, etc) and character string of (in format of) IPv6 address for use in IP / tunnel addressing.
Okay, so I've been pondering this for a little while. There are going to be some challenges in doing this properly, but I *think* that most or all of the challenges are solvable with some effort. Full disclosure: I will need to check with the other Namecoin devs to see if I might have missed anything, so I might need to issue corrections to these comments if I did miss anything important. Most of the challenges of dealing with this use case are going to be because Namecoin simultaneously aims to satisfy 2 goals: 1. Enforce that names are unique and only updatable by the owner. 2. Enforce that names are scarce, nonfungible, and resistant to squatting. Both of these goals are relevant for a DNS-like system that maps human-meaningful names to values. The first goal is relevant to Onioncat-like systems, but the second goal seems to be inapplicable, because (I presume) most end users don't care what IPv6 address Onioncat assigns them, and if a particular IPv6 address happens to be unavailable for registration, picking a different one isn't going to annoy anyone. (If, for some reason, there are Onioncat use cases that make this statement incorrect, please let me know.) Some of the challenges that are posed by the existence of goal 2 include: Creating a new IPv6 address would cost some money, conceptually similar to registering a domain name. This might incentivise unsafe user behavior such as reusing identities. There have been similar concerns raised in the past about other use cases of Namecoin (including some features of domain names) where name scarcity unintentionally incentivises insecure user behavior, so I'm guessing that we're open to the possibility of adjusting the system to solve this. Creating a new IPv6 address is subject to a 12-block (around 2 hours) waiting period (a salted commitment to the name is placed in the blockchain, and 2 hours later the name and salt are revealed), so that a newly created name cannot be sniped by someone relaying the transaction or during a small chain reorganization. I'm guessing that some Onioncat users may not want to have to wait 2 hours for their new IPv6 address to start working. This also might incentivise reuse of identities (see previous challenge). Okay, so here is a suggestion on how this might be fixable. Let's say that we create a new class of names in Namecoin. This might be a different set of name opcodes that have modified semantics. In this email I'll refer to this new class of names as MR (machine-readable) names, and the existing names as HR (human-readable) names. MR names have the following new properties: 1. MR names are not subject to name registration fees. (A fee is paid to the miner just as would be done for a currency transaction.) 2. MR name registrations are not subject to a 12-block waiting period. 3. MR name registrations must be signed by a public key whose hash is equal to the name being registered. 4. MR names are considered to be in a separate set from HR names for the purpose of name uniqueness checks, i.e. registering a domain name as an MR name is valid even if the domain name already exists, but software that looks up the domain name will receive the HR name unless it requests the MR name. I think MR names would solve both of the challenges I listed, without compromising goal 1. Sniping is prevented because a sniper would need to possess a private key whose public key hash is the name being sniped. In the case of Onioncat, the public key would be the .onion public key. Unfortunately, this construction introduces a new issue: there are a lot of public key systems and hash functions, and different applications will want different choices. If this is used to prevent sniping, then it would have to be part of blockchain validation, which makes supporting arbitrary pubkey systems and hash functions impossible. So, we can instead modify this construction a bit, as follows: 5. MR name uniqueness is not part of transaction/block validation. 6. The signatures used in property 3 are not used for transaction/block validation. 7. When an MR name is looked up, the Namecoin client returns all of the matching unspent transactions (meaning that since MR names are not unique, there may be multiple unspent transactions that match the name). 8. MR name lookups also return the signatures used in property 3, for each matching transaction. 9. MR name lookups also return the registration block height of each matching transaction. 10. The application layer that requests a name lookup (e.g. Onioncat) is responsible for choosing the earliest-registered name whose signature used in property 3 is valid according to whatever signature validation rules the application layer uses. The only attack I see here is that it's possible to spam invalid signatures into the blockchain and make everyone else carry them around. Transaction fees and block size limits should (I think) prevent this from being a problem, just as with Bitcoin. This kind of modification would, I think, be a softfork. It would be a fairly significant undertaking, but I think it would be useful for a lot of other use cases besides Onioncat. Again, I haven't discussed this outline with the other Namecoin devs, so maybe there are problems that I'm not seeing.
And most certainly any external layer must be capable of having nodes binding natively in the Tor / I2P / etc networks, and preferably being strictly private entirely within them (like how private Tor / I2P / Bitcoin nets can be deployed by generating new authorities, keys, genesis, etc). Outproxy is not an option.
Bitcoin and Namecoin nodes can be exposed as Tor hidden services (I believe there's even code in there now for automatically configuring such a hidden service via the Tor control port). I don't think there's any built-in support for I2P (unless something was added since I last looked), but if I2P can expose a local TCP service as an I2P service, and if I2P allows such TCP services to be connected to by exposing a SOCKS interface, I'm guessing that it should mostly work (famous last words). The only thing that would break that way is peer exchange: Bitcoin and Namecoin nodes normally share peer addresses, and although this works just fine with Tor hidden services, I don't think it would work out of the box with I2P (unless someone's added that since I last looked). Although it is possible to deploy private Bitcoin and Namecoin networks (I did it at a workshop I gave at DWS so that I could mine blocks on demand), usually people do this for testing or demonstration purposes, not for real-world applications. The reason is that blockchains' security assumptions include the assumption that they have a reasonably high hashrate from a reasonably diverse set of miners. An Onioncat-specific Namecoin network would probably have a very low hashrate compared to the main Namecoin network, which means that it would be much easier to perform a 51% attack. Merged mining could, hypothetically, raise the hashrate, except that to do merged mining, the miners would have to be connected to the public Bitcoin network. In addition, it's usually very unprofitable to mine Bitcoin or Namecoin over Tor or I2P, because the additional latency causes much higher orphan rates. (Most Bitcoin and Namecoin miners spend considerable effort obtaining low-latency connections for relaying blocks to and from other miners.) Might I ask what the motivation is for having a completely separate Namecoin network inside Tor/I2P, that can't be satisfied by binding participants' nodes to Tor/I2P hidden services while allowing some users who don't want or need anonymity to relay transactions and blocks between clearnet and Tor/I2P?
It's also not ideal to be expending resources on mining whereas other form of simpler distributed registry network may suffice onioncat purpose.
Might I ask what alternatives to mining would suit Onioncat's needs? I admit that I'm not incredibly familiar with Onioncat's needs and threat model, so if there's something simpler that works well, I'm unaware of what it would be.
Anyhow, fyi as to this thread and any ideas / collab :)
Yes, thank you for bringing this up. Feel free to give feedback on the above, suggest alternative methods, etc. I'm not certain whether Namecoin is the best solution for Onioncat's needs (and it sounds like no one is certain at this point), but I'm happy to do what I can to flesh out the ideas so that we can figure out if it's the right solution, and if so, exactly what that solution would look like. Cheers, -Jeremy PS: I'm not subscribed to the other lists; if you are subscribed to them and think they'd like to see this reply, feel free to forward it to them.
https://www.reddit.com/r/TOR/comments/54rpil/dht_syncthing_bitsync_over_tor/ Hi we would like to integrate DHT Bittorrent Syncing over Tor for our open source encrypted obfuscated media rich notepad app. This app will have for main objective to provide a secure information gathering and sharing tool for NGO's involved in recording human rights abuses in less than friendly countries and for the general public to be able to be shielded from the evermore privacy negative environment we live in... We are looking for developers to join us and criticism from the community. (Another fine non-strictly-TCP[v4] application potentially enabled by OnionCat. Though they may not be aware of its applicability yet.)
OK I'm replying inline;
https://www.reddit.com/r/TOR/comments/54rpil/dht_syncthing_bitsync_over_tor/
Hi we would like to integrate DHT Bittorrent Syncing over Tor for our open source encrypted obfuscated media rich notepad app.
Why Bittorrent? It's fun to think about using various composable components to build interesting applications and distributed systems but sometime composing certain components together results in non-optimal systemic properties.
This app will have for main objective to provide a secure information
Do you mean four main objectives? What are they?
gathering and sharing tool for NGO's involved in recording human
Gathering and sharing; are you sure these are two different properties or just one? Might there be other things that have this property besides bittorrent?
rights abuses in less than friendly countries and for the general public to be able to be shielded from the evermore privacy negative environment we live in...
We are looking for developers to join us and criticism from the community.
Are you aware of Tahoe-LAFS? We are almost done with the native Tor integration for Tahoe; however this latest release will also include support for IPv6 and I2p. Do you require revocation? What's your threat model?
(Another fine non-strictly-TCP[v4] application potentially enabled by OnionCat. Though they may not be aware of its applicability yet.)
Yes but then you are suggesting TCP on top of TCP via TCP/IPv6/onion/TCP. Do you know what happens when you get packet loss with that protocol layer cake? Cascading retransmissions. Non-optimal, meaning shitty. You might be able to partially solve this by using a lossy queueing Tun device/application but that just makes me cringe. cheers, David
On Wed, Sep 28, 2016 at 11:30 AM, dawuud <dawuud@riseup.net> wrote:
Are you aware of Tahoe-LAFS?
Don't know if they are, or if they are here, all we have is their short post. If they just need an insert and retrieve filestore for small user bases, there are lots of choices. If they need the more global and random on demand distribution properties, and even mutually co-interested long term storage nature of bittorrent, that's harder. Today people can use onioncat to escape IPv4 address space limitations, provide UDP transport, provide configuration free on demand any node to any node IP network semantics for use by existing applications. Mass bittorrent / bitcoin / p2p apps over a private network such as HS / eep happen to typically need and match that.
Yes but then you are suggesting TCP on top of TCP via TCP/IPv6/onion/TCP.
Onioncat is only one extra encapsulation layer. Of course if you run tcp app over onioncat instead of udp app, you have to think about that too. But being the top layer, onioncat itself does not have losses, ie any losses come up from below.... clearnet --> tor --> ocat --> user.
Do you know what happens when you get packet loss with that protocol layer cake? Cascading retransmissions. Non-optimal, meaning shitty.
For certain applications, expecially bulk background transport, it's actually quite useable in practice. And people do use voice / video / irc / ssh over hidden / eep services... of course there are non-optimal systemic issues there. People will use what they can [tolerate].
You might be able to partially solve this by using a lossy queueing Tun device/application but that just makes me cringe.
That's pretty far beyond anywhere tor network design is going anytime soon. Buffering for reordering datagrams into a queue, maybe partially if the user doesn't mind possible additional latency. Lossy... not in tcp layers. Maybe in ideal world user would supply requirements as ifconfig request to network, each interface providing different set, user binds apps to interfaces as needed. Sliders latency / bandwidth / loss - maybe represented as single app type config param: voice, irc, bulk, torrent, network tolerant - or by list of app names. Or network would monitor and adapt to users traffic.
Allow me to second that - for some applications (Internet of Things being the one I'm working on), the volume of data exchanged is very small, so there isn't much chance for packets to be lost or retransmitted. OnionCat + Tor simplify development immensely by giving each node a fixed IPv6 address, even behind NAT. You no longer have to _design_ the service for IoT, you just run it on the node and it's immediately accessible over IPv6. It's not perfect in terms of network protocol encapsulation but it's "good enough". https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good :) Razvan On Thu, Sep 29, 2016 at 2:23 AM, grarpamp <grarpamp@gmail.com> wrote:
On Wed, Sep 28, 2016 at 11:30 AM, dawuud <dawuud@riseup.net> wrote:
Are you aware of Tahoe-LAFS?
Don't know if they are, or if they are here, all we have is their short post.
If they just need an insert and retrieve filestore for small user bases, there are lots of choices. If they need the more global and random on demand distribution properties, and even mutually co-interested long term storage nature of bittorrent, that's harder.
Today people can use onioncat to escape IPv4 address space limitations, provide UDP transport, provide configuration free on demand any node to any node IP network semantics for use by existing applications. Mass bittorrent / bitcoin / p2p apps over a private network such as HS / eep happen to typically need and match that.
Yes but then you are suggesting TCP on top of TCP via TCP/IPv6/onion/TCP.
Onioncat is only one extra encapsulation layer. Of course if you run tcp app over onioncat instead of udp app, you have to think about that too. But being the top layer, onioncat itself does not have losses, ie any losses come up from below.... clearnet --> tor --> ocat --> user.
Do you know what happens when you get packet loss with that protocol layer cake? Cascading retransmissions. Non-optimal, meaning shitty.
For certain applications, expecially bulk background transport, it's actually quite useable in practice. And people do use voice / video / irc / ssh over hidden / eep services... of course there are non-optimal systemic issues there. People will use what they can [tolerate].
You might be able to partially solve this by using a lossy queueing Tun device/application but that just makes me cringe.
That's pretty far beyond anywhere tor network design is going anytime soon.
Buffering for reordering datagrams into a queue, maybe partially if the user doesn't mind possible additional latency. Lossy... not in tcp layers.
Maybe in ideal world user would supply requirements as ifconfig request to network, each interface providing different set, user binds apps to interfaces as needed. Sliders latency / bandwidth / loss - maybe represented as single app type config param: voice, irc, bulk, torrent, network tolerant - or by list of app names. Or network would monitor and adapt to users traffic. _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Greetings, again. No it's not good enough if TCP is being layered on top of TCP. Otherwise... then yes it should be good enough. I've previously used it with mosh which uses UDP. Changing the subject a bit, isn't The Internet of Things going to lead to a situation where there are even more NSA, GCHQ, BND remotely controlled computers with microphones and other sensors all around us? Never trust a HAL-9000! Never, ever ever. You linked to a wikipedia article and I read it; I would suggest being careful in declaring enemies. Certainly the cypherpunks movement has enemies who are malicious and those who are incompetent. In this discussion we are very very far away from "good enough". https://en.wikipedia.org/wiki/Principle_of_least_privilege Transparently routing ALL traffic from a computer over tor sounds like a terrible idea! This will undoubtedly result in sending things over Tor that you don't really want to send. Furthermore there are language security considerations. Tor is obviously written in C for historical reasons however if today you were to write onioncat, Tor or other security related software in C or C++ it would be considered socially irresponsible. Onioncat is abandoned. You are suggesting people use an abandoned C vpn/proxy. Terrabad! To be clear... I'm glad Onioncat exists because it's a cool experiment. I even implemented a twisted python onionvpn which is compatible with onioncat: https://github.com/david415/onionvpn no Gods no masters no SPOFs no admins no bedtimes David On Fri, Sep 30, 2016 at 01:55:13PM +0300, Razvan Dragomirescu wrote:
Allow me to second that - for some applications (Internet of Things being the one I'm working on), the volume of data exchanged is very small, so there isn't much chance for packets to be lost or retransmitted. OnionCat + Tor simplify development immensely by giving each node a fixed IPv6 address, even behind NAT. You no longer have to _design_ the service for IoT, you just run it on the node and it's immediately accessible over IPv6. It's not perfect in terms of network protocol encapsulation but it's "good enough". https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good :)
Razvan
On Thu, Sep 29, 2016 at 2:23 AM, grarpamp <grarpamp@gmail.com> wrote:
On Wed, Sep 28, 2016 at 11:30 AM, dawuud <dawuud@riseup.net> wrote:
Are you aware of Tahoe-LAFS?
Don't know if they are, or if they are here, all we have is their short post.
If they just need an insert and retrieve filestore for small user bases, there are lots of choices. If they need the more global and random on demand distribution properties, and even mutually co-interested long term storage nature of bittorrent, that's harder.
Today people can use onioncat to escape IPv4 address space limitations, provide UDP transport, provide configuration free on demand any node to any node IP network semantics for use by existing applications. Mass bittorrent / bitcoin / p2p apps over a private network such as HS / eep happen to typically need and match that.
Yes but then you are suggesting TCP on top of TCP via TCP/IPv6/onion/TCP.
Onioncat is only one extra encapsulation layer. Of course if you run tcp app over onioncat instead of udp app, you have to think about that too. But being the top layer, onioncat itself does not have losses, ie any losses come up from below.... clearnet --> tor --> ocat --> user.
Do you know what happens when you get packet loss with that protocol layer cake? Cascading retransmissions. Non-optimal, meaning shitty.
For certain applications, expecially bulk background transport, it's actually quite useable in practice. And people do use voice / video / irc / ssh over hidden / eep services... of course there are non-optimal systemic issues there. People will use what they can [tolerate].
You might be able to partially solve this by using a lossy queueing Tun device/application but that just makes me cringe.
That's pretty far beyond anywhere tor network design is going anytime soon.
Buffering for reordering datagrams into a queue, maybe partially if the user doesn't mind possible additional latency. Lossy... not in tcp layers.
Maybe in ideal world user would supply requirements as ifconfig request to network, each interface providing different set, user binds apps to interfaces as needed. Sliders latency / bandwidth / loss - maybe represented as single app type config param: voice, irc, bulk, torrent, network tolerant - or by list of app names. Or network would monitor and adapt to users traffic.
Changing the subject a bit, isn't The Internet of Things going to lead to a situation where there are even more NSA, GCHQ, BND remotely controlled computers with microphones and other sensors all around us
Not if IoT dev's start encrypting things. On a side note, hidden services are a great model for IoT devices; a la TorChat.
Transparently routing ALL traffic from a computer over tor sounds like a terrible idea! * This will undoubtedly result in sending things over Tor that you don't really want to send.*
From a latency / bandwidth perspective? Or paranoia?
Op 04-10-16 om 16:59 schreef Tim Kuijsten:
Op 03-10-16 om 19:43 schreef Evan d'Entremont:
Not if IoT dev's start encrypting things.
How would encryption help against exploited IoT devices?
sorry, i meant to ask how would encryption help against *exploiting* IoT devices.
Changing the subject a bit, isn't The Internet of Things going to lead to a situation where there are even more NSA, GCHQ, BND remotely controlled computers with microphones and other sensors all around us
They didn't say anything about exploits. I just have several gateways on my desk and none of them use any kind of encryption, from the device to backend, or from the backend to user. On Tue, Oct 4, 2016 at 12:07 PM Tim Kuijsten <info@netsend.nl> wrote:
Op 04-10-16 om 16:59 schreef Tim Kuijsten:
Op 03-10-16 om 19:43 schreef Evan d'Entremont:
Not if IoT dev's start encrypting things.
How would encryption help against exploited IoT devices?
sorry, i meant to ask how would encryption help against *exploiting* IoT devices. _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
to be more clear, those devices can currently be surveilled passively. If they were encrypted they couldn't be. On Wed, Oct 5, 2016 at 2:31 PM Evan d'Entremont <evan@evandentremont.com> wrote:
Changing the subject a bit, isn't The Internet of Things going to lead to a situation where there are even more NSA, GCHQ, BND remotely controlled computers with microphones and other sensors all around us
They didn't say anything about exploits.
I just have several gateways on my desk and none of them use any kind of encryption, from the device to backend, or from the backend to user.
On Tue, Oct 4, 2016 at 12:07 PM Tim Kuijsten <info@netsend.nl> wrote:
Op 04-10-16 om 16:59 schreef Tim Kuijsten:
Op 03-10-16 om 19:43 schreef Evan d'Entremont:
Not if IoT dev's start encrypting things.
How would encryption help against exploited IoT devices?
sorry, i meant to ask how would encryption help against *exploiting* IoT devices. _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Op 05-10-16 om 19:36 schreef Evan d'Entremont:
to be more clear, those devices can currently be surveilled passively. If they were encrypted they couldn't be.
ic, valid point. I was thinking more of the recent rise in exploited IoT devices[1] and the sad state of IoT security in general. [1] https://krebsonsecurity.com/2016/09/the-democratization-of-censorship/
Many wrote, in subthread started by dawuud 5 days ago:
talk: internet of things, security / exploit / nsa, crypto via tor, everything over tor, exits
This subthread does not concern the subject made for curating / supporting / tracking / developing "Onioncat and Prop224" [1]. Please a) end it, or b) move it elsewhere and/or post a new subject thread. [1] Reasonably including OnionVPN and any other equivalent IPv6 p2p onion tunnel(4) adapters as layered on, or integrated natively with, hidden services. And possibly tie-ins of this with other overlay networks, ie: garlicat.
On Thu, Jun 23, 2016 at 3:51 PM, grarpamp <grarpamp@gmail.com> wrote:
Freenet has talk on their lists of adding 100 new onioncat nodes to tor and i2p as linked to in this thread...
https://lists.torproject.org/pipermail/tor-dev/2016-June/011108.html
More folks blogging related to the above... http://mh7mkfvezts5j6yu.onion/2016/08/18/using-freenet-over-tor.html This post outlines a method of using Freenet over Tor based on posts I wrote on my Freenet hosted blog and subsequent discussions about it. If you read my Freenet hosted blog there's little new here, I'm just making it available on my non-freenet blog. One issue I've had with Freenet is that it exposes your IP address to peers. Recent law enforcement efforts to monitor Freenet have shown that they have been able to obtain search warrants based on logging requests for blocks of known data and associating them with IP addresses. If law enforcement can do this, so can random bad people. You can avoid exposing your IP address to random strangers on opennet by using darknet but even then you have to trust your friends aren't monitoring your requests. If it was possible to run Freenet over Tor hidden services then only the hidden service address would be exposed using this logging method. A problem is that Freenet uses UDP which Tor does not support. https://emu.freenetproject.org/pipermail/devl/2016-June/039056.html A recent post on the Freenet development mailing list pointed out that onioncat provides a virtual network over Tor and tunnels UDP. Using the steps they provided, and some tweaks, it's possible to set up a darknet node that doesn't expose its IP address. It uses the onioncat generated IPv6 address for communicating with peers - and this address is backed by a Tor hidden service. The steps below outline how to set this up. ... details inside ... https://lists.cpunks.org/pipermail/cypherpunks/2016-October/032674.html I've been taking a somewhat different approach. I'm also using OnionCat, but I focused first on anonymously reaching peers via the open Internet. I have a node that hits the Internet through an "anonymous" VPS proxy. The node reaches the proxy via IPv6 OpenVPN via OnionCat. The node binds locally only to tun1, and in the proxy, tun1 forwards to eth0.
On 2016-05-01 01:44, str4d wrote:
On 27/04/16 22:31, grarpamp wrote:
On 4/25/16, Tim Wilson-Brown - teor <teor2345@gmail.com> wrote:
On 22 Apr 2016, at 17:03, grarpamp <grarpamp@gmail.com> wrote:
FYI: The onioncat folks are interested in collaborating with tor folks regarding prop224.
https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.tx...
I'm interested in what kind of collaboration onioncat would like to do on prop224, next-generation hidden services. It would be great to work this out in the next few weeks, as we're coding parts of the proposal right now.
Yep :) And I know Bernhard was hoping to get in touch with Roger on this before long.
Basically, prop224 HS being wider than 80 bits will break onioncat's current HS onion <---> IPv6 addressing mechanism.
They're looking at various backward compatibility options, as well as possibly making side use of the HSDir DHT, or even integrating more directly with the tor client.
Just FYI, I recently migrated all of I2P's spec proposals to the website, and came across a seven-year-old proposal that Bernhard wrote about improving I2P support in GarliCat:
https://geti2p.net/spec/proposals/105-garlicat-name-translation
I don't know how well it has aged, but given that Tor is now facing the same issues that I2P has, perhaps it can be of some use if resurrected from the dead :)
This proposal simply suggest to a DNS reverse lookup within the I2P network based on a specific TLD. This kind of mechanism would work for Tor as well. In my opinion, the best solution would be to directly use the HS directory to do those lookups. Bernhard
str4d <str4d@i2pmail.org> writes:
[ text/plain ] On 27/04/16 22:31, grarpamp wrote:
On 4/25/16, Tim Wilson-Brown - teor <teor2345@gmail.com> wrote:
On 22 Apr 2016, at 17:03, grarpamp <grarpamp@gmail.com> wrote:
FYI: The onioncat folks are interested in collaborating with tor folks regarding prop224.
https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.tx...
I'm interested in what kind of collaboration onioncat would like to do on prop224, next-generation hidden services. It would be great to work this out in the next few weeks, as we're coding parts of the proposal right now.
Yep :) And I know Bernhard was hoping to get in touch with Roger on this before long.
Basically, prop224 HS being wider than 80 bits will break onioncat's current HS onion <---> IPv6 addressing mechanism.
They're looking at various backward compatibility options, as well as possibly making side use of the HSDir DHT, or even integrating more directly with the tor client.
Just FYI, I recently migrated all of I2P's spec proposals to the website, and came across a seven-year-old proposal that Bernhard wrote about improving I2P support in GarliCat:
https://geti2p.net/spec/proposals/105-garlicat-name-translation
I don't know how well it has aged, but given that Tor is now facing the same issues that I2P has, perhaps it can be of some use if resurrected from the dead :)
Hello, disclaimer: I've never used onioncat and I'm not even sure what are the use cases for it. I just read the docs on its webpage in an attempt to understand the system and maybe contribute to this thread. I probably don't understand the system sufficiently yet. Starting with a question wrt the "Scalable Solution" for I2P, I did not exactly understand how the DNS approach would work for garlicat. Would GC do the DNS request? Or the application? And to which DNS server? Some GC-specific DNS server? The solution seems plausible, but it requires the extra DNS protocol round trip. BTW, if the application-layer protocol supports DNS, can't we just fake the DNS protocol part and resolve the DNS query inside onioncat? So, Alice is in onioncat as "aliceonioncathiddenservice.onion" and she passes her onion to Bob who wants to torrent with her through onioncat. Alice gives "aliceonioncathiddenservice.onion" to her friend Bbo, and Bob tries to connect to it through his application (e.g. a torrent client). Bob's application will probably do a DNS query for the onion address, which onioncat can intercept (?). At that point, onioncat can register the onion address as the destination, and pass back a fake IPv6 address to the torrent client. From that point and on, the torrent client will use the fake IPv6 address, and onioncat will reroute the connection through the onion circuit to "aliceonioncathiddenservice.onion". I'm not sure if the above idea will work, but even if it does, it's worse than the current onioncat, since it requires the application-layer protocol to support DNS.
On 2016-05-26 13:37, George Kadianakis wrote:
str4d <str4d@i2pmail.org> writes:
[ text/plain ] On 27/04/16 22:31, grarpamp wrote:
On 4/25/16, Tim Wilson-Brown - teor <teor2345@gmail.com> wrote:
On 22 Apr 2016, at 17:03, grarpamp <grarpamp@gmail.com> wrote:
FYI: The onioncat folks are interested in collaborating with tor folks regarding prop224.
https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.tx...
I'm interested in what kind of collaboration onioncat would like to do on prop224, next-generation hidden services. It would be great to work this out in the next few weeks, as we're coding parts of the proposal right now.
Yep :) And I know Bernhard was hoping to get in touch with Roger on this before long.
Basically, prop224 HS being wider than 80 bits will break onioncat's current HS onion <---> IPv6 addressing mechanism.
They're looking at various backward compatibility options, as well as possibly making side use of the HSDir DHT, or even integrating more directly with the tor client.
Just FYI, I recently migrated all of I2P's spec proposals to the website, and came across a seven-year-old proposal that Bernhard wrote about improving I2P support in GarliCat:
https://geti2p.net/spec/proposals/105-garlicat-name-translation
I don't know how well it has aged, but given that Tor is now facing the same issues that I2P has, perhaps it can be of some use if resurrected from the dead :)
Hello,
disclaimer: I've never used onioncat and I'm not even sure what are the use cases for it. I just read the docs on its webpage in an attempt to understand the system and maybe contribute to this thread. I probably don't understand the system sufficiently yet.
Hi! In the following there is a fundamental explanation of OC and the problems with prop224. OnionCat simply does 2 things: 1) It is a VPN adapter based on the Tor (or I2P) network (on its hidden services). There is no central VPN server, instead OnionCat connects peer-to-peer to the other participants. Because it is based on layer 3 (as most other VPNs) all packets (not just TCP) may be routed through it. OnionCat uses IPv6 as L3 protocol. 2) OnionCat generates an end point IP address which is based on the hidden service ID (e.g. iuddxo47v5mhoqyz.onion <-> fd87:d87e:eb43:4506:3bbb:9faf:5877:4319). This has 3 major advantages: a) every end point automatically gets a unique IP thus the user does not have to care about it and b) they are cryptographically tied together, thus one cannot simply spoof an address, c) there is almost no configuration necessary because OC can "automatically find" its way through Tor because of its ability to translate between hidden service ID and IP address.
Starting with a question wrt the "Scalable Solution" for I2P, I did not exactly understand how the DNS approach would work for garlicat. Would GC do the DNS request? Or the application? And to which DNS server? Some GC-specific DNS server? The solution seems plausible, but it requires the extra DNS protocol round trip.
BTW, if the application-layer protocol supports DNS, can't we just fake the DNS protocol part and resolve the DNS query inside onioncat? So, Alice is in onioncat as "aliceonioncathiddenservice.onion" and she passes her onion to Bob who wants to torrent with her through onioncat. Alice gives "aliceonioncathiddenservice.onion" to her friend Bbo, and Bob tries to connect to it through his application (e.g. a torrent client). Bob's application will probably do a DNS query for the onion address, which onioncat can intercept (?). At that point, onioncat can register the onion address as the destination, and pass back a fake IPv6 address to the torrent client. From that point and on, the torrent client will use the fake IPv6 address, and onioncat will reroute the connection through the onion circuit to "aliceonioncathiddenservice.onion".
I'm not sure if the above idea will work, but even if it does, it's worse than the current onioncat, since it requires the application-layer protocol to support DNS.
For Alice and Bob to communicate together they need to know the IPv6 address of each other (as in any other IP-based network). What happens technically within OnionCat? 1) OnionCat receives an IPv6 packet, decodes the header and retrieves the destination IPv6. 2) OC converts the IPv6 address to an .onion-id 3) OC request a circuit from the Tor client with this destination .onion-id 4) Tor connects 5) OC forwards the IP packets through the circuit. 6) At the other end packets "drop out" of the Tor circuit into OC which in turn forwards the packets to the local kernel. Whats the problem know with Prop224? For OC to work properly it needs to be able to convert .onion-ids to IPv6 addresses back and forth. This works well with the current 80-bit hashes but it does not work with hashes greater than 80bits. So what's the solution? The solution is to use some kind of database to do lookups, i.e. find the proper .onion-id given a specific IPv6 address. Actually, it doesn't matter what kind of database this is but it should obviously NOT break anonymity. Because of that Internet DNS may be problematic although it would be very easy to implement. IMO a better place would be the HS directory :) Bernhard
participants (9)
-
Bernhard R. Fischer -
dawuud -
Evan d'Entremont -
George Kadianakis -
grarpamp -
Jeremy Rand -
Razvan Dragomirescu -
str4d -
Tim Kuijsten