Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LAN and Tor #958

Open
abidal3 opened this issue Mar 9, 2019 · 23 comments
Open

LAN and Tor #958

abidal3 opened this issue Mar 9, 2019 · 23 comments
Labels

Comments

@abidal3
Copy link

abidal3 commented Mar 9, 2019

Please separate LAN/VPN and Tor control for apps.
If LAN/VPN and Tor is allowed for app and Orbot is down then no access to devices over LAN/VPN.

@Jookia
Copy link
Contributor

Jookia commented Mar 20, 2019

This is intentional so Tor won't leak traffic from/to your local network.
Every Tor application I've used denies access to your local network.
Is there a use case where this should be changed?

@abidal3
Copy link
Author

abidal3 commented Mar 26, 2019

This is intentional so Tor won't leak traffic from/to your local network.

But the same can be said for VPN. But all remained still for VPN interface.
Earlier the checkboxes for all network interfaces have been divided.
Why invent other behavior?

@Jookia
Copy link
Contributor

Jookia commented Mar 26, 2019

It is inconsistent, yes. I did it this way is because I don't know much about Android GUI design and didn't want to over complicate the feature addition.

@abidal3
Copy link
Author

abidal3 commented Mar 27, 2019

It is inconsistent, yes

This behavior needs to change.
Let each checkbox control its network interface separately.

@Jookia
Copy link
Contributor

Jookia commented Mar 27, 2019

How would the user indicate they want all traffic to be Torified?

@abidal3
Copy link
Author

abidal3 commented Mar 27, 2019

How would the user indicate they want all traffic to be Torified?

If only Tor checkbox is enabled then traffic goes only through Tor. Just like with VPN.
If Tor and other chechboxes are enabled then traffic goes through Tor when Tor client is enabled or through other active enabled network interfaces when Tor client is disabled.

@Jookia
Copy link
Contributor

Jookia commented Mar 27, 2019

How do we tell if the Tor client is enabled or disabled?

@abidal3
Copy link
Author

abidal3 commented Mar 27, 2019

How do we tell if the Tor client is enabled or disabled?

Add the option to define Tor client address.
By default 127.0.0.1:9040 or 127.0.0.1:9050.

@Jookia
Copy link
Contributor

Jookia commented Mar 27, 2019

Does Orbot give a notification?

@abidal3
Copy link
Author

abidal3 commented Mar 27, 2019

Does Orbot give a notification?

Why get attached to Orbot?
Tor client may be a binary file tor.
The main thing is a binding address of tor client.

@Jookia
Copy link
Contributor

Jookia commented Mar 27, 2019

AFWall has to get notified that Tor is up or down from somewhere.

@abidal3
Copy link
Author

abidal3 commented Mar 27, 2019

AFWall has to get notified that Tor is up or down from somewhere

By checking the binding address.

@Jookia
Copy link
Contributor

Jookia commented Mar 27, 2019

How often will it do this? Will it wake the device up?

@abidal3
Copy link
Author

abidal3 commented Mar 27, 2019

Also add option to define timeout in seconds.

@abidal3
Copy link
Author

abidal3 commented Mar 27, 2019

But unless Orbot is checked for running status now?

@Jookia
Copy link
Contributor

Jookia commented Mar 27, 2019

I don't know enough Android programming to implement this feature.

@abidal3
Copy link
Author

abidal3 commented Mar 27, 2019

You don't have to add a new checking necessary.
How is it checked now?
For now you'll just separate checkboxes.

@Jookia
Copy link
Contributor

Jookia commented Mar 27, 2019

It's not checked.

@abidal3
Copy link
Author

abidal3 commented Mar 27, 2019

Then don't check anything :)
If only Tor checkbox is enabled then traffic goes only through Tor.

@Jookia
Copy link
Contributor

Jookia commented Mar 27, 2019

But then won't that mean if you check LAN and Tor, traffic won't be redirected to Tor?
That sounds dangerous if you expect the Tor checkbox to always redirect.

Ignoring the Tor checkbox, AFWall lists destinations that traffic can go.
Destinations checked are allowed through, destinations unchecked are blocked.
The Tor checkbox redirects the allowed traffic.
So right now you would let an application go through WiFi and Tor to have it Tor traffic on WiFi and block everything else.

Changing this so that if Tor isn't running the application will mean people's firewalls will now open if Tor is disabled rather than block connections.
Adding an option in the settings to let traffic through when Tor is down would work and preserve existing behavior.

For extra safety I'd like this to somehow be tied to how Orbot is configured- not just if Tor is down but whether it's disabled or enabled. That way if a bad guy somehow kills Tor connections it won't bypass while Orbot is reconnecting.

@ukanth: Any thoughts? I could be up for implementing this.

@abidal3
Copy link
Author

abidal3 commented Mar 27, 2019

But then won't that mean if you check LAN and Tor, traffic won't be redirected to Tor?

Well.
If Tor checkbox is enabled then traffic is redirected to Tor always.
Until you can add the necessary checks.

@abidal3
Copy link
Author

abidal3 commented Mar 27, 2019

Now we have to check a few checkboxes for Tor. And if Tor checkbox was disabled then we can forget to remove other checkboxes and traffic redirects through other network interfaces. This is dangerous too.

@abidal3
Copy link
Author

abidal3 commented Mar 27, 2019

That way if a bad guy somehow kills Tor connections it won't bypass while Orbot is reconnecting.

The same can be said about VPN too. But if VPN is reconnecting and other network interfaces are enabled for app then app traffic would be redirected to other enabled network interfaces.

@ukanth ukanth added the Review label Mar 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants