[Telepathy] empathy broken during Debian freeze

[Daniel Pocock]

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 (daniel at 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.