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@xxxxxxxxx> > 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@xxxxxxxxxxxxxxxxxxxx > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > > > > _______________________________________________ > tor-dev mailing list > tor-dev@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev