Re: RFC: proxy support w/o target name resolution

[Henri Doreau <henri.doreau () gmail com>]

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
> bottleneck.
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
>         scanme.nmap.org/24
> 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

Regards

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