Re: [PATCH] Always list SSL in case any SSL connection succeeded

[David Fifield <david () bamsoftware com>]

On Mon, Mar 02, 2009 at 01:04:28PM -0800, Fyodor wrote:
> On Mon, Mar 02, 2009 at 09:01:05AM -0700, David Fifield wrote:
> > On Tue, Feb 24, 2009 at 10:34:59PM +0100, Kristof Boeynaems wrote:
> > > Kristof Boeynaems wrote:
> > > > David Fifield wrote:
> >
> > PORT   STATE SERVICE   VERSION
> > 80/tcp open  ssl/http?
> >
> > PORT     STATE SERVICE      VERSION
> > 4433/tcp open  ssl/unknown?
> >
> > Though you can also make a case for "ssl/unknown" in the second case.
>
> I agree that we can make a case for removing the '?' in the second
> case.  After all, I think we generally make a special case to omit the
> '?' after "unknown" in version detection.  And, if I understand
> correctly, we're reasonably sure of the ssl part because we've
> successfully made an SSL connection at this point.

There is a new confusion here since nmap-services gained frequency data
and a whole bunch of ports named "unknown". It's true that when Nmap
can't identify a service, and that port doesn't have a name in
nmap-services, it substitutes "unknown" with no question mark. But port
4433 does happen to be in nmap-services, and its name there is
"unknown". So Nmap treats that like any other named port, and puts a
question mark at the end. Here are two examples, with port 4433, which is
in nmap-services, and port 4434, which is not:

$ ncat -l localhost 4433
$ nmap localhost -p 4433 -sV
PORT     STATE SERVICE  VERSION
4433/tcp open  unknown?

$ ncat -l localhost 4434
$ nmap localhost -p 4434 -sV
PORT     STATE SERVICE VERSION
4434/tcp open  unknown

I guess a name of "unknown" in nmap-services is there just because it's
syntactically required, and shouldn't be taken as the supposed name of
the service. Then we should add a new condition: if the service is named
"unknown" in nmap-services, treat it as if were not in nmap-services.
However it works, SSL-tunneled ports should work the same way.

David Fifield

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