Re: [tor-dev] design for a Tor router without anonymity compromises

[coderman <coderman@xxxxxxxxx>]

On 5/3/15, warms0x <warms0x@xxxxxxxxxx> wrote:
> ...
> I am bored so I figured I would read this big document, here are some
> comments from somebody who took the time to care:

thanks! :)



> 1.3 > Warning conditions:
>
> Is the "Client privacy leak detected" meaning the software would warn
> in the case of a LAN client attempting to make an unsecured connection
> or leak DNS data or somteihng like that?

correct. the client is filtering locally, and only expecting Tor
Browser traffic to egress. if anything else is sent, not through Tor
relays, it is dropped and warned about.



> Provided the leak never makes
> it off the routing device, then I think that is an acceptable warning

correct. this leak traffic is dropped, then warned about.



> 2.4 > Device software and configuration technical requirements
>
> "Require VPN on local WiFi and Ethernet network " does this mean VPN
> connection to the router itself, as in establishing an IPSec tunnel
> from LAN_1 --> [Router] before any layer four traffic is allowed? I see
> the FAQ about Wifi, which makes sense, but extending the VPN
> requirement to the physical network I find odd.

this is for three purposes.
 1. WiFi is inherently insecure, per the RC4 defect.
 2. if using open WiFi (no WPA-2 Enterprise EAP-TLS, nor any lesser
privacy setting) you avoid TCP and other injection DoS attacks.
 3. the privacy director is better able to transition between Public
networks / Tor enforcing network if the VPN up is used as successful
signal of pairing to expected router. Otherwise un-authenticated
details like IP, MAC, hostname provide only tentative indication of
Tor enforcing router upstream.



> I suggest also adding mandatory audit logging to the scope of the
> router software. In my opinion any and all state changes, whether
> automatic (Tor circuit change) or manual (administrator changing
> configuration) must be logged.

this is an important detail; thank you for bringing it up. i will add
the expected run logging and troubleshooting logging output collected
on device and available to the owner via privacy director
administrative access.



> 2.5/2.6 > Privacy Directory Requirements
>
> Is the expectation that every client attached to the router would be
> running this privacy directory software or only the router
> administrator(s)? In the former case, is there any bad exit indication
> that could/would be made to the clients?

only the owner is required to run this software. it is recommended
that other users on the Local network also run it, for the additional
support it provides keeping Tor Browser current and handling local
egress filtering when on a Tor enforcing network.

bad exit reporting requires the privacy director software, either as
owner or normal user. there is no way to report bad exits through
captive portal web UI on device.



> How is authentication and authorization of this privacy director
> software going to be performed with the router? In 1.2 the router would
> be passwordlessly set up, but after that how would an administrator
> ensure that only they are able to mutate the device set up?

as device owner, the first time setup, which requires directly
connecting to the device, provides key exchange for the remainder of
administrative activities.

if you're not owner of the owner keys, you don't get to perform any
administrative actions on the device.



> Also "Filter local traffic that is not Tor when active", does this mean
> that the privacy director software will require escalated privileges on
> the numerous platforms into order to modify local firewall states?

yes to modify firewall state.

it is possible to run without elevated privileges, however, filtering
traffic and disabling services cannot be performed and some automatic
behaviors become manual (e.g. auto detecting transition on or off of a
Tor enforcing network does not work in some scenarios, and the privacy
director menu must be used to explicitly update view.)

it is possible to constrain the delegation of these privileges, like
sudo for calling hooks around network changes, however this is
currently outside scope given the poor state of client side security
posture overall.



> Interesting effort, good luck

thanks for the feedback! we'll need the luck...


best regards,
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev