Nmap Development mailing list archives
Re: [RFC] Redoing Ncat's Proxy Options
From: Kris Katterjohn <katterjohn () gmail com>
Date: Fri, 10 Oct 2008 13:40:29 -0500
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/10/2008 09:24 AM, jah wrote:
On 10/10/2008 03:36, Kris Katterjohn wrote:* Is moving in this direction a good idea? I'm very much for it.I think so too.
Great.
* If so, what option names should be used? I'm OK with -x and -X, but what do you guys like?x is good. How would one specify a server, -l {port} -X {type}?
Pretty much, but -l doesn't take a port number anymore. One of the first bigger changes I made when I started working on Ncat this summer was to redesign it to take the address and port to bind to just like it does a host/port to connect to rather than using -l and -s. You can see the r8740 log for a better explanation on this. Oh, but sorry if you knew this but I mistook your example :) But otherwise, yep, that's the plan. Just like --ssl means either connect with SSL or listen with SSL solely depending on -l (so there's no --ssl-server or some other redundant nonsense).
* Should the -X equivalent option default to anything? OpenBSD Netcat defaults to SOCKS5.It might be simplest to default to http. Then we'd only need -X, -X4 and -X5.
Sounds good to me. I actually prefer defaulting to HTTP, but I figured more people used SOCKS so defaulting to that would be better. Any objections here?
* 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?I like http better than connect. I like just 5 rather than socks5, but I suppose both types of option might be allowed.
OK--if there are no objections of course--"http", "4" and in the future "5" will be the official, documented ones, and I may or may not (probably not) add the socks* equivalents as synonyms. So if anybody prefers the socks* ones, speak now :)
* 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.I guess we'd have to stick with a long option, something like --xauth, --x-auth, -auth would be reasonable.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}These would be good long options and better than the --http-proxy, --http-server, ... options for sure. I do like the idea of -x, -X and --auth though.
I don't like just --auth since the name itself doesn't convey "proxy authentication" to me, and this can cause problems in the future if some other non-mutually exclusive option can take some other type of authentication. Maybe we can just go the route of OpenBSD Netcat, but add in our long options: -x, --proxy -X, --proxy-type -P, --proxy-auth It's just that mixing the short forms with --proxy-auth, or the long forms with --x-auth, don't go well together IMO, and I also don't really want to have --x-auth or whatever be a synonym for --proxy-auth. So how's this? Any other (even completely different) ideas are still of course welcome.
My thruppence. jah
Thanks jah, I really appreciate it. Kris Katterjohn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSO+hmv9K37xXYl36AQKibg//fQ7Rp0rfzhZtiGlr+H4BF3sakZNkvC8f ma8f4Kyj47iseVWESiPBcE5juDMRwO7FYbIBioye12i26CTETT0j0SIHUVjo3CeL KQ60loKbVbkt/QeMXP8vVPWv4Hllpe56NSeB61B+yyOZa9VFEt2JQieVEbJee/kD Ww0SgEpIsaVDcb/358OZxwSc2yYlIC/3D5HOUDQQZ1DOp9fHjwXPQLOIdmFyDCb4 CivvFcwgp3oHj22k22m2410oPFyheES9E0VorgbLK2m4hMIrvZTpMkL9ScRKdkHi EyTi860ss/En4CJYW4Y6AsHdD7SxZZEcsy+aIcfKjPnh1HA//8niwV1PXLjcSxcn VBZ9pvcL9ZzNyTWdDByY31o+zxlDFoiBrn8H9na0LaaLDSPiDF4bO1PiMic/neHo GPlbM9zpr/ugZ2RZ8TgcIisYke6YNhI4o1xsCxMfXX6Ed+fAn+Rmo8aBaBK/rlmT iRqv2Xw+w7Too3SMA3j3SoGEU2H1Ydl0RGumXer7LVVaT3HjM6znBDgjLydTtk4B jk7sIf4BK4Ie2hEXQWEbQ+cNX/UbYD0HZiI0sMtXkqA89Lh+4M8Ac3NsfJSx1L5e V6YDd/NgRA7j8d956FFyZkpdmVRWAVgjKNtTd00TixSNC9VjKzzqrvlzCjtsOJRW gI04Nnm4zo0= =HJ1J -----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)