Re: Proposed SSL version detection probe changes

[Fyodor <fyodor () insecure org>]

On Tue, Feb 10, 2009 at 07:43:14PM +0100, Kristof Boeynaems wrote:
> Brandon Enright wrote:
> SSLv23 solution:
>    PORT     STATE SERVICE VERSION
>    4400/tcp open  tlsv1
>    4401/tcp open  sslv2
>    4402/tcp open  tlsv1
>    4403/tcp open  tlsv1
>    4404/tcp open  sslv3
>    4405/tcp open  sslv3

Thanks Kristof.  This is interesting data, but I'm not sure we want to
separate out SSL version information in the "service" field.  After
all, they are all forms of SSL, right?  Splitting them out may also
cause issues with Nmap's "magic" treatment of SSL, where it connects
back to the service using an OpenSSL SSL connection and tries to
interrogate further.  This might be useful information for the version
or extra information fields in the signature though.

> In short, going for this SSLv3 solution ensures backward compatibility, 
> and improves SSL coverage (as compared to the current SSL probe).

Does our current probe miss some SSL services?  Or is the difference
just a matter of whether it can detect different SSL versions?

> 2. Commented out the match lines that are so generic that they actually 
> simply match a general TLSv1 handshake alert or SSLv3 ServerHello.

Well remember that when SSL is detected, we connect again anyway using
OpenSSL.  I think the vast majority of Nmap installs now support
OpenSSL.  Even the Windows setup exe and zip file do.

For most services, I'm all for removing generic match lines in favor
of adding more specific ones.  But for SSL, I'm not sure it is worth
it.  It would require the second probe to detect these services (thus
taking up more time for service detection), and the information is
likely to be blown away anyway after Nmap connects to the OpenSSL
service using OpenSSL.  But I'm not opposed to the idea if there are
important benefits to doing so.

Cheers,
-F

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