[guardian-dev] supporting SOCKS on Android via a custom SocketFactory

Michael Rogers michael at briarproject.org
Wed Mar 22 10:40:03 EDT 2017


On 22/03/17 12:54, Nathan of Guardian wrote:
> On Wed, Mar 22, 2017, at 08:23 AM, Michael Rogers wrote:
>> Following up on an old thread to let you know that unfortunately the
>> approach we found for getting OkHttp to use a SOCKS proxy isn't safe. In
>> some cases OkHttp will try to resolve hostnames locally before creating
>> sockets, which leaks DNS lookups to the local network. Cure53 found this
>> in their recent audit of Briar. I'm currently trying to work out how big
>> a change is required to fix this.
> 
> Do we need to implement or fork our own HTTP library to ensure safety?
> Or is it just OkHttp itself that is the problem? I think Apache
> HTTPClient is better, possibly Volley, as well?

The problem is that we worked around the lack of proper SOCKS support at
the OS level by passing a custom socket factory to OkHttp - the socket
factory implements SOCKS, but OkHttp doesn't know that.

When OkHttp doesn't think it's behind a SOCKS proxy it does local name
resolution so it can make one connection attempt per address if there
are multiple addresses for a name. It passes the resolved name/address
pairs into the socket factory.

Fortunately, we can configure OkHttp to use a custom DNS resolver as
well as a custom socket factory. This allows us to capture the local
name lookups. If we return 0.0.0.0 as the address, OkHttp passes it
through to the socket factory where we can discard the fake address and
do the real name resolution via Tor.

This fixes the bug, but it's kind of brittle. To make it more robust we
can check that any name/address pairs passed into the socket factory
have 0.0.0.0 as the address. Even better would be some kind of OS-level
regression test that checks that no name lookups have escaped the
device, but that seems like a pretty big task.

Cheers,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x9FC527CC.asc
Type: application/pgp-keys
Size: 4660 bytes
Desc: not available
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20170322/92c9217b/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20170322/92c9217b/attachment-0001.sig>


More information about the guardian-dev mailing list