Re: [nmap-svn] r32114 - nmap-exp/d33tah/ncat-lua-callbacks/ncat/test

[Jacek Wielemborek <wielemborekj1 () gmail com>]

I believe that depends on the use case. Since you can handle both
encoding and decoding side of such proxy, it'd be easy to for example
encrypt whole proxy session or obfuscate it in any way for example to
do some IDS evasion. Perhaps it'd be better to leave the behavior
there, just optional?

2013/8/30 David Fifield <david () bamsoftware com>:
> On Fri, Aug 30, 2013 at 12:48:29PM +0200, Jacek Wielemborek wrote:
> > The new addition to the tests uncovered a weird, probably unwanted
> > behavior introduced in r32028. The problem is that when you do -L
> > scripts/filters/rot13.lua on both proxy server and proxy client, the
> > target through which we're proxying to also needs to be run with -L
> > rot13.lua. Should I revert r32028 to make the ultimate destination
> > host receive the decoded data?
>
> Does --load-lua-socket-file affect proxy negotiation? My impression is
> that it shouldn't, neither in connect nor listen mode. The proxy stuff
> should always be unmodified by Lua. Only the traffic that goes through
> the proxy (after negotiation) should be changed. In other words, you
> should have to specify base64 on the client and the server, but not on
> the proxy in between. The -L modification should be strictly between the
> client and the server.
>
> David Fifield
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/