|
|
|
|
|
by kodablah
2224 days ago
|
|
I can see where a FQDN candidate is no biggie in a browser's offer/answer since DNS lookups occur all the time. But I imagine the simple fix for Signal's WebRTC use, since they control both sides of the exchange, is to just disregard non-IP candidates. Or even better, don't do anything with the candidates until the call is accepted. Worst case, could just have a geographically centralized signaling server (or shared IP). Granted, since Signal controls both sides, might as well only serve fixed "host" candidates and disallow any offer/answer with custom crafted ones. One also wonders, to prevent other forms of leaks, if Signal can make a blanket policy to prevent DNS lookups or in general get tighter control on outbound network. |
|
The downside of disregarding all candidates until the call is accepted is that post-accept connectivity would be much slower.
Going through a server to hide your IP is an option in the settings in the app, but it can potentially lead to higher call latency, so there is a trade-off.
To prevent issues like this in the future we are taking more control of WebRTC's behavior with a fork of WebRTC (Signal uses WebRTC) and are providing patches to upstream WebRTC as well.
(I work at Signal on calling)