Can’t connect to IRC becuase of exit bans. Will keep you updated here however.
Onioncat not working still.
I’ve told the Onioncat dev.
Patrick would you be okay with setting up a HS and onioncat on a test workstation vm? I want to see if you will respond to my ping requests.
Would be difficult due to different time zones and no 24/7 running machine.
I advice to go for multiple Whonix-Workstation with multiple hidden services. That reproduces the same.
Or in doubt multiple Whonix-Gateways (but that should not be required).
Or in doubt using multiple computers for this setup.
Great news! Thanks to Berhnard Onioncat dev I managed to get to the bottom of this and get Onioncat working.
The summary:
OnionCat listens by default only on localhost (127.0.0.1), for security reasons. But if your Tor is on a different machine that does not work. You have to make it listen on all IP addresses with the following option: "-l 0.0.0.0:8060"
Steps to perform a anonymous VOIP call:
- Setup HS
- Onioncat must be started with these parameters on Whonix Workstation:
ocat <your local HS address> -l 0.0.0.0:8060-
sudo ifconfig. Copy the IPv6 address listed for the Onioncat tun0 interface. Exchange it with the other party preferably over Torchat.
-
Open Linphone settings and select IPv6. Apply and restart Linphone
-
At this point you should have exchanged ip addresses. To call someone put in the call box. Must use brackets:
username@[onioncat ipv6 address]
- Success. Now the other party will receive your call.
Instead of adding all these steps to the wiki, I believe that the only way this will be accessible to our users is if we include it in a frictionless manner configured out of the box.
Linphone being full featured and having mobile chat clients makes it the client of choice. Should there be an Onioncat port to Android someday, easy anonymous and secure VOIP between devices of all form factors will become a reality. [Feature Request] Onioncat Android Port · Issue #495 · guardianproject/ChatSecureAndroid · GitHub
Out of the Box Implementation:
- Include Linphone and Onioncat packages
- Setup onioncat to autostart with the system using the parameters listed above.
This is done by editing its config file at: /etc/default/onioncat
ENABLED=yes
DAEMON_OPTS=" Settings paramters go here"
All a user has to do is to paste their Hidden Service address in this file for it to be handled automatically.
-Linphone’s configuration file is fonund at: /home/user/.linphonerc
-The settings parameter to have it use IPv6 wold be inserted in that file. This and all of its settings could be tweaked by looking them up from this manual: en.flossmanuals.net/linphone/ch009_configuring/
IronSoldier recommends that onioncat be bound to the workstation internal IP address instead of all interfaces for more security. I don’t know how much more that gives if running behind a Whonix gateway. Since the only interfaces are loopback and the LAN one.
Did a test with this and it works too:
Sounds good!
Have you heard yourself?
[quote=“HulaHoop, post:46, topic:388”]IronSoldier recommends that onioncat be bound to the workstation internal IP address instead of all interfaces for more security. I don’t know how much more that gives if running behind a Whonix gateway. Since the only interfaces are loopback and the LAN one.
Did a test with this and it works too:
While it wouldn’t hurt to listen on all interfaces, it is indeed better to listen only on eth0 interface (IP 192.168.0.11 on Whonix 8.2).
Have you heard yourself?
I can but its not possible to distinguish between which endpoint the output is really from. This needs a real simulation between two parties. Can you please do that?
I can understand your hesitation in avoiding this setup when the details of getting it to work weren’t figured out. The time investment for something that wasn’t working wasn’t justified. But now it should be simple retracing of my instructions.
If you use KVM, microphone is available and you can also redirect your USB webcam to the vm if its integrated or plug it in.
Where to start onioncat? On Whonix-Gateway in your instructions?
Wouldn’t it be possible and much better to start onioncat on Whonix-Workstation? Can you try please?
This needs a real simulation between two parties. Can you please do that?Yes.
It can be made easier in Whonix 10. Shipping such configs shouldn’t be hard.
[
Except enabling a hidden service by default - we probably shouldn’t do this for performance reasons and for not harming the Tor network (performance). I think I asked on tor-talk about that some time ago, but I don’t find at the moment.
Also see:
But you didn’t suggest that yet. Just mentioning.
]
WIll be quite some time until Whonix 10. So I think in meanwhile it would help to have good instructions in meanwhile, so I can point Jason to it and so perhaps others can experiment with this in meanwhile.
I have always started ocat in the workstation for security reasons and its under these conditions that it works. Noted it in steps post.
Becuase its only using the Workstation I don’t understand the point of binding it to the 129.168.0.11 interface when its the only one possible for any traffic to the outside world. The other interface being the loopback.
There is probably no improvement for doing this on a default Whonix-Workstation, but this might have unexpected side effects for users who add additional (virtual) network interfaces such as OpenVPN. So the safer route is to explicitly bind it where necessary.
Started documenting this:
Any special reason for using port 8060 or was it an arbitrary choice?
Having very good wiki manual instructions is useful so or so for any case generally no matter if we later automate it or not. It’s like with any topic where you make notes to understand things or where you want to remember things. If your math notes look unorganized, if you have a horrible handwriting, and so forth, that’s similar on how it’s looking in your brain.
Because before you can automate it, you need to exactly know how it would work manually. And for later debugging / improvements / development / understanding / auditing / etc. it is good having the manual instructions around. After automation is done and stable, manual instructions can be moved to another /Dev/… wiki page.
Any special reason for using port 8060 or was it an arbitrary choice?
Its the port cited on the onioncat site. It could work with any other choice as long as both numbers match, the HS port and the onioncat port number listening setting on the ws.
Having very good wiki manual instructions is useful so or so for any case generally no matter if we later automate it or not. It's like with any topic where you make notes to understand things or where you want to remember things.
Agreed.
Made arbitrary choice of port to avoid conflicts with custom onioncat setups to 64739.
Instructions are ready, please check:
Asked Jason to call me. (He now needs to read the mail and we have to find an appointment were we’re both online.)
Should we write a blog post and encourage testing by others?
Made arbitrary choice of port to avoid conflicts with custom onioncat setups to 64739.Instructions are ready, please check:
Voice over IP (VoIP)
Looks good but you may want to change username to just user as it is by default to avoid confusion.
Asked Jason to call me. (He now needs to read the mail and we have to find an appointment were we're both online.)
Excellent.
Should we write a blog post and encourage testing by others?
Yeah this is newsworthy and deserves its own post. 
About your remarks on HiddenServices being enabled out of the box. I wanted to mention that the Briar tor-centric p2p messaging platform, automatically creates Hidden services to allow people to connect to one another whenever its installed. I wouldn’t say the load will be too much considering we already do things like updates over Tor. Maybe having one key be generated and used for all hidden services behind a gateway could help in this regard.
Done.
About your remarks on HiddenServices being enabled out of the box. I wanted to mention that the Briar tor-centric p2p messaging platform, automatically creates Hidden services to allow people to connect to one another whenever its installed. I wouldn't say the load will be too much considering we already do things like updates over Tor. Maybe having one key be generated and used for all hidden services behind a gateway could help in this regard.apt-get updates over Tor are okay with TPO (directly asked): https://www.whonix.org/wiki/FAQ#You_should_not_waste_the_Tor_network.27s_bandwith_by_downloading_operating_system_updates_over_Tor.21
Hidden services are different. Needs a separate discussion. I don’t remember how hs directories work. Not sure if they can take a sudden extra few thousands. Also security wise it wouldn’t be a good idea, since unpublished hidden service domains aren’t secret. We have no open incoming connections (issued from outside) by default but by enabling a hidden service by default we would add one.
Also network fingerprint for ISP would change, see:
distinguishing between (non-) hidden service hosters, too few/much open circuits:
I see. Its impressive the amount of tickets with good ideas on the Tor tracker. You have a good eye for details.
I will address the concerns you bring up at the end of your post here, then refer to them on the list too.
https://mailman.boum.org/pipermail/tails-dev/2014-August/006741.html
I am still curious to see setups with just one hidden service as server and a client
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.
http://manpages.ubuntu.com/manpages/raring/man1/ocat.1.html
-R Use this option only if you really know what you do! OnionCat generates a random local onion_id. With this option it is not necessary to add a hidden service to the Tor configuration file torrc. One might use OnionCat services within Tor as usually but it is NOT possible to receive incoming connections. If you plan to also receive connections (e.g. because you provide a service or you use software which opens sockets for incoming connections like Bitorrent) you MUST configure a hidden service and supply its hostname to OnionCat on the command line.
as well as setups using third party clearnet servers
Not possible at the moment as SIP based clients all use UDP with a few exceptions. However for clearnet communication, a viable candidate is Jitsi. Their GSOC project this year is concentrating on creating XMPP Jingle based VOIP server nodes that uses TCP instead of UDP for the censorship-prone aspects of UDP that make it vulnerable.
Jitsi seems the most feature rich Free VOIP software out there. I think I’ll give it a shot once more now that Onioncat is figured out.
The latter would have to include, that the server can long nothing useful, just notice, that two random pseudonyms have an encrypted voice chat.
If the two sides are anonymous, then usage within the Tor network makes more sense. The only reason clearnet is pursued is for those who want to contact a non-anonymous party. Its unlikely that first contact ever be initiated through VOIP. Its almost always a written one. One can invite the party of interest to download Whonix or TAILS and from there start a videochat.
Solutions for Multi-party Audio and Video conferencing within Tor:
-
WebRTC in TBB + Onioncat – More advanced collaboration features are possible because of Jitsi’s ongoing work in this space.
-
Jitsi Client Supports advanced features like Multi-party video conferencing, someone’s client will be running into server mode for that purpose because of latency management.
-
Linphone supports multi-party audio conferencing only as of yet AFAIK.
Other VOIP Notes:
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.
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.