Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 12 Sep 2018 09:33:19 -0400
From: Daniel Kahn Gillmor <>
To: Dhiraj Mishra <>,
Subject: Re: tdesktop leaks user IP address

Hi Dhiraj--

On Tue 2018-09-11 17:25:47 +0530, Dhiraj Mishra wrote:
> tdesktop leaks user IP address
> This is still not fix in telegram desktop  team says their is nothing to
> fix here and this is working has intended.

Thanks for this report -- it's good to have people looking at metadata
leakage and considering it as a security concern.  It is.

However, i'm not convinced that you've described the problem you're
seeing well enough to be actionable yet.  In particular, it's not clear
to me *whose IP address* you are concerned about leaking, and *where*
you are concerned about it leaking.  It's also not clear to me that
you've evaluated the impact/consequences of your proposed mitigation.

I've written out several questions below in the hopes of helping clarify
the concern, and figuring out what makes sense to do about it.  Please
take these questions in the spirit of constructive engagement!

> tdesktop:
> *Steps to reproduce:*
> 1. ./Telegram
> 2. Call end user
> 3. The access log on CLI reveals the end user public IP address.

let's give the parties involved in this names so that it's easier to
reason about.  Let's say that the call Initiator is Inigo, and that the
call recipient is Rebecca.  So Inigo takes steps 1 and 2.  Whose public
IP address (Inigo's?  Rebecca's?) leaks into which access log
(Inigo's?  Rebecca's?  both?)?

Is the concern really the inclusion of the IP address in the access log,
or is it the fact that Rebecca's public IP address is visible to Inigo,
and vice versa?  To whom else is this IP address visible?  Another way
of asking this is: who is the adversary you're concerned about learning
this IP address information?

 * someone looking at some specific logfile in the future?

 * the other party on the call during the call? (i.e. Inigo is Rebecca's
   adversary, and vice versa)

 * the Telegram server operator?

 * a network monitor inspecting traffic?

 * …

> By default in tdesktop p2p is enable, which open a direct communication
> when calling to the other user, potentially seeing his/her IP. Telegram is
> supposedly is a secure messaging application but while calling another user
> leaks his/her public IP address in access log. However, by navigating to
> Settings and Privacy  > Calls > and set P2P to `nobody` in telegram apps in
> (iOS and android) will not allow others to view public IP of end user, but
> this option is still not available in tdesktop, which makes tdesktop
> vulnerable to this issue.

Who needs to set P2P to "nobody" to have this change?  If either party
makes this choice is it sufficient for a given call?

Presumably turning off P2P means routing the calls through a central
server (perhaps via STUN/TURN or some other relay/proxy equivalent).  If
that's not the case, how are calls completed when P2P is disabled?  Who
operates that central server?

What is the performance impact (on rates of successful connections, on
latency during calls) of such a change?

Is the central server operator already in a position to be able to force
this shift from P2P to a centralized fallback?  What cost(s) would they
pay if they force this shift?

How does the potential for centralized mass surveillance of call traffic
change if all calls are routed through the central server by default?



Download attachment "signature.asc" of type "application/pgp-signature" (228 bytes)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.