Re: Supporting SNI throughout NSE

[David Fifield <david () bamsoftware com>]

On Mon, Aug 16, 2010 at 11:47:07AM -0600, David Fifield wrote:
> On Fri, Aug 13, 2010 at 04:11:12PM -0700, Fyodor wrote:
> > On Fri, Aug 13, 2010 at 04:35:41PM -0600, David Fifield wrote:
> > > What I propose is extending socket:connect to allow passing host and
> > > port tables as an alternative to a string and a number, like we do
> > > in lots of other places. If we get a table, we'll use
> > > host.targetname for SNI. If we get a host name, we'll resolve it and
> > > use it as the SNI.
> > >
> > > How does this sound? It won't break backward compatibility, but all code
> > > will have to be updated in order to support SNI.
> >
> > It sounds good to me!  I can think of many cases where we might want
> > to use SNI against servers other than the listed targets (like for
> > following redirects, or prerule scripts where we don't have a host
> > structure), so I'd suggest that we just note the required table
> > members (and note that the normal host/ports tables meet the
> > requirements) rather than simply asking people to pass the host/port
> > tables.  Also, even if someone passes a table for the host (to enable
> > SNI), I think they should still be allowed to pass a plain port
> > number.
>
> I have committed this change to nmap.connect, and so far I've update
> http.lua and comm.lua to use the host and port tables. Now this is the
> output:
>
> I'll now go and update other code that is still using host.ip and
> port.number.

I did a quick grep and changed all calls in these forms:

socket:connect(host.ip, port.number)
socket:connect(host.ip, port.number, port.protocol)

to this:

socket:connect(host, port)

I think we can all agree that this is better, even aside from the
benefit of supporting SNI.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/