Voip / Jitsi / Mumble

Development
#1

I have reason to believe that Jitsi works over Tor. I am trying to test it at the moment. That’s how I ran into the microphone thing.

Do I need to configure it to use a proxy so it connect to the account? Or should it work seamlessly?

Edit by Patrick:
changed title

#2

Nevermind. After digging around on mailinglists its clear that some aspect of their signalling protocol does not use TCP t the moment and for that reason it doesn’t work.

Perhaps in the future Whonix could have the capability to easily setup different types of hidden services from a GUI interface depending on what the user want. For VOIP it would fetch Murmur - the Mumbler server package and configure it to work with a preinstalled mumble client. Then people could just give out their service address to others via OTR when they want to invite them to their server for chatting.

Video capability is being added to Mumble.
Since its a hidden server that concerns the user only, multiparty chat would still be safe even though encryption is not supported in that mdoe for mumble.

#3

What I don’t like about mumble is its need for documentation since you need to know encryption only goes user <-> server not user <-> user. If you know it you can work around that limitation, but explaining this is moot. I would prefer something as simple as android/whatsapp/skype/facebook/you name it, but Tor-friendly and secure. Maybe in 20 years… In meanwhile, mumble…

Existing instructions:

Also includes mumble.

  1. Someone needs to try them. In this case especially I would be happy for some feedback for mumble or generally on voip.
  2. Then we maybe need to improve the instructions a bit.
  3. When instructions are tested and voip client is actually working well… Then it’s a good time creating a configuration package automating as much from instructions as possible.

But doing step 3) before 1) and 2) doesn’t work well.

See also: criteria for installing applications by default in Whonix:

In case of mumble, it clashes with stream isolation (uses Tor’s TransPort, but the requirement to keep Tor’s TransPort for user’s traffic only needs a separate discussion). Leaks DNS (in case of Whonix, through Tor’s DnsPort):

But maybe when torsocks 2.0 lands in Debian (currently only in experimental), maybe we can use the torsocks method (Mumble · Wiki · Legacy / Trac · GitLab) run it through uwt wrapper (GitHub - Whonix/uwt).

Or maybe just pre-configure it as best as possible (according to criteria), install config package and mumble by default, then if/how users use it?

#4

Nice points you made. Other things I realized about Mumble

  1. Since its server has to be trusted, it must be run locally and accessed exclusively via Tor which removes its TCP advantage. Requiring a server complicates the setup.

  2. No free Mumble servers exist on the clearnet and even if they do, they are a central point of failure given no end-to-end encryption exists in Mumble. MITM of calls would be possible.

  3. It will still rely on Onioncat

The better alternative:

Using Onioncat enables all UDP based VOIP software to work. They have all the features Mumble is missing and additionally have a serverless mode. Registrarless accounts allow calls to be made directly to anyone on the same subnet without setting up SIP servers.

linphone and jitsi are prime candidates for inclusion because they’re feature complete.

#5

Oh, by the way, for clarification, using mumble to talk to 1 contact while either one hosts the server would be as good as end-to-end encryption.

3. It will still rely on Onioncat
Mumble? No? Why?
Using Onioncat enables all UDP based VOIP software to work.
I am not sure Onioncat complicates the setup less than hosting a server.
linphone and jitsi are prime candidates for inclusion because they're feature complete.
I tried (maybe a half year ago) those once with Jason over clearnet, and we failed to establish a voice chat.
#6
Oh, by the way, for clarification, using mumble to talk to 1 contact while either one hosts the server would be as good as end-to-end encryption. ... Mumble? No? Why?

Yes but it lacks authentication like ZRTP’s SAS mechanism. Thats the reason TAILS is looking at mumble in context of it being combined with Oncioncat as the authenticating layer.

I am not sure Onioncat complicates the setup less than hosting a server.
Sure it does, you would need to go in and fiddle with many settings, set up a password and that kind of business. Onioncat is what, 2 commands?
I tried (maybe a half year ago) those once with Jason over clearnet, and we failed to establish a voice chat.

Those options work from experience over clearnet. Over Tor its impossible and would need Onioncat for UDP transfer. In all situations both parties will need to be torrified for VOIP to work whether its Mumble or something else.

#7

[quote=“HulaHoop, post:6, topic:388”][quote]Oh, by the way, for clarification, using mumble to talk to 1 contact while either one hosts the server would be as good as end-to-end encryption.
…
Mumble? No? Why?[/quote]

