Using Tor with socks5 leaks un-anonymized traffic in several situations

[missytake]

Under Linux, there is the use case of using the experimental socks5 proxy support to tunnel Delta Chat traffic through the tor daemon, thereby anonymizing the IP address while using Delta Chat. (For an example use case, see this guide: https://lefherz.net/2022/08/28/how-to-setup-delta-chat-on-tails-in-4-steps/ )

Unfortunately, the socks5 support is still experimental, and was never audited. So far, it seems there are several situations in which the IP address is leaked to different parties in the network. None of them are a severe issue and can be easily used to de-anonymize the user, but in combination with other data de-anonymization could happen. The socks5 support is experimental and comes with a warning:

Still, this situation needs to be improved to protect Delta Chat users. Let's use this issue to collect cases in which the IP address can get leaked, and to fix them.

1. One of them is already described in the warning - during onboarding, there is an unencrypted DNS MX lookup whether the domain's MX entry belongs to Google Workspaces. This tells a potential network attacker and the DNS server that this IP address plans to use an email address at this certain domain. The DNS server could compile a list of IP addresses which asked for this MX entry, substract IP addresses which are obviously mail servers and just need the MX entry for relaying emails, and have a list of IP addresses using this specific mail domain with Delta Chat. For mail domains with only one or few users, and with additional information about the Delta Chat usage of the target, this can leak the IP address of the target to the attacker.
2. HTTP traffic is not tunneled through socks5 yet, as https://github.com/async-email/async-native-tls doesn't support this (I don't know why). Delta Chat opens HTTP(S) connections in several situations: 2.1 during onboarding, if the mail domain of the user is not in the provider database, the autoconfig XML is requested over HTTPS to find out server configuration. This can leak the IP address of the target to the mail server. This information on its own does not suffice to identify the user account connected to this IP address, but correlating it with SMTP/IMAP authentication logs could achieve that, depending on how many other users the email server has. 2.2 when using the location tracking feature, mapbox tiles are downloaded over HTTPS to display the location of chat partners on a map. This can leak the IP address of the sender and/or recipient of the location message to mapbox.com, if they view the location map. mapbox.com could connect this information with the requested location (they don't see the exact coordinates, but which area was requested). On its own this is not very interesting data, but combined with other information it could also lead to localization or de-anonymization of targets.

There are potential other situations in which the IP address could leak, as this was never looked at with a holistic view, nor tested with wireshark. Automated tests would be useful to test against this problem in the future.

On Tails I suppose this problem would not appear, as Tails blocks every network traffic not going through the socks5 proxy, at least if the "unsafe browser" feature is not enabled. I did not test that though.

---

• Operating System (Linux/Mac/Windows/iOS/Android): Linux
• Delta Chat Version: 1.32.0
• Expected behavior: when using a socks5 proxy, all traffic is tunneled through the socks5 proxy
• Actual behavior: DNS and HTTP(S) traffic is sent over the normal network connection, without the proxy.
• Steps to reproduce the problem:
  • (capture traffic with wireshark or so)
  • Login to an account with Delta Chat
  • Enable location tracking
  • receive a location by someone else, look at it on the map
  • (check wireshark whether the traffic was sent over proxy or not)

[missytake]

Regarding 1., it seems that this DNS lookup is skipped if socks5 is enabled:

• https://github.com/deltachat/deltachat-core-rust/blob/4615c84f310ef53d2919e3de18cb8cf909e6d959/deltachat-ffi/src/lib.rs#L4202-4219 checks if socks5 is enabled and passes it to:
• https://github.com/deltachat/deltachat-core-rust/blob/master/src/provider.rs#L116, which skips the MX lookup.

So it seems to avoid this check the user needs to enable socks5 before typing the email address into the login form?

related discussion: https://github.com/deltachat/deltachat-desktop/pull/2355#issuecomment-917420191

[missytake]

Regarding 2.1, it seems that the autoconfig lookup is also skipped if socks5 is enabled:

• https://github.com/deltachat/deltachat-core-rust/blob/7a47c9e38bb8d25601b21765439edd0dba6c5518/src/configure.rs#L267-274 checks if socks5 is enabled and skips autoconfig if yes.

But as with the MX record lookup during configuration, if the user doesn't enable socks5 before typing the email address into the login form, the autoconfig HTTPS request happens.

Related PR: https://github.com/deltachat/deltachat-core-rust/pull/2474

This is the function which needs socks5 proxy support: https://github.com/deltachat/deltachat-core-rust/blob/7a47c9e38bb8d25601b21765439edd0dba6c5518/src/configure/read_url.rs#L18 I'm not deep into rust, so maybe I'm overlooking something, but I don't see a reason why this lookup can't be enhanced with proxy support.

[Simon-Laux]

is this still an issue in 1.34.4?

[missytake]

issue 1 needs more discussion if this is worth to worsen the onboarding UX - I tend to say "no", and would rather approach this issue with a general FAQ entry recommending best practices for tor users.

issue 2.1 seems to be fixed in https://github.com/deltachat/deltachat-core-rust/commit/fa198c3b5e5e543f9ac6d78a495bc2250da8c2d9, but I didn't test it yet.

Regarding issue 2.2, I didn't look yet where in the code the issue appears - do the mapbox requests happen in the core or in deltachat-desktop? If they are in the core, the fix for 2.1 might have fixed it as well.

[farooqkz]

mapbox requests seem to happen in the desktop using mapbox-gl. I would suggest some solution to proxy ALL electron traffics through the SOCKS5 proxy. What do you think? @Simon-Laux @link2xt @missytake

[Simon-Laux]

core has a function to do http requests (get_http_response in jsonrpc api) that respects socks proxy settings. The "real" solution would be to replace mapbox with leaflet and then use get_http_response from the jsonrpc to get the map tiles for leaflet, possible also cache them with pouchDB or sth like that. Then we could block all electron triggered requests (we currently whitelist mapbox).

But replacing mapbox with leaflet is a bigger effort.

[farooqkz]

@Simon-Laux How replacing mapbox with leaflet helps here?

[Simon-Laux]

@Simon-Laux How replacing mapbox with leaflet helps here?

less nodes dependencies is good in general and in leaflet we can easily make it fetch tiles over core. maybe map box too has too has an option for it too but we want to switch to leaflet anyway.

[r10s]

note, that there is a already a basic leaflet webxdc implementation on ios, it is not yet merged, however, i'd say we wait on desktop until that is done and consider moving away from mapbox then (maybe sth. for autumn) (i just explained things a little bit more at https://github.com/deltachat/deltachat-ios/pull/1912 )