Nmap Development mailing list archives
[RFC] Redoing Ncat's Proxy Options
From: Kris Katterjohn <katterjohn () gmail com>
Date: Thu, 09 Oct 2008 21:36:58 -0500
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey everyone, Ncat currently has --socks4-proxy and --http-proxy for connecting through a proxy, and --http-server to act like a proxy. In the future there will probably be a working SOCKS server option, with both SOCKS proxy options supporting SOCKS5. Having: --http-proxy --http-server --socks4-proxy --socks4-server --socks5-proxy --socks5-server seems lame to me. Of course, the different versioned SOCKS options could be combined with a "4" or "5" flag or some such, but still: having these all separate isn't strictly necessary. Before the release of Ncat with Nmap (where option names really start to solidify), what do you guys think of moving in a direction like OpenBSD Netcat with their -x and -X options, with -x specifying the address/port and -X specifying the protocol like "4" for SOCKS4, etc? I'm not formally suggesting we use "-x" and "-X", just having more generic options for these. Also note another thing about using these is that the same option (be it -X or whatever) can be used for the proxy servers as well. So instead of having both --http-server and --http-proxy, we can just use "-X http" (or "connect" like OpenBSD Netcat) in both cases. So: * Is moving in this direction a good idea? I'm very much for it. * If so, what option names should be used? I'm OK with -x and -X, but what do you guys like? * Should the -X equivalent option default to anything? OpenBSD Netcat defaults to SOCKS5. * Instead of -X taking "4" (SOCKS4), "5" (SOCKS5) and "connect" (HTTP CONNECT) like OpenBSD Netcat does, I think just using "socks4", "socks5" and "http" is better. However, I'm not super-set either way. Opinions? * What about the proxy authentication option (currently --proxy-auth)? I would like this to be similar to the names of the other proxy options, but using -x and -X would throw that out the window (OpenBSD Netcat uses -P). One possibility is to just drop this option and allowing for "user@socksproxy" and "user:pass@httpproxy" syntax in the -x equivalent option, but I'm not 100% behind that one. Aside from using just -x, -X and --proxy-auth, here is the first set of options that came to my mind: --proxy addr[:port] --proxy-type {socks4|socks5|http} --proxy-auth {user|user:pass} With or without -x/-X being synonymous with --proxy and --proxy-type. The current proxy options are all long-names, so keeping it that way won't hurt anything... but having short options is nice at times. Thanks!, Kris Katterjohn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSO6/xv9K37xXYl36AQI0hA//VQjq+3d0hIhj+fMbWIP4m0/pX+4M0Aap gvJzkpd2JvLlfd/7ehLaVw3AHVRwwrtwljmYf2mljLRgH1G4LQGOsAstG3nwWX1Q 44l4IwNlJOtkDL17QdDr11gtR99PRLqdA1HaBXNjKXjf3oix1griw7my+y9+Uqmd TywmRxw7lhLLUmTLnQ/ugxLhNiwZB+6Rv0oFQb7IWhZKFCDZ1wg5I6J7Srx3Pxm/ CR6QgSTjbQEPTzSoV/Q2pRw6bF1CwBOocDorrbZrHLrDhzcLE8BBKM+Lut9dg3+D ReMCLbbwmw85bFqoAdx37WJnOwvLgsegOphy2wMRimk6EWrzBTcNSltMU7F/girF BE/dc+r/YxMhy8OAIEcf5d9dmQ96U8aewDP5e4tWxjzUwiWRvVwjzF6J8SyhhMaX EY6Idp4IerEbAjZ5CP18QaU+PHAl7/FfiEwkRWJFsev68a2tW0yn4PdEPnqofVTJ nD8zD16Ui/a7brqRiUe9qY7iewdB36MQ7kk2r3tMcMtgpLUSVRKb1ri9NaGrzvTv gIndcrrEGc/p814Iq5jN6usInWcignlPyvbj6447G6ma++qDF+MEyja4b2IQ5jXs z28rcrCzRPlC6seTO4w/RuABUEO4OmppQgJSpfJK1hP85wGDNc0B1cVtvDNZon60 /rOhYDStEVI= =Yult -----END PGP SIGNATURE----- _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://SecLists.Org
Current thread:
- [RFC] Redoing Ncat's Proxy Options Kris Katterjohn (Oct 09)
- Re: [RFC] Redoing Ncat's Proxy Options jah (Oct 10)
- Re: [RFC] Redoing Ncat's Proxy Options Kris Katterjohn (Oct 10)
- Re: [RFC] Redoing Ncat's Proxy Options Dirk Loss (Oct 10)
- Re: [RFC] Redoing Ncat's Proxy Options Kris Katterjohn (Oct 10)
- Re: [RFC] Redoing Ncat's Proxy Options Kris Katterjohn (Oct 10)
- Re: [RFC] Redoing Ncat's Proxy Options Kris Katterjohn (Oct 12)
- Re: [RFC] Redoing Ncat's Proxy Options jah (Oct 10)