Delta has an increasing amount of peer-to-peer functionality. Unfortunately, P2P can, rather intrinsically, leak IP addresses. This is can be a problem in some situations.
Could we have a setting to disable all P2P functionality, or allow it only over Tor or I2P or some other proxy? This could give peace of mind to those who don’t want to risk leaking their IP.
It might make sense to make this a per-profile setting.
What you can already do:
It’s seems strange for me to build whole ecosystem of applications and servers to prevent users from making missteps in encrypted email handling, and in the same time to keep on creating new opportunities to make mistakes.
‘Just not open WebXDC apps’…
‘Just not answer the calls’…
Dear devs, we like your shiny toys. But please, do not force us to play with them. Add the ‘off’ switch.
Signal and Telegram offer an “Use peer-to-peer with … <these contacts>” and “Always relay calls”. These settings control the WebRTC iceTransportPolicy. It’s to be set to 'relay' in order to always use the TURN server (hosted on your Chatmail server).
So, basically it’s a matter of flipping the switch implementation-wise.
Signal also always relays the call if isContactUntrusted.
As to “WebXDC real-time channels”, I am not sure how to do it there, because it’s not WebRTC but Iroh.
Some related issues:
@9er @Minim Delta Chat is for private chats with friends and family, no for “chat with your enemies”, you don’t need to hide your IP from them, nor most people care about that, if you really care about hiding your IP, you don’t need extra settings in delta chat, you will be using Tor or a VPN, because anyways people send links etc. and you would easily leak your ip to some random server, by accident, plus your ISP watching your traffic, etc.
about the existing proxy setting in Delta Chat, all traffic should go over the set proxy, currently this is not the case in some situations and that is know bug/limitation
@adbenitez, in practice, people use DC chat with people they trust imperfectly. Even if a close family member/friend has my best interests at heart, they may not have the technical competence to defend those interests in a complex environment. They may have dementia.
Even if they are well-intentioned and competent, they are human and they will accidentally hit a button or link they should not have. Real-world attacks, even attacks on experts, frequently rely on the fact that humans have great difficulty being perfectly consistent, and sooner or later they mess up.
I like DC substantially because it makes encrypted messaging easy enough that I can get others to do it. I want software where I can say “Install this, and you’ll be fine.” Maybe “You can make it do bad things if you dig through the settings bits you don’t understand and ignore the UI warnings (but you won’t do that)”, too.
your comment is just reinforcing my previous opinion, if your familiar have dementia the more reason to have some global VPN instead of hopping they will use the app correctly and not to click random links
anyways this is getting really way off of practical reality, most people don’t even care about this, so I will not keep wasting time discussing some hypothetical scenario in which you plan to boicot the government with your demential Grandma and need the super-duper secure protection of Delta Chat to not leak your IP because ofc maybe she is actually a double agent and you can’t trust her
That seems a harsh interpretation of my argument. I’m suggesting a setting to make it easier for falliable humans to use the existing security settings consistently.
Global proxies are great (though they don’t do streams separation). They are not commonly used, in my experience largely because websites break over many of them. They are becoming more common, currently largely because of teens evading legislated age verification.
sorry if that seemed harsh, I apologize, I was just trying to point out the absurdity of the suggested scenario
please notice that we are not going to add new options here and there every time someone ask for it, it is part of our guidelines to avoid as much as possible adding new options, we can’t assume people will understand such options either, ex in your suggested scenario you said that someone with dementia can click around and use a p2p feature, the same way, they could go to the settings and disable the p2p protection switch, etc.
and to start with, such option would need to be disabled by default, because what most people care is reliability, they want mini-apps to work, calls to be fast and work, hence only a few advanced users will manage to go to the settings and disable p2p options, so it would have low impact and make it harder to debug problems
EDIT: see posts below
It is not enough to flip the switch to hide the IP address. If Alice has “relay only” switch enabled and Bob calls Alice with a list of candidates, Alice will accept any relay candidate even if it is a TURN server controlled by Bob logging Alice’s IP address. As far as I understand TURN allows Bob to make an “allocation” on the server, but Alice has to connect directly to Bob’s TURN server and port provided by Bob.
TURN server allows Bob to create an allocation and ask Alice to connect there, but Alice then cannot use her TURN server to hide her IP address. If both Alice and Bob have their own TURN relay that they trust and don’t want to trust each other relay, they cannot establish a connection.
Signal and Telegram clients should filter the relay addresses received in the call offer/answer that comes from the other side to only allow TURN servers controlled by Signal/Telegram when the setting is enabled. If the clients do not do such filtering and only change iceTransportPolicy then this setting does not actually protect the IP address.
Are you sure that’s how it works? Are you saying that Signal’s implementation is incorrect, and that the web spec is incorrect?:
This can be used to prevent the remote endpoint from learning the user’s IP addresses, which may be desired in certain use cases. For example, in a “call”-based application, the application may want to prevent an unknown caller from learning the callee’s IP addresses until the callee has consented in some way.
(also see the “Revealing IP addresses” section)
I don’t think that it’s implied that the peer (Alice) or the signaling server also has to be “sanitizing” the other peer’s (Bob’s) SDP and trickled ICE candidates, to filter out those that are not TURN in order for iceTransportPolicy to do what it’s intended to do.
I am not sure, I have not tested it. This can be tested by creating an PoC HTML page that creates WebRTC object with “relay” policy and “accepts a call” with an IP address and see if connection is made to IP address listed as a relay candidate.
EDIT: I have tried to make a call between two web pages using iceTransportPolicy “relay” and trigger any packet to be sent to the IP of the relay offered by the other side and so far has not managed to do this. Also when I accept an offer from a client using TURN server example.net on a client using TURN server example.org, TURN server example.org has some traffic directly from/to the TURN server example.net, even before sending an answer.
I have found how this description was written:
Previous text said “This can be used to reduce leakage of IP addresses in certain use cases.”, then got expanded into this without much discussion. I’d not assume that much thought was put into it.
I have now searched if this problem of attacker injecting a custom TURN server was discussed and found this issue: WebRTC
In this scenario attacker injects a “relay” candidate with a hostname that has a DNS server controlled by an attacker and this hostname is resolved even before call is accepted. This was the issue in Signal in 2020 because they have a native WebRTC stack and the candidate was passed to WebRTC stack even before call was accepted. They patched it by removing the code that does DNS resolution, but it seems there was no filtering at least at that time if attacker could just send any hostname in the offer. In Delta Chat this is not possible because until you accept the call we do not even call setRemoteDescription, so the SDP offer sent by the other side is just a text in memory.
But from the discussion it seems it is not considered a problem that once the call is accepted and local SDP is set the IP address of the relay candidate offered by the caller is used. The only issue was that hostname was resolved before the call is accepted.
Originally IceTransportPolicy was called just “IceTransports”.
The commit adding it said only this:
If there is a mandatory constraint called “IceTransports” it will control which how the ICE engine can act. This can be used to limit the use to TURN candidates by a callee to avoid leaking location information prior to the call being accepted.
Does not look like anyone was concerned with hiding an IP address during the call.
“Revealing IP addresses” section does not say much, you can also read it as if nobody messes up with signalling and does not inject custom relay candidate, you will only have non-P2P connections and no IP addresses revealed to the other party. If you look how this section was written, there again was not much discussion: Security considerations section - second PR by alvestrand · Pull Request #194 · w3c/webrtc-pc · GitHub
The reason it was written was just to have a non-empty “Security Considerations” and once written nobody edited it, everyone is just OK the section was filled: 20806 – Section 15 (Security Considerations) is empty
In the Signal source code the variable that eventually gets set is called hideIp and has the description that says “if true hide caller’s IP by using a TURN server”:
I think this correctly describes what the setting “Always relay calls” does: if the caller has the setting enabled, caller IP address is not sent to the called side in the offer. But called side may still offer its own relay candidate and fail to connect to the caller candidate, then the call will be relayed over the called side I assume. Otherwise why SDP answer even contains candidates at all?
Thank you very much. 
I’m sorry I didn’t make my scenario clearer. I should have taken the time to respond more clearly and omit irrelevancies.
That makes good sense. I think there are already enough settings that chunking them is helpful. Like the way a bunch of them are labelled “Advanced” and hidden by default; that is good. That lets most users just think “not what I am looking for” and skim past.
Where settings can be conceptually simple, with implementation details hidden by default, I am very much in favour of it. Simple to understand=simple to use=useful.
Not going to correct my posts above to avoid editing too much. Summary is that in experiments with Chromium setting “relay” policy results in your relay being used as a proxy for outgoing connections, so IP is not revealed. I have however not found the confirmation for this in the specification. W3C spec is not really important, it links directly to RFC 9429: JavaScript Session Establishment Protocol (JSEP)
But I have not found where does any specification say whether you should connect to the other side candidates using your relay or one of your network interfaces directly. ICE Candidate Policy seems to be only about which candidates should be collected.
Good research!
I could be wrong, but I suspect that this could be implied by how ICE works. You gotta think not in terms of connections, but rather packets, with IP and port. When you send a packet to the other peer’s TURN candidate, you send it from some IP and port, and that IP and port is your local candidate. If the policy says that one must not collect non-relay candidates, then it means that you cannot send packets anywhere except your TURN server.
But again, I could be wrong.
Maybe this chapter could help us understand it Connecting | WebRTC for the Curious.
But anyways, I think that we can’t be responsible for the implementations of WebRTC. If the spec says that this config value is to hide your IP, then we should treat it like that. We shouldn’t be refraining for using it just because we haven’t conducted a security audit of Chromium.
At the very least our setting could say “Try not to reveal IP address” instead of promising that it will be hidden.
By the way I made a related feature proposal here which suggests one way to let users enjoy P2P realtime chat functionality over Tor, which I think has huge potential but seems maybe out of scope of the project currently.
I think it is unobjectionable to have a setting to disable calls the same way there is a setting to disable P2P realtime channels for webxdc. This would prevent accidentally tapping the screen for accepting a call by accident. (Also some people just don’t like to be called even if their not worried exposing their IP so it could also be useful for them).
If there is proper Tor proxy support for calls in the future with Arti or something that would be great but I guess we need to wait a bit for that.