RFC: proxy support w/o target name resolution

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

Hello,

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.

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.

My roadmap for this exciting project will depend on these choices. I
could also imagine making the current system production ready first
and merge it before working on more complex points.

Feedback and suggestions are very welcome!

Regards


[1] https://svn.nmap.org/nmap-exp/henri/nmap-proxies

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