Transparant TOR .onion support.

[mateli]

This is a lightweight suggestion compared to the SOCKS support issue.

When an server address ends in ".onion" then use the orbot SOCKS proxy if it's available.

No confirmation is required. If Orbot is detected and the root domain is .onion then just use TOR. Otherwise don't. If both are true then it's safe to assume that the user wants to use TOR. In fact checking for Orbot may be a bit redundant. Failing to connect to it when there is a .onion domain would indicate to the user that an action is required.

And also if possible detect transparant VPN mode. If we already use TOR through that we don't want to nest the connection.

I know that for HTML mail there may be a problem with privacy. The quick and dirty solution for this is to disable HTML mail on accounts that use .onion servers.

As Orbot already has transparant proxying there is no need to have an option that routes everything through TOR. What we need is selective routing of .onion domains only.

[philipwhiuk]

(Accidentally clicked close)

The quick and dirty solution for this is to disable HTML mail on accounts that use .onion servers.

See #906 for why this is itself a complex thing.

This is a lightweight suggestion compared to the SOCKS support issue. When an server address ends in ".onion" then use the orbot SOCKS proxy if it's available.

It's not really. The hard part is refactoring and testing our connections to use proxies. Not the UI bit.

As far as I'm concerned this still depends on #980

Also, enabling just Orbot just for onion domains means leaking everything else. It's not only ugly it's potentially insecure and Tor email's use case is stuff like whistleblowing. I don't want to do it badly and claim support.

And also if possible detect transparant VPN mode. If we already use TOR through that we don't want to nest the connection.

I have no idea if this is even possible.

[gdt]

Another use case for email and Tor is getting around firewalls. I'm not doing that for mail right now, but I do use jabber to hidden services, not to hide, but to be able to function on for-the-public wifi nets whose admins think they should block ports they don't understand. So no argument about the proxy dependence or about the issue of halfway approaches having danger, but "there is no need for tor until it's good enough for whistleblowing" isn't quite right.

[mateli]

Considering the above comments I suggest the following which is a quick and dirty fix. Add the possibility to install a second instance of K9 that runs in parallel and then one can make that app subject to Orbot's VPN. That will protect all traffic within that app. No need to support SOCKS or any other proxy.

A "K9 secondary email" app in Google play would solve this problem for me. I could do this myself but keeping it updated would be a problem. It is better if this is integrated into the upstream release routine.

Creating a "K9 email 4 TOR" that on startup checks verifies that Orbot is runnig by connecting to an .onion-domain and on failure refuse to start with an error message would solve this problem with security. The error message should just instruct the user to enable Orbot VPN for the application. The standard variant of K9 would then still be unaffected.

The quick and dirty solution for this is to disable HTML mail on accounts that use .onion servers.
See #906 for why this is itself a complex thing.

I figured out that I can fix this server side by having the server reject HTML email.

This is a lightweight suggestion compared to the SOCKS support issue. When an server address ends in ".onion" then use the orbot SOCKS proxy if it's available.

It's not really. The hard part is refactoring and testing our connections to use proxies. Not the UI bit.
If the existing network library supports SOCKS it should be a matter of a few lines of code. If not it's a matter of using another library and a few lines of code.

As far as I'm concerned this still depends on #980

I don't see that. The issues are overlapping but both contains features not needed by others.

Also, enabling just Orbot just for onion domains means leaking everything else. It's not only ugly it's potentially insecure and Tor email's use case is stuff like whistleblowing. I don't want to do it badly and claim support.

Tor exit nodes are far far worse than this. So no I can't t agree to that. Also if the server is on a local IP which several of my servers are, routing them trough exit nodes will fail.

And also if possible detect transparant VPN mode. If we already use TOR through that we don't want to nest the connection.

I have no idea if this is even possible.

Trying to open an existing .onion domain trough Android would not fail if Onion VPN is redirecting all of K9:s traffic.

[cketti]

The automatic .onion support via Orbot suggested here sounds like it could cause more confusion than the user either configuring Orbot for transparent proxying or manually entering Orbot as SOCKS proxy (once we have that feature).

Please feel free to implement any "quick and dirty" solutions in your own fork of K-9 Mail.

[mateli]

The quick and dirty solutions to this is insecure transparent proxying or the confusing demand to redundantly set socks proxy for each end every .onion domain used.

I don't see how supporting TOR by automatic routing TOR domains trough the TOR router would be confusing. The confusing is for .onion domains to not work.

This is the second time I had a useful future that closed with nonsensical reasons so yes I will create a more secure and useful fork of this project. The other problem was fixed because a flood of other users put pressure on fixing it, now allowing users to accept invalid SSL/TLS certificates. That but by the way was something that's required for .onion support as there are no valid SSL/TLS for .onion domains.

Now I am going to go trough all the closed issues for other things that you have arrogantly dismissed, fix them in a fork and then market it heavily. I really had other projects was ahead of this in my priority queue but I'll insert it third to the top.