TURN protocol leaks username
MilanKral opened this issue · 9 comments
Current mobile networks with NAT many times require use of TURN servers.
Most TURN server authenticate users using username and password.
Because aTalk only supports UDP protocol for TURN it leaks the username - username is transferred in clear text. When "Auto discover STUN/TURN" is used to gather TURN servers, then the TURN username is the Jabber username, so Jabber username is leaked.
Please consider enabling support for TLS, DTLS for TURN.
Please consider implementing support for XEP-0215, which allows the Jabber server to publish short-term TURN login username and password.
Here is a proposal for TLS, DTLS support.
https://github.com/MilanKral/atalk-android/tree/TURN_TLS
But I still can't get ICE4J to use TLS, DTLS.
Thanks for your contribution. I have manually pulled in all the source changes for the next aTalk release.
Thanks for your contribution. I have manually pulled in all the source changes for the next aTalk release.
What's left to make DTLS working? In 2.2.4 the option is grayed out and not selectable.
I have continue your question in its original thread.
But I still can't get ICE4J to use TLS, DTLS.
Just checked in the source with ice4j-2.0.0-20181024.160538-12 upgraded to the latest ice4j-2.0.0-20190607.184546-36. No sure if this helps in TLS and DTLS
I need NAT config for Atalk
MDS
Hello
Sir
I referred to the online help for configuring NAT between two different mobile networks (example between the Orange mobile network and Teletel), but without success.
Let me explain :
1 - When two smartphones on two different mobile networks (example between the Orange mobile network and Teletel mobile) are called, communication is established but there is no sound (ZRTP does not turn green) so the correspondents do not get along.
2 - When two smartphones on the same mobile network (eg the Orange mobile network alone) call each other, communication is established and there is sound (ZRTP turns green) so the correspondents get along very well.
To fix the NAT I have tried the STUN Google = stun.l.google.com: 19302 and our own STUN = server2magdia.africa.com:3478 without success.
Always to correct the NAT I also tried some Atalk versions (versions: 1001, 1053, 1062, 1.6.6, 2.3.4, 2.4.1, and the latest = 2.4.3}, but also without success.
In short, the only problem I have with Atalk, this product that I love so much, is correcting the NAT.
I sincerely ask you to help me solve this problem.
If you need two clients (openfire users) to test yourself, let me know.
The version of my Openfire server is 4.2.3.
I also have a question:
Which XMPP server does Atalk not have a NAT problem with (i.e. on two different mobile networks, the correspondents get along very well) ?.
Thank you for your prompt reaction
Regards,
MAGDIA
aTalk v3.0.3 has implemented the supported for XEP-0215.
Please consider implementing support for XEP-0215, which allows the Jabber server to publish short-term TURN login username and password.