Re: [PATCH] Extended SSL support in Nmap

[Kristof Boeynaems <kristof.boeynaems () gmail com>]

Brandon Enright wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On Sat, 21 Feb 2009 20:01:33 +0100 or thereabouts Kristof Boeynaems
> <kristof.boeynaems () gmail com> wrote:
> ...snip...
>   
> > Based on these results, it seems that the patches version is more 
> > performant (faster, and generating less packets), while also giving
> > much more information (less 'ssl/unknown's). Also the quality of the 
> > information seems better. Note that the difference in detected ssl
> > ports is due to the fact that 1. and 2. detect a certain services as 
> > "ssl/unknown", while 3. detects this same service as "imaps?". Not
> > sure why this happens.
> >     
>
> The 'imaps?' detection happens because the scan was probing port 993
> and couldn't get any response out of it.  Nmap would have tried the SSL
> (v23) probe but not gotten a response and then moved on to other probes
> in the file.  When all the probes probes Nmap tries don't match it just
> lists the service from the name in nmap-services and slaps a '?' onto
> the end.
>
> With your patch though one of the other SSL probes would have elicited
> a response that would allow Nmap to find the service inside of the
> tunnel.
>
>   

Hi Brandon,
Thanks for the analysis. It is completely correct, apart from the fact 
that it is actually the patched version that will return "imaps?".

I tested this particular host manually. This host shows some "strange" 
behavior, in that it will allow a SSLv3 connection, but will immediately 
afterwards close the connection. Thus Nmap is not able to get any more 
information, although it manages to connect correctly. This is actually 
the 'bug' mentioned earlier, in which Nmap throws away all gathered 
information when it is unable to come to a conclusion. This bug is high 
on my TODO list ;)

The unpatched version, on the other hand, will try an SSLv23 connection, 
but this particular host is one of those rare hosts that does not accept 
such a connection (it is SSLv3-only), so Nmap concludes simply 
"ssl/unknown".

> > Of course a lot more performance (and functional) testing is
> > necessary; I am executing some more extensive tests (more hosts)
> > myself.
> >
> >     
>
> I think this is actually going to be pretty hard to test.  Starting a
> new SSL session is already a very slow, very CPU-intensive task.  When
> I was doing a SSL survey of the Internet I had to keep the
> - --max-hostgroup to 16 because if it was any higher Nmap would try to
> version-probe too many SSL services at once and I wouldn't have enough
> CPU to handle all of the session instantiation.
>
> Jah mentioned seeing this here:
>
> http://seclists.org/nmap-dev/2008/q2/0332.html
>   

Interesting! Currently I am doing scans without this --max-hostgroup 
limitation, and indeed, during the version detection parts my CPU "goes 
through the roof". However, I did not notice any effect on the quality 
of the results for now; then again I haven't really been focusing on 
such issues either.
Do you mean that you noticed that the quality was really suffering 
without this --max-hostgroup limitation? You got different results when 
specifying this option?

> I don't think I'm going to have time this weekend to test things but
> I'll add it to my TODO wish-list.
>   

Thanks, all testing is very welcome.

Kristof

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