[tor-talk] Tor VoIP PBX Architecture Discussion

[Conrad Rockenhaus]

Hello All,

So prior to opening up the service for beta, Iain suggested that we have a
discussion regarding my proposed service and my planned architecture to see
if there’s any room for improvements in the design or any vulnerabilities
that can take away someone’s anonymity.

So the design is pretty simple, I have an Asterisk box, and in front of
that Asterisk box I have a FreeBSD box that is running Tor, SSHD, and
OpenVPN. SSHD and OpenVPN are exposed as hidden services via Tor. The Tor
user connects to Asterisk via a passwordless OpenVPN or SSH tunnel to route
UDP traffic to Asterisk.

Asterisk is connected to Internet to allow interconnection with VoIP
providers, termination with with users that don’t care about anonymity, as
well as interconnection with other XMPP servers.

SMS is enabled, it requires an email address. If you don’t have a reliable
Tor accessible email address, we’re working on a solution.

Any comments/suggestions would be greatly appreciated!

Conrad
--
Conrad Rockenhaus
https://www.rockenhaus.com
------
Get started with GreyPony Anonymization Today!
https://www.greyponyit.com

[Conrad Rockenhaus]

Hello All,

We had a discussion on IRC regarding this and the following suggestions were made:

1) Change the architecture to FreeBSD box<—> Tor <—> OnionCat <—> Asterisk, or even drop the FreeBSD box completely if the Asterisk box is able to handle the load.

2) Traumschule is looking into creating a wiki page or opening a ticket for this project.

3) Every alternate solution we looked at didn’t have the advantages that this solution had, which is the ability to provide PSTN access and interconnections to public Internet XMPP servers.

4) Results of a test were conducted and one second round trip latency was noticed from PSTN to a soft phone connected via Tor (via OpenVPN). Hopefully performance improvement will be noticed with OnionCat.

If there’s any questions, comments, or suggestions, or if there’s anyone that’s willing to volunteer their time in helping out with this project please let us know. It would be greatly appreciated.

Thanks,

Conrad

Post by Conrad Rockenhaus
Hello All,
So prior to opening up the service for beta, Iain suggested that we have a discussion regarding my proposed service and my planned architecture to see if there’s any room for improvements in the design or any vulnerabilities that can take away someone’s anonymity.
So the design is pretty simple, I have an Asterisk box, and in front of that Asterisk box I have a FreeBSD box that is running Tor, SSHD, and OpenVPN. SSHD and OpenVPN are exposed as hidden services via Tor. The Tor user connects to Asterisk via a passwordless OpenVPN or SSH tunnel to route UDP traffic to Asterisk.
Asterisk is connected to Internet to allow interconnection with VoIP providers, termination with with users that don’t care about anonymity, as well as interconnection with other XMPP servers.
SMS is enabled, it requires an email address. If you don’t have a reliable Tor accessible email address, we’re working on a solution.
Any comments/suggestions would be greatly appreciated!
Conrad
--
Conrad Rockenhaus
https://www.rockenhaus.com
------
Get started with GreyPony Anonymization Today!
https://www.greyponyit.com

[grarpamp]

architecture to Tor <—> OnionCat <—> Asterisk
test ... one second round trip latency ... PSTN to a soft phone connected via Tor (via OpenVPN).
Hopefully performance improvement will be noticed with OnionCat.

OnionCat can provide access to using UDP and IPv6
over Tor without the extra openssh openvpn layers.

Onion to onion sets an average range of RTT due
to hopcount and speed of light. Software layers
add on top of that.


Those widely deploying onioncat / onionvpn should be
aware of some caveats and good future oppurtunities...

- Users have to compile and run them, they may not
be as available platform wide as openvpn / ssh.
That's minor since joint effort with those projects can be started
to port, document, and publish them [and their binaries again], etc.

- They're IPv6 only, that's minor, expected and ok since everyone
has local IPv6 stacks and apps now and IPv6 is the way forward.
[The encapsulated IPv4 mode is a hack, use IPv6 instead.]

- Doesn't yet work with v3 onion services automagically.
Tor may require an address resolution / translation layer
to do that, which would probably also end up handling
hostnames naming layer as a bonus.
This is a big oppurtunity for anyone who wants to design it :)

- Tor is thinking to kill off v2 onion services despite all the
uses and users of IPv6 and UDP via onioncat / onionvpn.
There is a trac ticket somewhere to continue v2 onion
services in perpetuity, with various levels of support, up
to and including fork of tor client and or network.
Continuation is a fine middle ground.

A few of the related tickets...
https://trac.torproject.org/projects/tor/ticket/23079
https://trac.torproject.org/projects/tor/ticket/6001
https://trac.torproject.org/projects/tor/ticket/25955

There are some communities using bittorrent, voice comms,
and other applications for many years, entirely within onionland,
via onioncat, onionvpn, udp, ipv6. So the tech works pretty good :)


See also...
https://www.onioncat.org/
https://github.com/rahra/onioncat
https://github.com/david415/onionvpn

https://itsecx.fhstp.ac.at/wp-content/uploads/2014/11/FischerOnionCat.pdf
search: the lists for "onioncat", there are detailed posts that
could be collated for reference by those working on things.

[Iain Learmonth]

Hi Conrad,

Post by Conrad Rockenhaus
4) Results of a test were conducted and one second round trip latency was noticed from PSTN to a soft phone connected via Tor (via OpenVPN). Hopefully performance improvement will be noticed with OnionCat.

Tor Metrics has some data on average latencies for client to Onion
service. This is your absolute minimum latency, with the only way to
reduce this being to have latency-aware path selection or to reduce
latencies on the Internet (e.g. by swapping fibre for copper or copper
for microwave).

https://metrics.torproject.org/onionperf-latencies.html

You get benefit from using an Onion Service over using an exit in that
you're using less constrained resources (exits are scarce) but you also
add extra hops to your circuit. For now, these extra hops do increase
latency. Configuring your onion service to not be location hidden would
improve this.

It would be interesting to see what kind of overheads are added by
OnionCat, but I see that this is a project that has an end in sight
unless someone comes up with a way to make it work with v3 Onion
Services. IPv6 addresses are not long enough to encode keys into to make
them self-authenticating. Either we need IPv7 or perhaps some
Onion-native network layer or something else.

If you have the endpoints that support it, Codec2 might give you some
benefits. This was originally designed for amateur-radio low bandwidth
digital voice but is also supported by Asterisk.

It might also be that half-duplex communication (even if implemented
with humans saying "over") could bring benefits as this would allow you
to increase the buffer sizes without having people talking over each other.

Thanks,
Iain.

[Roger Dingledine]

Post by Iain Learmonth
It might also be that half-duplex communication (even if implemented
with humans saying "over") could bring benefits as this would allow you
to increase the buffer sizes without having people talking over each other.

Reminds me of the early days in Guardian Project's voice support in Orbot,
where they essentially built a "push to talk" feature that encoded your
thing as an mp3 and sent it across the Tor network and played it on the
other end. I hear that, once you figured out how to use it, it was
remarkably usable.

--Roger

[Iain Learmonth]

Hi,

Post by Roger Dingledine
Reminds me of the early days in Guardian Project's voice support in Orbot,
where they essentially built a "push to talk" feature that encoded your
thing as an mp3 and sent it across the Tor network and played it on the
other end. I hear that, once you figured out how to use it, it was
remarkably usable.

Someone recently showed me an app where you could record short videos
and send them in a push-to-talk style, for either near-synchronous or
asynchronous communication. They used it to send messages to their young
children while traveling. The first thing I thought when I saw this was
that this would be a perfect candidate for Onion services.

Thanks,
Iain.

[Nathan Freitas]

Post by Roger Dingledine

Post by Iain Learmonth
It might also be that half-duplex communication (even if implemented
with humans saying "over") could bring benefits as this would allow you
to increase the buffer sizes without having people talking over each other.

Reminds me of the early days in Guardian Project's voice support in Orbot,
where they essentially built a "push to talk" feature that encoded your
thing as an mp3 and sent it across the Tor network and played it on the
other end. I hear that, once you figured out how to use it, it was
remarkably usable.

You can still do this today but with the Plumble android app and any Mumble protocol server. You can also do this with Signal over Orbot - voice calls don't work since they are UDP, but voice messages work just fine!

[Conrad Rockenhaus]

Post by Nathan Freitas

Post by Roger Dingledine

Post by Iain Learmonth
It might also be that half-duplex communication (even if implemented
with humans saying "over") could bring benefits as this would allow you
to increase the buffer sizes without having people talking over each other.

Reminds me of the early days in Guardian Project's voice support in Orbot,
where they essentially built a "push to talk" feature that encoded your
thing as an mp3 and sent it across the Tor network and played it on the
other end. I hear that, once you figured out how to use it, it was
remarkably usable.

You can still do this today but with the Plumble android app and any Mumble protocol server. You can also do this with Signal over Orbot - voice calls don't work since they are UDP, but voice messages work just fine!

Understood about the half-duplex communication, but I’m trying to keep this as close to as standard PSTN usage as possible. My goal for this project is to allow an independent journalist in a hostile country or a censored user that happens to not have any technical knowledge other than to connect a soft phone to a username and a password via a a relay or a bridge and make that phone call to communicate to the world what is really going on.

Half Duplex communications are great, but Gulf War I proved to the world how valuable full duplex, real time audio communication can be in a given situation, especially in a situation where no one else is able to provide the world that insight.

For the switching portion of this project - once we’ve proven a concept we need to get a project page like has Iain has suggested. I hope that the switching project’s switches will be required to have open IAX2 interconnect policies and a master directory of “Area” Codes :P.

Thanks,

Conrad

[Conrad Rockenhaus]

Iain,

If it were to be offered as a non-hidden service, what about the UDP portion of the VoIP services, or do we just force everything to be TCP?

Thanks,

Conrad

Signed PGP part
Hi Conrad,

Post by Conrad Rockenhaus
4) Results of a test were conducted and one second round trip latency was noticed from PSTN to a soft phone connected via Tor (via OpenVPN). Hopefully performance improvement will be noticed with OnionCat.

Tor Metrics has some data on average latencies for client to Onion
service. This is your absolute minimum latency, with the only way to
reduce this being to have latency-aware path selection or to reduce
latencies on the Internet (e.g. by swapping fibre for copper or copper
for microwave).
https://metrics.torproject.org/onionperf-latencies.html
You get benefit from using an Onion Service over using an exit in that
you're using less constrained resources (exits are scarce) but you also
add extra hops to your circuit. For now, these extra hops do increase
latency. Configuring your onion service to not be location hidden would
improve this.
It would be interesting to see what kind of overheads are added by
OnionCat, but I see that this is a project that has an end in sight
unless someone comes up with a way to make it work with v3 Onion
Services. IPv6 addresses are not long enough to encode keys into to make
them self-authenticating. Either we need IPv7 or perhaps some
Onion-native network layer or something else.
If you have the endpoints that support it, Codec2 might give you some
benefits. This was originally designed for amateur-radio low bandwidth
digital voice but is also supported by Asterisk.
It might also be that half-duplex communication (even if implemented
with humans saying "over") could bring benefits as this would allow you
to increase the buffer sizes without having people talking over each other.
Thanks,
Iain.

[Iain Learmonth]

Hi,

Post by Conrad Rockenhaus
If it were to be offered as a non-hidden service, what about the UDP portion of the VoIP services, or do we just force everything to be TCP?

You still have 3-hops to the rendezvous point that are going through Tor
so it all still has to be TCP. You get to save though by not having
3-hops from the server side, and you cut down then to a 3/4-hop circuit
instead of 6. While OnionCat lets you pass UDP packets, they are still
encapsulated in TCP when they go over Tor and so are subject to
head-of-line blocking. You're also implementing some form of congestion
control on top of TCP's and Tor's congestion/flow control which can lead
to interesting effects for timer interaction (although for the RTP
streams you don't have retransmissions, just for the signalling).

Thanks,
Iain.