Yes but it lacks authentication like ZRTP’s SAS mechanism. Thats the reason TAILS is looking at mumble in context of it being combined with Oncioncat as the authenticating layer.[/quote]
I don’t understand why Onioncat is necessary for authentication. As long as only two persons talk to each other, you can set up a server password and therefore be sure, that no one else joins the server. In this case I don’t understand need for any additional authentication.

#8

I see what you’re saying but the TAILS page says. There must be a reason why they did this , as they accept either zRTP on its own or Onioncat but not the absence of both:

Preliminary testing showed OnionCat + Mumble to be a working and relatively easy to setup Tor-enabled VoIP solution; the 1/2s - 1s delay is only slightly annoying.

As it was pointed out in the “Adding voip to torchat” thread on or-talk, OnionCat before r555 provides no bidirectional authentication: the caller has (limited) certainty to be talking to the call receiver, but the reverse is not true. So this shall be used in combination with zRTP or similar, unless the new unidirectional mode is good enough.

#9

Maybe they just didn’t notice there is a TCP mode?

I asked on tails-dev mailing list:
https://mailman.boum.org/pipermail/tails-dev/2014-August/006619.html

#10

One more thing, if all the VOIP clients are being used inside the Tor network then the concerns for stream isolation no longer apply?

IMHO if the stream isolation is still a problem but the Mumble alternatives are immune (jitsi and linphone) then they are the obvious choice.

#11

Yes.

Please someone do a practical test.

#12

The settings are not clear and I must be doing something wrong. Combined onioncat settings in context of example you posted.

in /etc/tor/torcc

HiddenServiceDir /var/lib/tor/onioncat/ HiddenServicePort 8060 192.168.0.11:8060

Restart Tor.

sudo service tor reload

[b] sudo su nano /var/lib/tor/onioncat/hostname[/b]
--- This part doesn't work says there is a new file being created. Shows nothing relevant.

I wish you can test this. It makes more sense because you know anonymity minded people who already know your identity to talk with. The maximum I can do with my setup is simulate two hidden services connected with onioncat and running Jitsi or Linphone inside. A VOIP call on the same computer is pointless and probably too confusing to tell if it really works or if I’m just hearing my own echo.

If you want me just to test out the concept of 2 clients being able to see eachother with onioncat I will. This functionality is really important. It needs to exist in an easy way for others.

#13

[quote=“HulaHoop, post:12, topic:388”]The settings are not clear and I must be doing something wrong. Combined onioncat settings in context of example you posted.

in /etc/tor/torcc

[quote]
HiddenServiceDir /var/lib/tor/onioncat/
HiddenServicePort 8060 192.168.0.11:8060

Restart Tor.

sudo service tor reload[/quote]

[quote]
sudo su
nano /var/lib/tor/onioncat/hostname [/quote] — This part doesn’t work says there is a new file being created. Shows nothing relevant.[/quote]
Where do you read these instructions?

I fixed instructions for Voice over IP (VoIP) a bit. They used HiddenServicePort without HiddenServiceDir.

Please first get a hidden webserver test wise working.

If it works, feel free to disable.

Then move on to more complicated things, i.e. onioncat.

I wish you can test this.
I can test it. It would help if instructions were ready so far.
It makes more sense because you know anonymity minded people who already know your identity to talk with.
I still need to find someone who does that experiment with me. Maybe Jason will help once the instructions are ready.
The maximum I can do with my setup is simulate two hidden services connected with onioncat and running Jitsi or Linphone inside. A VOIP call on the same computer is pointless and probably too confusing to tell if it really works or if I'm just hearing my own echo.
It would still help a lot if you get to this point, I could do a real test with Jason.
This functionality is really important. It needs to exist in an easy way for others.
Sure. It's another item in the great stream of great suggestions. So much functionality needs to exist. Such as: https://github.com/Whonix/Whonix/issues/125 Or stuff from: https://github.com/Whonix/Whonix/issues
#14
Where do you read these instructions?

I was adapting your instructions to those provided by onioncat’s port numbers found here: Configuration – OnionCat

I can test it. It would help if instructions were ready so far.

Ok great. here’s a writeup:

1.setup HS (you probably done it before)

Packages you need:

apt-get install openjdk-7-jre onioncat linphone

For jitsi download their signed package here:
https://download.jitsi.org/deb/binary/

I used version:

dpkg -i jitsi_2.4.4997-1_i386.deb

  1. setup onioncat

  2. Create and use a registrarless account in Jitsi for direct IP-IP calling by following : Free Video Conferencing Software for Web & Mobile | Jitsi

#15
Sure. It's another item in the great stream of great suggestions. So much functionality needs to exist. Such as: https://github.com/Whonix/Whonix/issues/125

That seems major. Surprisingly I thought they had some mechanism to handle revocation, but apparently not. What is the obstacle to your solution? - besides time and energy constraints. The keyserver guys seem open to the idea. Upstream seemed interested, but they suggest GPG handles that which I don’t see happening any time soon.
Can Intregeri’s handle this?

If you decide to make this as a Whonix only feature for the time being its a big plus.

#16

If you don’t like including Jitsi in Whonix because of its Java dependency, there is linphone.

You can test direct IP calling with this:

http://www.linphone.org/user-guide.html

Direct SIP calls in local network

Just enter sip: in the SIP url bar of linphone to place a call to another linphone running in your network.

This works also on the public internet provided that the two machines have public IP addresses or appropriate firewall rules.

#17

Have you succeeded calling yourself using jtisi yet?

Have you succeeded calling yourself using linphone yet?

[quote=“HulaHoop, post:15, topic:388”][quote]Sure. It’s another item in the great stream of great suggestions. So much functionality needs to exist. Such as:
https://github.com/Whonix/Whonix/issues/125[/quote]

That seems major. Surprisingly I thought they had some mechanism to handle revocation, but apparently not. What is the obstacle to your solution? - besides time and energy constraints. The keyserver guys seem open to the idea. Upstream seemed interested, but they suggest GPG handles that which I don’t see happening any time soon.
Can Intregeri’s handle this?

If you decide to make this as a Whonix only feature for the time being its a big plus.[/quote]
Only time constraints.
No idea about intrigeri, seems to mostly try to involve others to get stuff done and having time constraints as well.
intrigeri reads debian-security mailing list as well, so I am not asking people specifically do to this.
What could be done would be writing a bug report against apt-get. No idea how effective that would be. I also haven’t found time yet writing a good bug report against apt-get

#18

For reasons I don’t know, your hidden service instructions still don’t work for me. Tor never creates the onioncat directory, or for any other service, under /var/lib/tor/.

You said you would like to test and I went ahead and supplied easy to follow instructions to recreate the environment I did. This also includes step by step instructions on doing an IP call. But all of this is worthless if hidden services don’t work for me. And I’ve wasted many hours trying. Nothing else I can do about that.

I’m not lazily dumping this on you, but if you still don’t want to do it that’s fine, forget it.

#19

Just found out Hidden services only work when the custom Whonix torcc file is altered. There are two torcc files under /etc/tor that have the same name ‘torcc’. I’m talking about the one with the setting DisableNetwork0. You might want to change the documentation to explain this or call the file something else so people know that they are specifically accessing the copy of the file that works when using commandline.

#20

It’s “torrc” not “torcc”. It is not possible to have two files with the same name. Please post result of.

ls -la /etc/tor

/etc/tor/torrc.examples should not be edited. The comments at the top should be pretty clear.

**** Do NOT edit this file! ****

This file will show you examples you can copy and paste to /etc/tor/torrc

Additionally, you can read the official Tor Manual at:

    **** Do NOT edit this file! ****</blockquote>

Also on graphical Whonix-Gateway there is a shortcut to /etc/tor/torrc. It asks for password automatically need to enter your password first to be able to edit it. The /etc/tor/torrc.examples file cannot be edited.

/etc/tor/torrc.anondist-orig should not be edited. But instructions say “sudo nano /etc/tor/torrc”. Pretty unambiguous.

/etc/tor/torrc.anondist and /etc/tor/torrc is the same (symlink). “Both” can be edited but for simplicity just stick to /etc/tor/torrc.

An eventual /etc/tor/torrc~ is a backup file created by kwrite. Editing it would have no effect.

However, anything can go wrong will go wrong. On graphical Whonix-Gateway I don’t understand what could be wrong. And in terminal Whonix-Gateway, instructions say “sudo nano /etc/tor/torrc”. I have not the slightest clue what you by “same name”.