[tor-talk] orWall 1.0.0 released!

CJ tor at tengu.ch
Sat Oct 4 06:50:20 UTC 2014


On 04/10/14 00:27, Mike Perry wrote:
> CJ:
>> Hello!
>>
>> just a small update regarding orWall: it's released 1.0.0!
>> There's still *one* annoying issue regarding the tethering, but it
>> should be OK next week. Just have to take some time in order to debug
>> this for good.
>>
>> orWall provides now a brand new UI in order to be easier to handle.
>> There's also an integrated help (as a first-start wizard we might call
>> later on).
>> There are many new features and improvements, like:
>>
>> - ability to disable all rules and let the device access freely the Net
>> - for each app, the possibility to access some advanced settings
>> allowing to bypass Tor, or tell orWall the app knows about proxies or Tor
>> - better management for the init-script
>> - better management for iptables rules
>> - translations in French, German and Italian are almost done
> 
> Hey CJ, just wanted to let you know that I've tried OrWall and it's a
> huge improvement! Way better user experience on just about every front!
> 

\o/ I'm really glad I could do something more userfriendly

> I also have not detected any leaks on my upstream router, either.

thanks to the init-script and a better iptables management ;). DROP
policy is just the key.

> 
> When I get a chance, I will update the original blog post to recommend
> OrWall instead of my crazy Droidwall hack scripts.

Wow… Thank you!

>  
>> Any feedback from Tor/Orbot users interest me in order to improve
>> orWall. I think the current release is pretty good, but as the main dev
>> I'm maybe not that neutral regarding this statement ;).
> 
> The one thing is that I find the long-press options for "Connectype
> type" confusing: 
> 
>  - "Force connection" to what? I assume through Tor's transproxy because
>     of the REDIRECT text, but this will not be clear to users who are
>     unfamiliar with iptables.
>     How about: "Redirect all network activity"

hmmm yes. Why not, I think it's a sentence people will understand indeed

> 
>  - What does "native capacity"/"fenced path" mean? Does that mean only
>    access to the local SOCKS/HTTP proxy ports in Tor's case?
>    How about: "Only allow local proxy port access"
> 

Same thing. As this box allow all local connections (no port filtered
for now, I'll maybe add it later), text will be correct.

> These are complicated ideas to convey, though. I'm not sure my
> suggestions are the best ones either.
> 

True :/. It's a bit explained in the wizard though. But I think the
wizard might be worked out a bit more, it's painfully long and full of text.

> 
> I also suggest soliciting input about the DNS issue we discussed where
> DNS queries are done by root on Android 4.3+ unless the
> 'ANDROID_DNS_MODE=local' environment variable is set. Perhaps someone
> will come up with a clever hack to set this env var in a persistent way
> that we haven't thought of, or find some way to write a shim on the DNS
> resolution filesystem socket to enforce what we want.

yup. This part is hard, and I don't think I'll be able to find a
solution alone. I'll open an issue on the github tracker and place a big
"help wanted" in it :).

> 
> You could list this on a known issues or FAQ page, or in your bugtracker
> I guess. Making root/UID 0 handle DNS is also a security risk, and I'm
> very surprised the Android team thought this was a good idea. :/

Oh, well, they also decided to follow Oracle JVM Cipher list, you know…
Nothing surprises me now ;).

> 
> 
> Also looking forward to the "Logs" window doing something :)

Same for me. This part will be complicated due to different kernel
capabilities:
some supports LOG target, other NFLOG, and the latter doesn't provide
any nflog reader in the ROM (heya, Cyanogenmod, you're brain-dead on this!).
Thus it means:
- detecting which kind of log is supported
- create some UI in order to activate logs (already have some ideas)
- inject some binary in the system for nflog support
- … and many other things.

Maybe this can be avoided, as AFWall+ is considering providing some
intents as API end-points. This would mean:
- install orWall
- install AFWall+
and you'll get the best of both worlds, as AFWall will take care of the
iptables and log interfaces, just executing orWall orders…

Thanks for your feedback!

Cheers,

C.

> 
> 
> 
> 
> 


More information about the tor-talk mailing list