Nmap Development mailing list archives

Proposed SSL version detection probe changes


From: Kristof Boeynaems <kristof.boeynaems () gmail com>
Date: Sun, 8 Feb 2009 18:41:51 +0100

Hi,

while looking at SSL support in Ncat (see other thread), I ended up
digging into the Nmap version probing code as well.

More specifically, I noticed that the current version Probe for SSL
(defined in nmap-service-probes) is defined as follows:

Probe TCP SSLSessionReq
q|\x16\x03\0\0S\x01\0\0O\x03\0?G\xd7\xf7\xba,\xee\xea\xb2`~\xf3\0\xfd\x82{\xb9\xd5\x96\xc8w\x9b\xe6\xc4\xdb<=\xdbo\xef\x10n\0\0(\0\x16\0\x13\0\x0a\0f\0\x05\0\x04\0e\0d\0c\0b\0a\0`\0\x15\0\x12\0\x09\0\x14\0\x11\0\x08\0\x06\0\x03\x01\0|

This turns out to be an SSLv3 ClientHello.

Now, while an SSLv3 ClientHello will sollicit useful responses from a
pure SSLv3 server, it will most probably generate a less useful answer
from a pure TLSv1 or SSLv2 server. The latter will send a "Protocol
not supported" type of message, that probably contains little useful
information to discern between different implementations. A more
general SSLv2-compatible SSLv3 ClientHello might return better
responses (i.e. more information to act upon, especially the returned
Server Certificate might contain useful information).

Moreover, an as wide range of supported ciphers as possible could be
supported in the ClientHello, to increase the chances that useful
information is returned even further.

I generated such a broad SSLv23 ClientHello with the following command:

 $openssl s_client -connect host:port -cipher ALL:COMPLEMENTOFALL

This packet converted to a version Probe looks as follows:

Probe TCP SSLv23SessionReq q|\x80\x8f\x01\x03\x01\x00f\x00\x00\x00
\x00\x00:\x00\x009\x00\x008\x00\x005\x00\x004\x00\x003\x00\x002\x00\x00/\x00\x00\x1b\x00\x00\x1a\x00\x00\x19\x00\x00\x18\x00\x00\x17\x00\x00\x16\x00\x00\x15\x00\x00\x14\x00\x00\x13\x00\x00\x12\x00\x00\x11\x00\x00\n\x00\x00\t\x00\x00\x08\x00\x00\x06\x00\x00\x05\x00\x00\x04\x00\x00\x03\x07\x00\xc0\x06\x00@\x04\x00\x80\x03\x00\x80\x02\x00\x80\x01\x00\x80\x00\x00\x02\x00\x00\x01\x15\x08f_6\x01\xab\xf8\xa4&o\xf8_\xec{\x01+\xc0\xd19M\x0b5\x8f#\xc3\xc6'Ie\xa8s|

For completeness, I also generated a TLSv1 version Probe, which looks
as follows:

Probe TCP TLSv1SessionReq
q|\x16\x03\x01\x00j\x01\x00\x00f\x03\x01I\x8f\x16)\xa0_\xe2\xac\xe6\xfa\xea}$\xd4iH-\xa1^\x9ah\xa28}\xf5\x96\xe8\xc8\xde\x95T\x98\x00\x008\x00:\x009\x008\x005\x004\x003\x002\x00/\x00\x1b\x00\x1a\x00\x19\x00\x18\x00\x17\x00\x16\x00\x15\x00\x14\x00\x13\x00\x12\x00\x11\x00\n\x00\t\x00\x08\x00\x06\x00\x05\x00\x04\x00\x03\x00\x02\x00\x01\x02\x01\x00\x00\x04\x00#\x00\x00|

It might be a good idea to add these two additional version probes as
well, with the more general SSLv23 one first, and falling back to the
other two. Not sure whether that is worth the time penalty though;
that should be tested in practice.

Cheers,

Kristof

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


Current thread: