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:
- Supporting SNI throughout NSE David Fifield (Aug 13)
- Re: Supporting SNI throughout NSE Fyodor (Aug 13)
- Re: Supporting SNI throughout NSE David Fifield (Aug 16)
- Re: Supporting SNI throughout NSE David Fifield (Aug 16)
- Re: Supporting SNI throughout NSE David Fifield (Aug 16)
- Re: Supporting SNI throughout NSE Fyodor (Aug 13)