Home page logo

nmap-dev logo Nmap Development mailing list archives

Re: RFC: proxy support w/o target name resolution
From: Henri Doreau <henri.doreau () gmail com>
Date: Fri, 28 Dec 2012 14:04:45 +0100

Hi David,

[re-adding dev@ to recipients]

thanks for the suggestions. Some comments inline.

2012/12/24 David Fifield <david () bamsoftware com>:
On Fri, Dec 21, 2012 at 09:55:51PM +0100, Henri Doreau wrote:
I'm currently working on making nsock able to tunnel TCP connections
through chains of proxies. I have a working prototype[1] and would
like to discuss some points and the general roadmap here.

I chose the following, simple, approach to initially implement proxy support:
  - Caller first builds a proxy chain object from a string like
"http://localhost:8080,socks4://someproxy.example.com:1234";. This
object can be shared and reused between nsock pools.
  - Caller then associates this object to a nsock pool.
  - All TCP connections that are requested on this pool are
transparently relayed through the chain.

It works fine for HTTP connect and socks4 (though I'd like to stress
the fact that my implementation is experimental). A challenge I'm
facing is the addition of protocols that let you specify a target
hostname, so that you don't have to resolve its name locally
(typically: socks4a). This is essential when operating under
restricted network conditions.

First, I think we should merge and deploy what you have implemented so
far, even though it leaks DNS. Name resolution through a proxy is
trickier and I'm afraid to get stuck in it.

Sounds wise. I'll focus on making the existing code production ready
then. HTTP authentication support can also be postponed for now I
think. Let's validate the base layers first.

Hooking the nsock TCP connect function is convenient (because it's
totally transparent) but this function takes a struct sockaddr and not
a string as a target specification parameter. I see several options.
One is to change the prototype of the function to make it take a
string as parameter (which I sort of dislike). Another one is to build
a name resolution system within nsock, which would be helpful anyway,
and change its behavior on demand. According to what the proxy chain
looks like, it could replace actual name resolution by the generation
of a hash. This hash would be recognized as such by the TCP connect
function, that would then use the hostname instead when communicating
with the proxy.

On-demand name resolution through Nsock is probably better for
efficiency. Brandon had to invent a local DNS caching hack when we were
doing the favicon scans, because sequential name resolution was a huge

Ok, this would be a second step then.

We could invent a structure that is a subset of what Target holds.
Basically, a host name and an IP address. Either field could be omitted.
If we are doing all name resolution through a proxy, the IP address will
never be filled in; the host name is the only information we will give
the proxy. Then there can be convenience functions, one like the current
nsock_connect that takes a sockaddr, and another that takes a string
that is a host name (or string representation of an IP address).

Yes, I like this approach. If I understand correctly what you're
proposing, the target object should be defined and managed by the
caller, right? What about having a semi-opaque nsock_target object
that would be passed to the library (à la nsock_iod)? I'd find this
nicer. Any pro/con?

There are some difficulties. We want to eventually replace the connect
scan with one implemented using Nsock. If I want to scan
it isn't possible without resolving the address. If we're in a strict
"proxy resolves" mode, then we have to show an error in this case. If
we're in a "just make my scan work" mode, we might choose to resolve the
address locally and then feed the 256 IP addresses to the proxy.

Indeed, these aren't trivial tasks but I see no blocker at least. How
to use different proxy chains (to balance the load or for resiliency)
is also challenging and undefined yet.

David Fifield


Sent through the dev mailing list
Archived at http://seclists.org/nmap-dev/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]