Re: [RFC] Redoing Ncat's Proxy Options

[Kris Katterjohn <katterjohn () gmail com>]

-----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