On 02/04/13 17:08, Simon McVittie wrote: > On 02/04/13 11:14, Daniel Pocock wrote: >> As both of these servers support long term credentials, I think it would >> be highly worthwhile to be able to use them with empathy. Possible >> config options in empathy: >> >> STUN/TURN server name: ? >> STUN/TURN server protocol: (UDP/TCP/TLS) >> Server supports TURN (checkbox) >> (Long term credential) username: >> (Long term credential) password: > > This is not going to happen in Debian wheezy, which is already several > months behind its various upstreams due to the freeze, but yes.
At a bare minimum, could there be a STUN_SERVER and TURN_SERVER environment variable (similar to HTTP_PROXY?) for those who really want slightly more control over these things? The value could be expressed as a URI, http://tools.ietf.org/html/draft-nandakumar-rtcweb-turn-uri-00 > Would it be desirable to support having STUN server != TURN server? I > suspect that the answer might be "yes in telepathy-gabble, but no in the > Empathy UI"? (If neither is given, the STUN server should default to > stun.telepathy.im, whereas the TURN server should default to nothing.) I agree this is different It is very important to keep in mind that one TURN server (reTurn) supports STUN clients, while the other, TurnServer.org, only supports true TURN clients. Any error messages about rejected STUN requests probably need to hint that the server may only support TURN. > Ideally, the TURN server should probably be discovered from DNS SRV if > not configured, like SIP does (dan...@example.com -> > _turn._udp.example.com or something). Lumicall currently uses _stun._udp to lookup TURN: $ dig -t srv _stun._udp.sip5060.net ;; ANSWER SECTION: _stun._udp.sip5060.net. 60 IN SRV 0 1 3478 stun-test.sip5060.net. but that appears to be naughty, I should change it to _turn._udp as well: http://tools.ietf.org/html/rfc5766#section-18 > Rather than having the password in the account settings in clear text, > it would probably be better to have a SASLAuthentication channel pop up > and ask for it, like we do for the main account password (in GNOME, that > channel is handled by the Empathy.Auth component, using gnome-keyring). > We don't yet have D-Bus API for asking for passwords other than the > server's "main" password. The first step would be for someone interested > in this to describe the use case on a Telepathy (freedesktop.org) bug. > >> The implementation I made in Lumicall does TURN server discovery via DNS >> SRV and tries to use the SIP credentials as TURN credentials > > That's all very well for SIP, where credentials are frequently passed > around without TLS anyway, but XMPP servers conventionally use TLS and > we default to strict SSL validation, so I doubt we should be handing out > the XMPP password on a clear-text TURN connection? I suppose we could > try using it if require-ssl = FALSE or something, but in an ideal world, > nobody would ever have that set anyway. That's not quite the case: a) SIP uses a challenge/response DIGEST mechanism (with nonce to prevent replay attacks) and even without TLS, passwords can never be sent in the clear as they can with HTTP plaintext auth b) Before putting reSIProcate and the repro SIP proxy into Debian, I made sure the full mutual TLS support was possible (RFC 5922) on a par with what XMPP does by default. It is really cool and works with popular clients, including Empathy and Jitsi: http://www.resiprocate.org/ReproMutualTLSAuthenticationJitsi and the same code is now being leveraged to secure SIP over WebSockets c) Even when TURN does not use TLS, it is also using a DIGEST style mechanism to protect the long term credentials, so using the SIP or XMPP credentials as TURN credentials should not risk the disclosure of those credentials: http://tools.ietf.org/html/rfc5389#section-10.2 I would agree there is a slight risk in that the username could be disclosed in the clear over TURN even though the credentials were fully protected over TLS for XMPP. A security-concious UI might encourage the user to only use TURNS (TURN over TLS) >> Thanks for explaining this. For the issue at hand, >> - I've tested with two clients on the same LAN (against ejabberd on >> squeeze) and they still don't work. > > I've asked for further logs on the Debian bug, with details of how to > get them. Hopefully that'll be more enlightening... I will provide those details in the next few days >> - could any other change in the recent upload (4 March) have contributed >> to the problem I am facing? >> http://packages.qa.debian.org/t/telepathy-gabble.html > > The timing does sound suspicious, but I've re-checked the diff that I > sent in the unblock request, and nothing there seems relevant. Thanks - as mentioned, I use it against an ejabberd instance on squeeze, if you also have the ability to test that combination of without too much trouble. _______________________________________________ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy