Voip / Jitsi / Mumble

Development
#60

Wouldn’t call it concern. Rather further research.

[quote]I am still curious to see setups with just one hidden service as server and a client[/quote]

This is in fact possible. Instead of using ocat address.onion you would replace address.onion with a parameter -R to run as a ‘client’ only mode. That means only one out of the two parties has to go through configuring a HS. Bear in mind though that contact can only be established after the client party connects to the one running a HS, becuase the latter can accept incoming connections while the former cannot.


I forgot to add, I meant also without using onioncat. Because that adds complexity and makes the setup more difficult.

For example by using a Tor hidden service mumble (TCP mode) server + Tor client connecting to it (also in TCP mode).
Advantages:

  • onioncat not required
  • just one hidden service required rather than two (better latency)

Or some Voip client using TCP. Just saw that linphone has a SIP TCP mode. Someone could set up a Tor hidden voip server and the calling partner could connect to it through Tor in TCP mode. Advantages:

  • onioncat not required
  • just one hidden service required rather than two (better latency)
The only reason clearnet is pursued is for those who want to contact a non-anonymous party.
Not necessarily.
Its unlikely that first contact ever be initiated through VOIP.
Didn't had first contact in mind. Unrelated to my argument.
[quote]The latter would have to include, that the server can long nothing useful, just notice, that two random pseudonyms have an encrypted voice chat. [/quote]

If the two sides are anonymous, then usage within the Tor network makes more sense.


Not necessarily. Two Tor users having a voice chat using a clearnet server can make sense. Conditions:

  • ignoring the ZRTP fingerprinting issue below [if it’s valid, then the two Tor users and a clearnet server should of course not be used - but I would like to explain my thinking here]
  • two Tor users know each other already, met offline, agreed to meet up on some public free clearnet voice chat server (or perhaps they’re using TorChat or something like that and agree on the server)
  • no hidden services involved (best latency using Tor)
  • random pseudonyms
  • voice chat client that supports TCP mode
  • voice chat client supports end-to-end encryption
  • see also: Voice over IP (VoIP) (I wanted to say the same there.)
When using zRTP + SRTP for encryption in any stretch that goes on the clearnet, be sure to never select a VBR (variable bitrate) codec as the pauses in a conversations produce fingerprints in the encrypted stream that allow the adversary to infer what words are being said.
This sounds horrible. Sounds like a complete failure of ZTRP. Should be documented. Please add this + reference to the https://www.whonix.org/wiki/Voip wiki page. In that case probably my above use case Tor users having a voice chat using a clearnet server should be avoided and one hidden service should always be involved.
#61
I forgot to add, I meant also without using onioncat. Because that adds complexity and makes the setup more difficult.

Sure but there is a way to have it do that only 1 HS is needed which I posted. Please include this in documentation for those would like this as an option.

I added the note with the reference on VBR.

#62

Thanks for doing that already.

#63

Linphone instructions have been divided into callee setup and caller setup. I hope these changes make the setup simpler for at least one calling partner. Please check them out.

#64

Good writeup and should be easy to follow. There are some places I need to make more clear and other information I’ll include in a bit. I’ll try to transfer some relevant notes to the Onioncat page too.

#65

Continuation of this thread here:

#66

A group of devs in Ecuador have written scripts for setting up a onion mumble server and connecting to ti for participants:

1 Like
#67

Has evolved into the Wahay project on github with Debian packaging in the works. Good reports on functionality from the team on Tails-dev.

1 Like
#68

Remote work needs have catalyzed many projects to come up with more usable self hosted VoIP solutions as alternatives to Zoom.

https://anarc.at/blog/2020-04-09-mumble-dreams/

https://veronneau.org/using-jitsi-meet-with-puppet-for-self-hosted-video-conferencing.html

#69

1. Time to undeprecate Jitsi?

Tor Project recommends Jitsi Meet in 2020:

Sites:

Jitsi Meet - Secure, Simple and Scalable Video Conferences

Jitsi Meet is an open-source (Apache) WebRTC JavaScript application that uses Jitsi Videobridge to provide high quality, secure and scalable video conferences. Jitsi Meet in action can be seen at here at the session #482 of the VoIP Users Conference.

The Jitsi Meet client runs in your browser, without installing anything else on your computer. You can try it out at https://meet.jit.si.

Jitsi Meet allows very efficient collaboration. Users can stream their desktop or only some windows. It also supports shared document editing with Etherpad.

Installation

On the client side, no installation is necessary. You just point your browser to the URL of your deployment. This section is about installing a Jitsi Meet suite on your server and hosting your own conferencing service.

(If you want to host a Jitsi server only below - not necessary for general Whonix users)

Installing Jitsi Meet is a simple experience. For Debian-based system, following the quick install document, which uses the package system. You can also see a demonstration of the process in this tutorial video.

For other systems, or if you wish to install all components manually, see the detailed manual installation instructions.

Installation with Docker is also available. Please see the instruction.

See also: Introduction | Jitsi Meet

Looks like you can just do videochat straight through the browser, no account needed, fully encrypted, 100% opensource and just need to create a meeting name?

Seems to work in Tor Browser with JS enabled - so if it works, who wants to bother with really complicated setups as per all the other VoIP options. Too easy to be safe?

It then creates a room with link, dial in & pin, and you can just cut and paste the details to share with whomever. Optional password can be set for others to join the link. (You should maybe test this with one of your Whonix friends Patrick to see if it works well, with not too much delay etc.)

2. http://www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/FTP

Filezilla works out of the box, but is not pre-installed.

For Tor Browser and/or wget, users could experiment with TrackHostExits [archive]. Further information on TrackHostExits can be found here [archive] and here [archive].

What do you want here - just Filezilla install instructions, some pics, and basic “How to”? Will it need anything special in Whonix?

3 Likes
Long Wiki Edits Thread
#70

I dont think its recommended for anonymity purposes e.g:

  • Presence of JS , and im not sure if the JS libraries open source but doesnt make it ok using TB with JS.

  • Jitsi over Hidden Services working?

  • And since there is no hidden services based on it then it doesnt resolve metadata issue, and connection always over TLS.

  • Using WebRTC which is not really welcome in privacy area

So its not really Tor,TB friendly the TPO want to recommend it fine but they show us or jitsi how is that safe for anonymity.

Alternative but doesnt mean better BigBlueButtom.

So unless testings showing there is possibility to have hidden services and connection over Tor/TB i dont think should be mentioned anywhere. It will be just bulky wiki not security/anonymity based one.

It would be nice recommending SFTP rather than FTP:

2 Likes
#71

I don’t think we have it listed anymore when we realized VoIP needs UDP.

Have you tested it?

Jitsi meet is based on WebRTC which is based on UDP so won’t work without tunneling over Tor with another browser. It can’t be used by TBB since all WebRTC was torn out because of IP leaks. Hosting your HS is not possible unless all parties use Onioncat and even then there is no secure implementation for v3 with Onioncat.

Sounds good. This part should be standard, the problem I experienced was finding an easy to configure/use FTP server on the desktop that had secure defaults. Instructions and recommendations are all over the place. If you can narrow down package choices that would be a major step and I’ll try to figure out use.

Filezilla supports it. Have you ever used it?

2 Likes
#72

I read that yes, but i didnt tried it since sftp can be used directly.

1 Like
#73
2 Likes
#74
1 Like
#75

Thanks to @JeremyRand all the necessary work for Wahay Whonix support has been developed and merged upstream.

Next we should figure out the easiest and most maintainable way to include it in Whonix:

Either through adding their repo or using binaries-freedom

cc/ @Patrick

In the space of super efficient video codecs, Google has amazed by releasing Lyra which is capable of working on the crappiest and most low bandwidth connections out there including 56K modems. If such a feature can be integrated in Wahay somehow we can achieve what wasn’t possible before - a high latency tolerant video conferencing technology. Mind blowing :brain: :bomb:

2 Likes
#76

Not quite everything, but we’re making a lot of progress. My upstream torgo patches were migrated into Wahay’s vendored copy
of torgo today: Bump vendored torgo · Issue #25 · digitalautonomy/wahay · GitHub . IIRC the main things left to upstream are some onion-grater profile patches (Wahay’s onion-grater profile only works with Tails right now; I have some small patches that make it work with Whonix) and a firewall compatibility patch (right now Wahay listens on a random port; we should make it pick a port from a small range so that we don’t have to open all incoming connections in the Whonix firewall; I don’t have a patch for this yet but I don’t expect it to be difficult). Technically the Go binaries produced by the upstream source should work fine with Whonix as of today now that the torgo patches are vendored, since Whonix-Gateway’s onion-grater profiles are packaged separately from Wahay, and the firewall thing is just an attack surface issue, not a dealbreaker for getting things to connect at all. But I still want to get these remaining issues dealt with upstream.

It sounds from the Google article that Lyra is specifically an audio codec; video is out of scope (though you could combine it with a good video codec e.g. AV1 to get 56kbit/s videoconferencing). The Google article doesn’t explicitly say whether Lyra supports truly constant bitrates, which would be important for our use cases but may matter less for the use cases that Google developed this for. (If it doesn’t support CBR, that would presumably not be hard to add though.)

3 Likes
#77

Patch submitted for the onion-grater profile. Fix onion-grater profile for Whonix by JeremyRand · Pull Request #27 · digitalautonomy/wahay · GitHub If anyone here is more comfortable with onion-grater than I am, feel free to give it a look-over in case there’s something I can improve.

This is the last patch code-wise needed to get Wahay to connect successfully (though you’ll still need a suboptimal firewall config until the port range is fixed).

4 Likes
#78

I see. Thanks for explaining. It seems video support is considered out of scope by Ola anyhow, his focus is on making Mumble usable over Tor only rather than extending functionality downstream. I don’t know if mentioning the possibility of video to the Mumble team would be considered heretical though.

2 Likes
#79
2 Likes