[tor-dev] onion moshing

[dawuud]

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 at 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 at lists.torproject.org
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> >
> >

> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160925/8432bf38/attachment.sig>