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
0x9FC527CC.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org