2015-06-24 13:56:27 > d33tah (~d33tah () kolos math uni lodz pl) has joined #nmap-socks
2015-06-24 13:56:27 -- Mode #nmap-socks [+ns] by hobana.freenode.net
2015-06-24 13:56:27 -- Channel #nmap-socks: 1 nick (1 op, 0 voices, 0 normals)
2015-06-24 13:56:29 -- Channel created on Wed, 24 Jun 2015 13:56:27
2015-06-24 18:23:01 > pasca1 (~pasca1 () dhcp-v214-048 vp reshsg uci edu) has joined #nmap-socks
2015-06-24 19:35:02 > hatchee (~henri_@nmap/developer/hatchee) has joined #nmap-socks
2015-06-24 19:45:51 @d33tah hi hatchee, pasca1 
2015-06-24 19:45:58 @d33tah looks like i didn't mess up the timezones ;)
2015-06-24 19:47:00 pasca1 d33tah: hi!
2015-06-24 19:47:20 pasca1 how many more people are we expecting?
2015-06-24 19:47:49 @d33tah i'd say Fyodor, Daniel and David
2015-06-24 19:49:26 @d33tah afk, i'll go grab some tea
2015-06-24 19:51:25 @d33tah back
2015-06-24 19:53:03 > bonsaiviking (~bonsaivik@nmap/dmiller) has joined #nmap-socks
2015-06-24 19:53:49 @d33tah hello :)
2015-06-24 19:54:01 hatchee Hi there
2015-06-24 19:54:28 hatchee (I'm Henri)
2015-06-24 19:56:34 @d33tah i noticed that David didn't sign up on Doodle
2015-06-24 19:56:43 @d33tah and hadn't replied to Fyodor's thread
2015-06-24 19:56:55 @d33tah so i'd assume we're only waiting for Fyodor and I messaged him over XMPP
2015-06-24 19:59:53 > fyodor (~fyodor@nmap/Fyodor) has joined #nmap-socks
2015-06-24 20:00:07 fyodor Howdy!
2015-06-24 20:00:11 hatchee hi
2015-06-24 20:00:15 @d33tah hi fyodor 
2015-06-24 20:00:19 pasca1 hello
2015-06-24 20:00:19 -- Mode #nmap-socks [+o fyodor] by d33tah
2015-06-24 20:00:23 -- Mode #nmap-socks [-o d33tah] by d33tah
2015-06-24 20:00:42 @fyodor Thanks, everyone for coming!
2015-06-24 20:01:27 @fyodor So maybe Andrew and Jacek can start by going over where we are now and the current issues?
2015-06-24 20:01:50 d33tah okay. pasca1, would you mind if i started?
2015-06-24 20:01:57 pasca1 d33tah: go for it
2015-06-24 20:02:28 d33tah so generally, the assumption was to start without touching the port scanning codebase because there's no stable nsock scanner
2015-06-24 20:02:54 d33tah (i tried to implement one but recently hatchee showed me that the way i'm doing it kind of abuses the stack and might be the root cause of the segfaults)
2015-06-24 20:03:16 d33tah so we went for implementing socks4a as another proxy mode next to http connect and socks4 in nsock
2015-06-24 20:03:29 d33tah and then make NSE connect() use it
2015-06-24 20:04:12 d33tah this way me and Andrew could test the implementation and actually leave it working at least for prerule/postrule/hostrule scripts
2015-06-24 20:04:37 d33tah fyodor: i'll summarize how we tried to implement the first iteration, okay?
2015-06-24 20:04:47 @fyodor certainly!
2015-06-24 20:05:14 d33tah so the first idea was to make http-title-hostrule that would just grab http title, but without port scanning
2015-06-24 20:05:34 d33tah you'd do nmap -Pn -sn -n --script http-title-hostrule target and it should work
2015-06-24 20:06:27 d33tah one problem that we had and didn't really solve was the API - inside of l_connect, which is an entry point for NSE connect(), the hostname resolution is being performed and nsock_connect_tcp is called on a struct sockaddr
2015-06-24 20:07:19 d33tah since i decided that we're exploring the problems first, i suggested pasca1 to just hack around this one by making Nmap always pick nsock_connect_tcp_socks4a that used the hostname and actually passed it on to socks4a proxy
2015-06-24 20:07:33 d33tah (there was additional check that basically tested whether --proxy argument started with socks4a://)
2015-06-24 20:07:42 d33tah i do know it's ugly, but it helped us unearth another problem:
2015-06-24 20:08:16 d33tah nmap won't even try to run -n -Pn -sn if the target hostname doesn't resolve, which is the case if you try to use DNS on an .onion address
2015-06-24 20:08:28 d33tah so first two problems are:
2015-06-24 20:08:54 d33tah 1. nsock_connect_* expects the caller to already resolve the hostname and pass the IP as the argument
2015-06-24 20:09:17 d33tah 2. if socks4a is being used, nmap shouldn't try to resolve and cache target's IP address because there isn't one
2015-06-24 20:10:10 d33tah also, NSE isn't that much useful with prerule/postrule/hostrule scripts alone, so for testing purposes I asked pasca1 to dig up my fork of hatchee's nmap-nse-portscan, with an implementation of connect() scan that uses NSE l_connect
2015-06-24 20:10:13 hatchee I think it'd be easy to make nsock API take struct nsock_target instead of sockaddr
2015-06-24 20:10:45 hatchee struct nsock_target being a container for either a hostname, URL, sockaddr...
2015-06-24 20:10:53 d33tah hatchee: my gut tells me the same - i'd expect gethostbyaddr() to be replaced with nsock_resolve
2015-06-24 20:11:10 hatchee with an enum describing the nature of the info, and flags, possibly
2015-06-24 20:11:37 d33tah ah, getaddrinfo*. i meant DNS resolution anyway.
2015-06-24 20:12:09 d33tah well one thing that'd definitely take some time is replacing all the calls in nmap, ncat and nping
2015-06-24 20:12:13 hatchee my only concern is that we change many things just to make PoCs work together
2015-06-24 20:12:33 hatchee remember that the proxy support is not fully complete (SSLv3 reconnect is broken)
2015-06-24 20:13:04 d33tah well, generally, would this change alone count as useful refactoring?
2015-06-24 20:13:18 hatchee and as you said there is currently no stable nsock-based port scanning module
2015-06-24 20:13:48 d33tah i was recently wondering how much time would it take to replace select() with nsock_loop and connect() with nsock_connect_tcp
2015-06-24 20:13:52 d33tah in scan_engine.cc
2015-06-24 20:13:52 hatchee this single change, yes, because it's needed for a (useful) socks4a support
2015-06-24 20:14:39 hatchee so I see three separate questions: target specification in nsock, socks4a support and port scanning through proxies
2015-06-24 20:15:05 hatchee as for target specification, I see no real other alternative
2015-06-24 20:15:17 d33tah i remember David suggesting me to try that change a year ago but i didn't know back then that it made sense to call nsock_loop with a timeout
2015-06-24 20:15:31 hatchee IIRC, David & I kinda agreed on that a couple years ago when discussing the question
2015-06-24 20:16:09 d33tah which one? target specification?
2015-06-24 20:16:14 hatchee yes
2015-06-24 20:16:31 d33tah interesting. so this one change's been waiting there for years? ;)
2015-06-24 20:16:52 hatchee unfortunately, yes
2015-06-24 20:17:08 d33tah well i guess this kind of proves that there's need to actually make it
2015-06-24 20:17:16 d33tah what was the reasoning back then? socks4a as well?
2015-06-24 20:18:26 hatchee it was delayed because my priority was a larger refactoring project, which I haven't had time to do
2015-06-24 20:18:43 hatchee and which would (hopefully) help having a full and robust proxy support
2015-06-24 20:18:55 hatchee then it would be really interesting to have socks4a
2015-06-24 20:19:15 hatchee and migrate more components from nmap to nsock
2015-06-24 20:19:26 hatchee of nmap*
2015-06-24 20:19:53 hatchee anyway, I think you can start working on this target specification thing
2015-06-24 20:20:07 d33tah well, imho it's not a very difficult change and if it makes sense on its own, we could ask pasca1 to work on it
2015-06-24 20:20:15 hatchee the API has to be very simple, to not obfuscate the upper layer
2015-06-24 20:20:28 d33tah my suggestion is to introduce nsock_resolve()
2015-06-24 20:20:49 hatchee sure, when I say "you" it's a generic "you" :)
2015-06-24 20:20:50 d33tah and then its result would be passed to nsock_connect_*
2015-06-24 20:20:56 pasca1 would nsock_resolve call getaddrinfo?
2015-06-24 20:21:08 d33tah if it's not socks4a.
2015-06-24 20:21:10 hatchee hmm that's not how I would do it
2015-06-24 20:21:31 bonsaiviking Well, part of the trouble there is that some proxy methods (SOCKS4a, HTTP Connect) do not resolve an address at all.
2015-06-24 20:21:35 hatchee nsock_target_new(void *tgt, size_t tgt_len, enum nsock_tgt_type)
2015-06-24 20:21:50 bonsaiviking You connect by-name. the Proxy doesn't hand you an IP address at all.
2015-06-24 20:21:58 hatchee right
2015-06-24 20:22:03 d33tah bonsaiviking: i'd make it transparent
2015-06-24 20:22:10 d33tah i think we're talking about a similar thing
2015-06-24 20:22:17 d33tah i like your approach more, hatchee 
2015-06-24 20:22:18 d33tah because
2015-06-24 20:22:23 d33tah right after nsock_resolve
2015-06-24 20:22:28 d33tah we'd need nsock_by_ip or something
2015-06-24 20:22:46 d33tah and grouping it all into a single function that just takes the enum sounds better
2015-06-24 20:22:50 d33tah do you follow, pasca1?
2015-06-24 20:23:12 hatchee name resolution is something different, we're just talking about the objects we have to manipulate here
2015-06-24 20:23:13 pasca1 yeah, so in the nsock_target_new proto type, *tgt is the hostname?
2015-06-24 20:23:24 d33tah pasca1: or the IP
2015-06-24 20:23:30 bonsaiviking ok, so this new thing returns a somewhat opaque structure that can be used in nsock_connect_* but doesn't necessarily contain an IP address?
2015-06-24 20:23:33 d33tah hatchee: why not resolve them at the same time?
2015-06-24 20:23:42 pasca1 okay, so the decision to resolve or not would be before that was called?
2015-06-24 20:23:49 hatchee socks4a needs a hostname (potentially) and we currenlty have IPs only. Let's make nsock able to handle both
2015-06-24 20:23:56 d33tah pasca1: the decision shouldn't be up to the user
2015-06-24 20:23:58 < fyodor (~fyodor@nmap/Fyodor) has quit (Ping timeout: 244 seconds)
2015-06-24 20:24:03 d33tah whoops.
2015-06-24 20:24:04 hatchee bonsaiviking: yes
2015-06-24 20:24:21 hatchee pasca1: yes
2015-06-24 20:24:23 pasca1 sorry, "decision" might have been misleading
2015-06-24 20:24:35 > fyodor (~fyodor@REDACTED) has joined #nmap-socks
2015-06-24 20:24:36 d33tah so
2015-06-24 20:24:42 < fyodor (~fyodor@REDACTED) has quit (Changing host)
2015-06-24 20:24:42 > fyodor (~fyodor@nmap/Fyodor) has joined #nmap-socks
2015-06-24 20:24:55 d33tah we call nsock_target_new with the enum being BY_NAME or something
2015-06-24 20:24:56 fyodor I think Comcast failed me for a bit
2015-06-24 20:25:15 fyodor but I'm back now
2015-06-24 20:25:35 d33tah fyodor: would you like to take a look at the log?
2015-06-24 20:25:48 fyodor Yeah, could you mail or msg it to me?
2015-06-24 20:25:54 d33tah i'll mail it
2015-06-24 20:25:57 fyodor thanks
2015-06-24 20:26:22 d33tah done
2015-06-24 20:26:34 d33tah 20:24:55       d33tah $ we call nsock_target_new with the enum being BY_NAME or something
2015-06-24 20:26:47 d33tah if it's socks4a, the name just gets stored, if it's not, it's resolved, right?
2015-06-24 20:27:13 hatchee yes, proxy initialization functions do that
2015-06-24 20:27:49 d33tah okay, so we're right when nsock_target_new is called. good.
2015-06-24 20:27:55 d33tah resolving right*
2015-06-24 20:28:27 hatchee and there must be no difference in API whether there's a proxy chain used or not
2015-06-24 20:28:42 d33tah sounds sane.
2015-06-24 20:28:54 hatchee a connect is a connect, doesn't matter if it loops over 10 proxies before returning
2015-06-24 20:30:00 hatchee so I think you got it, or do you want me to clarify? :)
2015-06-24 20:30:13 bonsaiviking It's going to be a *lot* of work to get this to work with Nmap's regular forward lookups and Target objects, but I think it's valuable even without that support right away.
2015-06-24 20:30:21 d33tah hatchee: i think i got it. pasca1?
2015-06-24 20:30:26 pasca1 i think i'm understanding
2015-06-24 20:31:07 d33tah bonsaiviking: what do you mean?
2015-06-24 20:31:22 pasca1 does this mean we would keep just one nsock_connect_tcp that takes the nsock_target object?
2015-06-24 20:31:35 d33tah pasca1: yup
2015-06-24 20:31:42 pasca1 great
2015-06-24 20:31:47 d33tah and probably the same to nsock_connect_udp and sctp
2015-06-24 20:33:18 d33tah actually now i'm thinking if this nsock_target_new could also take the protocol and change semantics...
2015-06-24 20:33:32 d33tah (probably not)
2015-06-24 20:34:37 hatchee make it simple and generic
2015-06-24 20:34:59 d33tah so for now, as proposed by you
2015-06-24 20:35:43 d33tah because i was thinking of x = nsock_connection_new(tspec, port, tspec_type) and replacing nsock_connect_* with nsock_connect(x)
2015-06-24 20:35:47 d33tah for a minute
2015-06-24 20:36:09 d33tah but it might not be a good idea
2015-06-24 20:37:45 hatchee an other question was about the implementation itself, of socks4a proxy module
2015-06-24 20:38:00 bonsaiviking d33tah: right now, forward lookups are done right in the middle of target expression parsing: TargetGroup.cc:239: static NetBlock *parse_expr_without_netmask(const char *hostexp, int af)
2015-06-24 20:38:01 d33tah yeah, there's quite some code duplication. this was done on the quick.
2015-06-24 20:38:28 hatchee pasca1: it looks good
2015-06-24 20:38:30 bonsaiviking So even once this is done, it probably will be limited to prerule scripts until that's changed
2015-06-24 20:38:51 hatchee (sry, I'm moving on too quickly)
2015-06-24 20:38:57 d33tah no problem for me
2015-06-24 20:39:21 pasca1 thanks, but yeah, lots of code duplication and hacky stuff
2015-06-24 20:39:37 hatchee pasca1: yes, please reuse the existing code and structures
2015-06-24 20:39:56 hatchee I'm totally ok with having two proxy_spec exposed from a single file, it's no problem at all
2015-06-24 20:40:19 hatchee just override the functions that behave differently
2015-06-24 20:40:22 pasca1 okay, that was what i was hoping to do
2015-06-24 20:40:53 hatchee also, please stick to nsock C coding conventions (like: no declarations in the middle of a block)
2015-06-24 20:41:00 hatchee I'm almost emotional on that :)
2015-06-24 20:41:21 pasca1 okay, sorry, i wasn't aware before but d33tah told me after I had moved on
2015-06-24 20:41:54 d33tah for a moment i was afraid i hadn't caught that.
2015-06-24 20:42:00 pasca1 are there any other nsock coding conventions I should be mindful of?
2015-06-24 20:42:49 hatchee no tabs, 2 spaces indent, lowercase for everything but macros, nsock_ prefixes for public symbols
2015-06-24 20:42:56 hatchee no new typedefs
2015-06-24 20:43:15 hatchee are the most important ones I think
2015-06-24 20:43:21 pasca1 thank you
2015-06-24 20:43:46 bonsaiviking General rule is: don't make your code stick out ;)
2015-06-24 20:43:58 d33tah nicely put.
2015-06-24 20:44:14 hatchee (no designated initializers, they're beautiful but prevent nsock to build on windows!) :D
2015-06-24 20:44:29 d33tah tbh this doesn't ring a bell.
2015-06-24 20:44:53 d33tah okay, so i think that we decided on target specification and socks4a implementation. the target resolution done by nmap is still a tad problematic.
2015-06-24 20:45:48 hatchee once again: proxy support must be transparent, but I understand that the high level changes you did were a hack to be able to test your code
2015-06-24 20:46:03 d33tah yup
2015-06-24 20:47:20 hatchee are there other items to discuss?
2015-06-24 20:47:26 d33tah 20:44:53       d33tah $ okay, so i think that we decided on target specification and socks4a implementation. the target resolution done by nmap is still a tad problematic.
2015-06-24 20:47:31 d33tah the second sentence
2015-06-24 20:47:46 d33tah right now we walked this around by adding an /etc/hosts entry
2015-06-24 20:47:55 d33tah just to make the address resolve to 127.0.0.1 since it's not used anyway
2015-06-24 20:48:32 bonsaiviking I would stick with that for now. Remember, Nsock is more than just Nmap.
2015-06-24 20:48:45 d33tah but that renders the PoC hardly usable
2015-06-24 20:48:54 bonsaiviking If you want a showcase for the new functionality, build it into Ncat first.
2015-06-24 20:49:01 bonsaiviking I think that would be easier, don't you?
2015-06-24 20:49:26 d33tah i'd say it would be more fun to add --treat-hostname-literally, but i would be surprised if nobody minded that.
2015-06-24 20:49:44 bonsaiviking Part of my hesitance to go for that right away is that I see it as a bigger project:
2015-06-24 20:49:57 bonsaiviking separate forward name lookups from Nmap's target parsing code.
2015-06-24 20:50:08 d33tah sounds painful.
2015-06-24 20:50:30 bonsaiviking At that point, we could use nmap_dns.cc code to parallelize the lookups (using Nsock, naturally!)
2015-06-24 20:50:47 d33tah okay, so this one stays unresolved
2015-06-24 20:50:58 fyodor lol
2015-06-24 20:51:07 bonsaiviking Yes, because there's a (weak) workaround (hosts file) for Nmap
2015-06-24 20:51:29 bonsaiviking and the focus should be on building a solid foundation in Nsock.
2015-06-24 20:51:45 d33tah understood. hold on, i'll check Andrew's e-mail, looking for more issues
2015-06-24 20:52:27 d33tah http://seclists.org/nmap-dev/2015/q2/244
2015-06-24 20:52:50 bonsaiviking For that matter, build a lua script for Ncat that implements a "everything is 127.0.0.1" DNS server and use it with --dns-servers.
2015-06-24 20:53:14 d33tah should be doable. i already have code for a dns server.
2015-06-24 20:53:19 bonsaiviking oh, that doesn't work because forward lookups don't use --dns-servers. Nevermind (also a reason to separate that out!)
2015-06-24 20:53:31 d33tah i remember David specifically telling me not to merge it because there's the danger that anybody would use it :D
2015-06-24 20:53:40 d33tah (and i hadn't looked at the rfc even once when i was implementing it)
2015-06-24 20:54:06 bonsaiviking lol, scary. But even using dnsmasq there are simple configs to answer all .onion with 127.0.0.1.
2015-06-24 20:54:13 d33tah #3 - another thing i wouldn't expect to get merged would be "ignore scan" that would assume ports to be open just like -Pn assumes hosts to be up
2015-06-24 20:54:15 bonsaiviking so it's not such a terrible workaround.
2015-06-24 20:54:18 d33tah bonsaiviking: LD_PRELOAD if we're going crazy? :D
2015-06-24 20:54:31 d33tah at least things stay in the userland
2015-06-24 20:54:45 d33tah though
2015-06-24 20:54:56 d33tah if you do this kind of things, you can as well just shadow getaddrinfo
2015-06-24 20:55:06 d33tah right inside the C code, checking for .onion. whatever.
2015-06-24 20:55:26 bonsaiviking d33tah: (#3) could be implemented easily if we ever do scanrule NSE scripts.
2015-06-24 20:55:27 d33tah i agree that it's not critical if you don't like my lovely --treat-hostname-literally idea
2015-06-24 20:55:46 d33tah bonsaiviking: it's actually even easier without it
2015-06-24 20:55:53 d33tah this was nmap-nsock-scan rev1
2015-06-24 20:56:45 d33tah https://svn.nmap.org//nmap-exp/d33tah/nmap-nsock-scan/nsock_scan.cc?p=32621
2015-06-24 20:56:53 d33tah i like the header to code ratio
2015-06-24 20:57:34 d33tah bonsaiviking: for me it's not the problem of implementation but more of "will it blend" (or be merged).
2015-06-24 20:58:31 bonsaiviking Right, so what I was saying is that if we do the (desired by some) scanrule NSE project, then
2015-06-24 20:59:01 bonsaiviking it doesn't matter if nobody wants an "ignore scan" but you, you can have it in a tiny lua script in your home dir.
2015-06-24 20:59:23 d33tah i'd say it could be useful in some cases?
2015-06-24 20:59:32 d33tah -O with two syns less
2015-06-24 20:59:46 d33tah running the script without making the connection
2015-06-24 20:59:49 d33tah a tad less noisy
2015-06-24 20:59:53 bonsaiviking Sure. But just as useful would be any number of other ways to provide "this port is open"
2015-06-24 21:00:07 d33tah what do you mean?
2015-06-24 21:00:40 bonsaiviking read output of netstat; input a previous -oX result; rpcinfo; snmp-netstat;
2015-06-24 21:00:42 bonsaiviking etc.
2015-06-24 21:01:26 d33tah you're right and actually the main argument for adding my idea was that there's no real -Pn counterpart
2015-06-24 21:01:37 d33tah so, as expected, nobody likes my idea.
2015-06-24 21:01:46 bonsaiviking we're getting a bit off-topic, though :)
2015-06-24 21:01:54 d33tah sorry
2015-06-24 21:02:18 d33tah #4:
2015-06-24 21:02:23 d33tah "We need to decided how to handle cases where socks4a proxies are listed
2015-06-24 21:02:23 d33tah in a proxy chain that includes other proxy types.  For example, if a
2015-06-24 21:02:23 d33tah socks4a proxy is supposed to create a tunnel to an http proxy, we need to
2015-06-24 21:02:23 d33tah consider if/how to also prevent DNS resolution of the http proxy URI.  If
2015-06-24 21:02:23 d33tah anyone knows of any other issues that could come up with adding socks4a to
2015-06-24 21:02:23 d33tah proxy chains, please let me know."
2015-06-24 21:02:55 d33tah (and this is probably the last one on my end)
2015-06-24 21:03:33 d33tah i have no opinion on #4 right now, expecting this to pop up while testing.
2015-06-24 21:04:12 hatchee with a flexible way to specify targets (including the nodes of the px chain too)
2015-06-24 21:04:34 d33tah (including the nodes of the px chain too)
2015-06-24 21:04:35 hatchee we should be able to instruct the socks4a module to resolve its next hop remotely
2015-06-24 21:04:58 d33tah you mean proxy scanning one of proxy chain node?
2015-06-24 21:05:07 hatchee no,
2015-06-24 21:05:23 d33tah nodes*
2015-06-24 21:05:27 hatchee the proxies are reached via regular nsock calls
2015-06-24 21:05:49 hatchee which can recursively loop over a chain
2015-06-24 21:06:24 d33tah so basically nsock would use nsock_target_new internally as well
2015-06-24 21:06:30 bonsaiviking So as long as the last hop knows how to contact the next thing (whether another hop to be added or the target)
2015-06-24 21:06:42 bonsaiviking it's transparent and everything works.
2015-06-24 21:06:45 hatchee yes
2015-06-24 21:06:58 hatchee should work* ;)
2015-06-24 21:07:09 bonsaiviking You could conceivably build a chain that doesn't work, but it wouldn't work for *anyone* not even proxychains-ng at that point.
2015-06-24 21:07:23 hatchee indeed
2015-06-24 21:07:42 d33tah i can't think of an example right now. should it be detected and considered a fatal error?
2015-06-24 21:07:48 pasca1 yeah, i
2015-06-24 21:08:01 pasca1 sorry -- i'm curious what a chain that doesn't work would be
2015-06-24 21:08:33 pasca1 something with http-proxy before socks proxies?
2015-06-24 21:09:06 bonsaiviking me --> socks4 (not 4a) --> xyz.onion
2015-06-24 21:09:07 hatchee anything where node X cannot resolve node x+1
2015-06-24 21:09:09 bonsaiviking why complicate it?
2015-06-24 21:09:18 pasca1 okay, thanks
2015-06-24 21:09:44 d33tah bonsaiviking: hmmm... but that would fail at hostname resolution phase.
2015-06-24 21:09:46 bonsaiviking Am I wrong in suspecting that most http proxies also are fine with using names and not ip addresses?
2015-06-24 21:10:00 bonsaiviking d33tah: there's no hostname resolution phase.
2015-06-24 21:10:09 d33tah which is why it'd fail.
2015-06-24 21:10:16 d33tah nsock_target_new would fail at that point
2015-06-24 21:10:36 bonsaiviking there's the creation of a nsock_target, which does not involve resolving
2015-06-24 21:10:36 d33tah hmmm... that's confusing actually.
2015-06-24 21:10:45 hatchee bonsaiviking: I'm not sure, I think it depends
2015-06-24 21:10:48 bonsaiviking then when you go to connect, the chain is built
2015-06-24 21:10:54 bonsaiviking and fails?
2015-06-24 21:10:57 d33tah bonsaiviking: i thought that we agreed that nsock_target_new would also resolve the IP if it's not socks4a.
2015-06-24 21:12:28 pasca1 i thought we were saying that the IP would be resolved before that?
2015-06-24 21:12:37 hatchee nsock_target_new has no idea what the "protocol" is
2015-06-24 21:12:39 pasca1 (if it isn't socks4a)
2015-06-24 21:12:46 hatchee doesn't even know what a protocol is :)
2015-06-24 21:13:06 hatchee it gives you an almost-opaque structure
2015-06-24 21:13:28 hatchee and internals can use it, as it is, or transformed (resolved)
2015-06-24 21:13:35 d33tah okay, but if you tell it
2015-06-24 21:13:54 hatchee e.g.: if you give tcp connect a hostname it will have to resolve it
2015-06-24 21:14:05 d33tah nsock_target_new("slashdot.org", strlen("slashdot.org"), BY_HOSTNAME)
2015-06-24 21:14:18 d33tah shouldn't it resolve the IP during this call?
2015-06-24 21:14:25 d33tah (unless it's socks4a)
2015-06-24 21:14:26 hatchee no
2015-06-24 21:14:35 d33tah so we defer the resolution to nsock_connect_tcp?
2015-06-24 21:14:41 hatchee yes
2015-06-24 21:14:43 bonsaiviking No, because you haven't given it any info to resolve it. a nsock_proxychain for instance
2015-06-24 21:14:58 d33tah i see.
2015-06-24 21:15:06 d33tah that makes it a bit more complex imho
2015-06-24 21:15:11 d33tah on the implementation side
2015-06-24 21:15:24 bonsaiviking So nsock_proxychain_new would have to call nsock_target_new and nsock_connect internally for each hop
2015-06-24 21:15:45 bonsaiviking but that's the same interface we want the user to use.
2015-06-24 21:15:50 hatchee yep
2015-06-24 21:16:16 bonsaiviking So nsock_connect will resolve the name the best way it can: either it's already a numeric IP, or
2015-06-24 21:16:34 bonsaiviking the last proxy in the chain is one that can take names, or
2015-06-24 21:16:47 bonsaiviking we have to try to resolve it locally.
2015-06-24 21:17:26 bonsaiviking It's always about the last proxy in the chain and the target: once a proxy is no longer the last one, its name resolution functionality is moot.
2015-06-24 21:18:48 d33tah okay. i think i get it.
2015-06-24 21:20:00 d33tah i think that's all on my end then.
2015-06-24 21:20:21 hatchee and I'll have to go very soon
2015-06-24 21:20:32 bonsaiviking hatchee: thanks, it's been super helpful
2015-06-24 21:20:36 pasca1 okay, thank you guys for discussing this
2015-06-24 21:20:39 fyodor Awesome.
2015-06-24 21:20:40 hatchee my pleasure!
2015-06-24 21:20:40 d33tah yes, thank you hatchee :)
2015-06-24 21:20:45 d33tah guys
2015-06-24 21:20:55 d33tah i'll send you the log and ask you if you want anything to redact out of it
2015-06-24 21:21:09 d33tah and then how about i post it on nmap-dev?
2015-06-24 21:21:17 fyodor sounds good to me
2015-06-24 21:21:21 bonsaiviking how about, can you put in some comments from me that sound really smart?
2015-06-24 21:21:27 pasca1 haha
2015-06-24 21:21:52 d33tah bonsaiviking: sure! just tell me what to change :3
2015-06-24 21:21:59 hatchee lol
2015-06-24 21:22:23 d33tah so, is the meeting complete?
2015-06-24 21:22:26 fyodor Alright, meeting is adjourned.  Thanks all!
2015-06-24 21:22:33 bonsaiviking Adios!
2015-06-24 21:22:34 d33tah thank you :)
2015-06-24 21:22:37 < fyodor (~fyodor@nmap/Fyodor) has quit (Quit: Leaving)
2015-06-24 21:22:39 pasca1 bye, thank you!
2015-06-24 21:22:40 < bonsaiviking (~bonsaivik@nmap/dmiller) has left #nmap-socks
2015-06-24 21:22:42 hatchee thank you all, bye!
2015-06-24 21:22:45 < hatchee (~henri_@nmap/developer/hatchee) has left #nmap-socks
2015-06-24 21:22:55 < pasca1 (~pasca1 () dhcp-v214-048 vp reshsg uci edu) has left #nmap-socks