Custom obfs4 bridge does not work on Tor Browser for Android
We got a report on our blog post (https://blog.torproject.org/comment/282217#comment-282217) mentioning that custom obfs4 bridges don't work on Android while they do on desktop. I tested with a bridge provided and can reproduce the issue.
Activity
Trac:
Parent Ticket: #31284 (moved)
Trac:
Parent: N/A to #31284 (moved)
Sponsor: N/A to Sponsor30-canNotice the missing ClientTransportPlugin line for obfs4proxy.
generic_x86:/ # cat /data/data/org.torproject.torbrowser_alpha/app_torservice/torrc AutomapHostsOnResolve 1 ControlPortWriteToFile /data/user/0/org.torproject.torbrowser_alpha/app_torservice/lib/tor/control.txt ControlPort auto CookieAuthentication 1 CookieAuthFile /data/user/0/org.torproject.torbrowser_alpha/app_torservice/lib/tor/control_auth_cookie DisableNetwork 1 DNSPort 5400 HTTPTunnelPort 8218 ReducedConnectionPadding 1 RunAsDaemon 1 SafeSocks 0 SOCKSPort 9150 KeepAliveIsolateSOCKSAuth IPv6Traffic PreferIPv6 StrictNodes 0 TestSocks 0 TransPort 9140 VirtualAddrNetwork 10.192.0.0/10 Bridge obfs4 123.234.345.456:3322 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA cert=asdfasdf UseBridges 1It's because we only add the ClientTransportPlugin line for the default bridges.
Trac:
Cc: phw, cohosh, arma to phw, cohosh, arma, sisbell
Keywords: TorBrowserTeam201906 deleted, TorBrowserTeam201909 added
Replying to sysrqb:
It's because we only add the ClientTransportPlugin line for the default bridges.
In theory you should be able to put all the ClientTransportPlugin lines in there by default, even when there are no bridges set, and Tor won't launch any of them until it has a bridge that needs them.
Replying to arma:
In theory you should be able to put all the ClientTransportPlugin lines in there by default, even when there are no bridges set, and Tor won't launch any of them until it has a bridge that needs them.
FWIW, Tor Browser on desktop has used this approach ever since we switched to Tor Launcher (i.e., for a long time now). The following gets appended to the
torrc-defaultsfile which is always loaded by TB desktop's tor:I fixed this as part of fixing the bridge list. I took the approach suggested by arma, the plugin transport is added regardless of whether user specifies a bridge. This is a much cleaner approach.I added some unit tests for verify behavior.
https://github.com/sisbell/Tor_Onion_Proxy_Library/commit/ac9ad2295b3dcb312a9aff4f3f7b27343bc4b73d
Trac:
Status: new to needs_review
Keywords: TorBrowserTeam201910 deleted, TorBrowserTeam201910R addedThis is a very tight fix, only addressing the obfs4 bug and a couple of bridge bugs. No change required for tor-android-service since the API hasn't changed. This commit does not address all issues we have with settings.
Changes
- Break apart the setting of transports and bridges. Transports will be set independent of whether user has configured bridges.
- Removed shuffle of bridges (addresses previous review comment)
- Removed max limit on number of bridges (addresses previous review comment)
https://github.com/sisbell/Tor_Onion_Proxy_Library/commit/39f6aad9257947d7c47181e04963857284a67a44
Looks pretty good.
+ @SettingsConfig + public TorConfigBuilder bridgesFromSettings() { + List<String> supportedBridges = settings.getListOfSupportedBridges(); + if (supportedBridges == null || supportedBridges.isEmpty()) { + return this; + } + String type = supportedBridges.contains("meek") ? "meek_lite" : "obfs4";Do we still use both? obfs4 now has support for meek, so I assume we simply can do the same. As an example, I have this in my Tor Browser torrc:
ClientTransportPlugin meek_lite,obfs2,obfs3,obfs4,scramblesuit exec ./TorBrowser/Tor/PluggableTransports/obfs4proxy
- if(hasAddedBridge) useBridges();I don't see any other
useBridges()calls, do we need an unconditional call now?Trac:
Keywords: TorBrowserTeam201911R deleted, TorBrowserTeam201911 added
Status: needs_review to needs_revisionReplying to sysrqb:
Looks pretty good.
+ @SettingsConfig + public TorConfigBuilder bridgesFromSettings() { + List<String> supportedBridges = settings.getListOfSupportedBridges(); + if (supportedBridges == null || supportedBridges.isEmpty()) { + return this; + } + String type = supportedBridges.contains("meek") ? "meek_lite" : "obfs4"; }}}This is done to filter out obfs4 bridges is meek is asked for but based on your information, I don't think we need a filter.
Do we still use both? obfs4 now has support for meek, so I assume we simply can do the same. As an example, I have this in my Tor Browser torrc: {{{ ClientTransportPlugin meek_lite,obfs2,obfs3,obfs4,scramblesuit exec ./TorBrowser/Tor/PluggableTransports/obfs4proxy }}}
{{{
-
if(hasAddedBridge) useBridges();
}}} I don't see any other
useBridges()calls, do we need an unconditional call now? I looked through the bridge settings code. Since UseBridges is 0 by default, the following methods needs to be changed to write bridges if enabled.{{{ @SettingsConfig public TorConfigBuilder useBridgesFromSettings() { return !settings.hasBridges() ? dontUseBridges() : this; }
to@SettingsConfig public TorConfigBuilder useBridgesFromSettings() { return settings.hasBridges() ? useBridges() : this; }There is one other use of useBridges, but I believe I can remove that as well. This MAY cause a problem with Orbot configuration but that can be resolved later as we clean up the code. I'll make a couple of changes and make a new commit.-
