[tor-dev] uProxy adds Tor support

[David Fifield]

https://blog.uproxy.org/2016/09/uproxy-adds-tor-support.html

This blog post says that uProxy gained support for proxying others'
traffic through Tor.

uProxy client → censor → uProxy server → Tor → destination

In the classic uProxy deployment scenario, the client and server are
people who know each other. (I say "classic" because there are other
deployment modalities now.) They each run a browser extension. The
client encapsulates its web traffic and sends it to the server over
WebRTC. The server then issues the web requests and sends the responses
back over the WebRTC channel.

A potential problem is that the uProxy server's own web browsing gets
mixed up with that of the client. The client could, for example, get the
server in trouble by accessing sketchy web sites. That's what the Tor
integration is meant to solve.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Thesis using QUIC in Tor

[Ali Clark]

> Well done, this looks really neat! A couple of questions:

Thanks Jesse :)

> 1) Are you looking into publishing your work in a peer-reviewed journal
> such as CSS, NDSS, PoPETS, or elsewhere?

Not at the moment, however there's another research group investigating QUIC
and I've also shared my code with them.

> 2) Did you examine the performance improvements for 6-hop onion/hidden
> service circuits?

Afraid I didn't have time, but I expect performance should improve for that
case too.

> 3) Tor currently multiplexes circuits over the same TLS connection. This
> is by design to avoid leaking circuit-level metadata, including the
> observation of construction and tear-down. The first paragraph on page
> 21 seems to suggest that QUUX leaks this information. Is this correct,
> or did you take steps to address this? For that matter, does QUUX leak
> any additional metadata that could assist with de-anonymization attacks?

That paragraph only refers to the internal code buffers before send so
shouldn't be an issue. The stream frames are contained in an encrypted QUIC
packet for transfer over a QUIC connection, and it shouldn't be possible to
tell what streams/circuits are communicating just by looking at an encrypted
QUIC packet from a connection between relays.

The initial stream creation currently sends an "unusual" 32 byte hash and 4
byte circ-id on the connection. If the connection is busy this would hopefully
be resegmented with other streams' data on the connection to create a full
packet. If it's an issue the size could be rounded up to a full cell size
instead though. However, in truth I would be surprised if Tor currently resists
traffic analysis on creation of circuits, since I expect handshake cell timings
would be quite identifiable, especially over a quiet relay.

I agree for a busy relay (both in and out) analysis of a Tor relay's
established circuit traffic should be difficult, and I expect it'd be about as
difficult for QUIC, depending on its algorithm/heuristics for how it chooses to
resegment stream data onto packets send them.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Thesis using QUIC in Tor

[Jesse V]

On 09/30/2016 07:02 AM, Ali Clark wrote:
> For my master's thesis this summer I looked into the performance impact from
> using QUIC instead of TCP/TLS as the relay transport. Results from the
> experiments look quite promising.
> 
> For more details and the thesis, please see my blog post:
> https://www.benthamsgaze.org/2016/09/29/quux-a-quic-un-multiplexing-of-the-tor-relay-transport/

Hi Ali,

Well done, this looks really neat! A couple of questions:
1) Are you looking into publishing your work in a peer-reviewed journal
such as CSS, NDSS, PoPETS, or elsewhere?
2) Did you examine the performance improvements for 6-hop onion/hidden
service circuits?
3) Tor currently multiplexes circuits over the same TLS connection. This
is by design to avoid leaking circuit-level metadata, including the
observation of construction and tear-down. The first paragraph on page
21 seems to suggest that QUUX leaks this information. Is this correct,
or did you take steps to address this? For that matter, does QUUX leak
any additional metadata that could assist with de-anonymization attacks?

-- 
Jesse



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Onioncat and Prop224

[dawuud]

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  wrote:
> 
> > On Wed, Sep 28, 2016 at 11:30 AM, dawuud  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.


signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Thesis using QUIC in Tor

[Ali Clark]

Hi all,

For my master's thesis this summer I looked into the performance impact from
using QUIC instead of TCP/TLS as the relay transport. Results from the
experiments look quite promising.

For more details and the thesis, please see my blog post:
https://www.benthamsgaze.org/2016/09/29/quux-a-quic-un-multiplexing-of-the-tor-relay-transport/

I'm happy to respond to questions either here or in comments on the blog post.

Ali
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Onioncat and Prop224

[Razvan Dragomirescu]

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  wrote:

> On Wed, Sep 28, 2016 at 11:30 AM, dawuud  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
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev