Re: Proposed SSL version detection probe changes

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

Brandon Enright wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Mon, 16 Feb 2009 23:53:04 -0800 or thereabouts Fyodor
> <fyodor () insecure org> wrote:
> ...snip...
>   
> > I agree that we should make sure Nsock can connect to any reasonable
> > SSL servers.  Have you found any SSL servers on the Internet for which
> > browsers can connect, but ncat and/or version detection (they use the
> > same SSL connection creation calls) can't?
> >     
> Some versions of Nessus, yes.  Not to long ago I did a giant SSL survey
> of the Internet (many millions of hosts) and found that a small
> percentage (~3%) could not be connected to with the default SSL23
> probe.  I had to manually specify one of the SSL versions using
> openssl s_client.
I did not do an internet survey myself, but in theory Nmap will have 
problems with any SSL server that is not backward compatible with SSLv2 
(i.e. SSLv3-only or TLSv3-only). A type of SSL server that I would 
expect to become more prevalent as SSLv2 support is being phased out.

It shouldn't be too difficult to come up with an Nmap-based script that 
scans a wide range of random SSL servers, and determines what version 
they are supporting; but it seems that Brandon has already done this 
before as part of his SSL survey.
I would be very interested to see a list of that 3%. Is this something 
you can share, Brandon?
> I think the overall goal is to improve the number of services Nmap
> detects as SSL and increase the number of successful SSL connections
> made when Nsock tries SSL.
>
> I think the reason Kristof suggested instead of a generic "ssl"
> service, to have "tlsv1", "sslv3", etc is that Nsock would need to know
> which handshake to use in making the SSL connection.  If we added
> additional service probes for other SSL versions but just matched them
> as "ssl" then Nsock would most likely fail to connect to them
> properly.  Nsock would need to be extended to know about the different
> SSL versions.
>   
Thanks Brandon, that's exactly what I meant.
The idea is to recognize *a* supported SSL version during version 
probing, to use this information later on for making the right SSL 
connection with Nsock (i.e. SSLv2 compatible, SSLv3 or TLSv1; at the 
moment Nsock only supports SSLv2 compatible).
Given that we have this information, we might as well show it to the 
user in the version field, but that is not the actual goal, rather a 
side-effect. On the other hand, there is also a reason to hide this 
information instead, as it can be confusing, given that only *a* 
supported version is shown; the exact version shown/detected is 
dependent on the order of the SSL version probes (discussed at length in 
my previous post).
Note that an enumeration of *all* supported SSL versions is interesting 
to know as well (especially in case SSLv2 is supported), but that is 
probably better done with an NSE script; in fact, there are already NSE 
scripts for that.

Cheers,

Kristof


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