Nmap Development mailing list archives

Supporting SNI throughout NSE


From: David Fifield <david () bamsoftware com>
Date: Fri, 13 Aug 2010 16:35:41 -0600

Nuno Gonçalves found that Ncat and Nmap didn't support Server Name
Indication (SNI), which is a way to indicate the intended host name of
the target of the connection during the SSL handshake. This allows
virtual hosting of multiple SSL services on the same port and IP.

I committed a change to enable SNI in Ncat and service scanning. The
next obvious step is to do it for NSE, but I ran into a problem there.

For testing I'm using the two domains xn--j4h.ws and xn--k4h.ws, from
this article:
http://langui.sh/2009/11/03/ssl-vhosting-on-the-same-ip-aka-sni/. They
happen to be IDN names, but that isn't important here. We should be able
to run this and get the two different HTML titles:

nmap --script=html-title -Pn -n -p 443 xn--j4h.ws xn--k4h.ws

But it doesn't work:

Nmap scan report for xn--j4h.ws (173.45.234.167)
PORT    STATE SERVICE REASON
443/tcp open  https   syn-ack
|_html-title: 400 Bad Request

Nmap scan report for xn--k4h.ws (173.45.234.167)
PORT    STATE SERVICE REASON
443/tcp open  https   syn-ack
|_html-title: 400 Bad Request

It turns out that the IP address is being sent as a string in the SNI
field. The problem is that almost all of our TCP connections in NSE are
made like this:

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

The connect call only sees the IP address, not the host name. It's easy
enough to change this to

socket:connect(host.targetname or host.ip, port.number)

But that's not optimal; looking up the host name a second time could
return a different IP address or something. What we really want is to
specify the host name and IP address at the same time. 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.

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

Current thread: