Re: [PATCH] Extended SSL support in Nmap

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

doug () hcsw org wrote:
> Hi Kristof,
>
> Thanks for looking into version detection/SSL so deeply. There are usually
> a few fingerprints for SSL services that weren't properly matched though
> I think recent versions of Nmap have gotten better because it mostly seems
> to be outdated nmap versions that send these.
>   

Good to know!

> Would it be possible to keep the SSLSessionReq probe name? The thing is
> that we often get fingerprints from old versions of Nmap and they will
> all use the probe name SSLSessionReq which will make it difficult to
> test them against an nmap-service-probes that doesn't have this probe.
>   

Sure, we can keep the old name. I didn't realize that that is important 
for fingerprint tracking. I only changed the name because I found that 
that covered the content of the probe better; but of course we can keep 
the old name, and just clarify in the Probe comment.

> I like how your patch doesn't modify the probe string sent by the SSL
> probe. This is good because there are other non-SSL services that are
> matched by the SSLSessionReq probe. If the probe string changed it
> might obsolete those match lines and we'd have to start over with those
> services. Off the top of my head, AFP and tor are two services matched
> by this probe.
>
> Anyways your patch is looking good as it sounds like it will increase
> Nmap's SSL coverage. But this could potentially be a big change so we
> should make sure we think it all the way through. 

Agree.

> And of course any
> modifications to the system need to be documented:
>
> http://nmap.org/book/vscan-post-processors.html#vscan-ssl-postprocess
>
> I think at least it will need to be made clear that there are multiple
> services that will be passed to SSL post processing (if available),
> not just ssl but now tlsv1, sslv3, sslv2, etc. 

Yes, this is indeed a change that should be documented (if the current 
patch proposal would get accepted).

> As Fyodor said it might
> make more sense just to keep using ssl for everything unless there's a
> really compelling reason otherwise.
>   

Well, currently the SSL coverage of Nmap is not perfect. It misses about 
0.4% of the SSL services out there (according to my latest tests, see 
http://seclists.org/nmap-dev/2009/q1/0486.html).
The same goes for SSL support in Ncat (which shares the same Nsock SSL 
code).

Therefore, if we can extend SSL support in Nsock (hence Nmap and Ncat), 
without affecting current performance/quality of Nmap, I think we should 
do it.

This patch aims to do exactly that. Of course some extensive testing has 
to be performed, to validate the patch, and the assumptions above 
(especially the assumption that Nmap performance doesn't suffer).

Note that currently, only 'ssl' is shown in results (not 'ssl3' or 
tls1'), as I see no good reason to show the detected SSL versions to the 
user (as explained earlier).

> Hope this helps,
>   

Thanks!

Kristof

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