I was inspired by onioncat to write a twisted python implementation. Onionvpn doesn't have as many features as onioncat. I've successfully tested that onionvpn and onioncat can talk to each other and play nice. Both onionvpn and onioncat implement a virtual public network. Anyone can send packets to you if they know your onion address or ipv6 address... however injection attacks are unlikely since the attacker cannot know the contents of your traffic without compromising the tor process managing the onion service.
I've also tested with mosh; that is, you can use mosh which only works with ipv4 over an ipv4-to-ipv6 tunnel over onionvpn/onioncat. Like this:
mosh-client -> udp/ipv4 -> ipv6 -> tun device -> tcp-to-tor -> onion service decodes ipv6 to tun device -> ipv6 -> udp/ipv4 -> mosh-server
https://github.com/david415/onionvpn
If an onionvpn/onioncat operator were to NAT the onion ipv6 traffic to the Internet then that host essentially becomes a special IPv6 exit node for the tor network. The same can be done for IPv4. Obviously operating such an exit node might be risky due to the potential for abuse... however don't you just love the idea of being about to use low-level network scanners over tor? I wonder if Open Observatory of Network Interference would be interested in this.
david
On Wed, Dec 9, 2015 at 11:59 AM, David Stainton dstainton415@gmail.com wrote:
Obviously operating such an exit node might be risky due to the potential for abuse...
Whatever.
however don't you just love the idea of being about to use low-level network scanners over tor?
Yes. Such network tools and features are extremely useful for network admins, server admins, end users, coders, etc.
I hope Bernhard is following onions v2 and will post his onioncat v2 proposal in English. You could work together and be friends and stuff.
I think mosh does support IPv6 non roaming as of latest release, so it should work for this.
I'd rather not consider IPv4. As you may be hinting, leave that up to the termination point to offer as an optional nat feature. Internal IPv4 is certainly not required to support a nice ecosystem of users and their apps entirely within onionland, lots [most] manner of apps are now either IPv6 enabled, or abandon/stubborn ware.
Hello again David,
Sorry to resurrect an year-old thread but it looks to me like OnionCat is abandoned code at this point - mailing lists are gone, no development since mid last year, etc. Since the Tor developers plan to deprecate (and quickly eliminate) v2 onion names and expect to move to the new longer names/keys ASAP, I was wondering if you had any plans to adapt your OnionVpn software.
I was thinking of a very generic lookup mechanism for IPv6 to .onion name lookup, adaptable to anything from blockchain-based name systems to a centralized file. Possibly simply running an external script given as a parameter on each IPv6 to name lookup (and checking that the returned name hashes back to the IPv6 address expected).
I think OnionVpn may be easier to modify than OnionCat, given that it's Python.
Thank you, Razvan
-- Razvan Dragomirescu Chief Technology Officer Cayenne Graphics SRL
On Wed, Dec 9, 2015 at 6:59 PM, David Stainton dstainton415@gmail.com wrote:
I was inspired by onioncat to write a twisted python implementation. Onionvpn doesn't have as many features as onioncat. I've successfully tested that onionvpn and onioncat can talk to each other and play nice. Both onionvpn and onioncat implement a virtual public network. Anyone can send packets to you if they know your onion address or ipv6 address... however injection attacks are unlikely since the attacker cannot know the contents of your traffic without compromising the tor process managing the onion service.
I've also tested with mosh; that is, you can use mosh which only works with ipv4 over an ipv4-to-ipv6 tunnel over onionvpn/onioncat. Like this:
mosh-client -> udp/ipv4 -> ipv6 -> tun device -> tcp-to-tor -> onion service decodes ipv6 to tun device -> ipv6 -> udp/ipv4 -> mosh-server
https://github.com/david415/onionvpn
If an onionvpn/onioncat operator were to NAT the onion ipv6 traffic to the Internet then that host essentially becomes a special IPv6 exit node for the tor network. The same can be done for IPv4. Obviously operating such an exit node might be risky due to the potential for abuse... however don't you just love the idea of being about to use low-level network scanners over tor? I wonder if Open Observatory of Network Interference would be interested in this.
david
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Hello,
Certainly OnionVpn could be made to work with the new prop224 onion services using some interesting properties of ed25519 to compose private subnets protected by a single ed25519 master key communicated out of band. But actually onionvpn and onioncat are an ugly hack and sending arbitrary protocols over tor doesn't really work well when for examples you have packet loss... and cascade of retransmissions occurs; that really sucks.
We need a messaging api for our datagrams not a stream transport. Although it might be possible to improve the situation with tcp/ipv6/onion/tcp by using a lossy packet queue inside the client-side tun application. I guess if you only udp/ipv6/onion/tcp (as in the onion mosh use-case) then it could work OKish if the latency isn't too high.
Anyway I'm not really interested in working on this; I've got lots of other Tor-related projects I'm working on instead.
Cheers,
David
On Sun, Sep 25, 2016 at 05:01:36PM +0300, Razvan Dragomirescu wrote:
Hello again David,
Sorry to resurrect an year-old thread but it looks to me like OnionCat is abandoned code at this point - mailing lists are gone, no development since mid last year, etc. Since the Tor developers plan to deprecate (and quickly eliminate) v2 onion names and expect to move to the new longer names/keys ASAP, I was wondering if you had any plans to adapt your OnionVpn software.
I was thinking of a very generic lookup mechanism for IPv6 to .onion name lookup, adaptable to anything from blockchain-based name systems to a centralized file. Possibly simply running an external script given as a parameter on each IPv6 to name lookup (and checking that the returned name hashes back to the IPv6 address expected).
I think OnionVpn may be easier to modify than OnionCat, given that it's Python.
Thank you, Razvan
-- Razvan Dragomirescu Chief Technology Officer Cayenne Graphics SRL
On Wed, Dec 9, 2015 at 6:59 PM, David Stainton dstainton415@gmail.com wrote:
I was inspired by onioncat to write a twisted python implementation. Onionvpn doesn't have as many features as onioncat. I've successfully tested that onionvpn and onioncat can talk to each other and play nice. Both onionvpn and onioncat implement a virtual public network. Anyone can send packets to you if they know your onion address or ipv6 address... however injection attacks are unlikely since the attacker cannot know the contents of your traffic without compromising the tor process managing the onion service.
I've also tested with mosh; that is, you can use mosh which only works with ipv4 over an ipv4-to-ipv6 tunnel over onionvpn/onioncat. Like this:
mosh-client -> udp/ipv4 -> ipv6 -> tun device -> tcp-to-tor -> onion service decodes ipv6 to tun device -> ipv6 -> udp/ipv4 -> mosh-server
https://github.com/david415/onionvpn
If an onionvpn/onioncat operator were to NAT the onion ipv6 traffic to the Internet then that host essentially becomes a special IPv6 exit node for the tor network. The same can be done for IPv4. Obviously operating such an exit node might be risky due to the potential for abuse... however don't you just love the idea of being about to use low-level network scanners over tor? I wonder if Open Observatory of Network Interference would be interested in this.
david
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-
David Stainton -
dawuud -
grarpamp -
Razvan Dragomirescu