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:
- Proposed SSL version detection probe changes Kristof Boeynaems (Feb 08)
- Re: Proposed SSL version detection probe changes doug (Feb 08)
- Re: Proposed SSL version detection probe changes Kristof Boeynaems (Feb 09)
- Re: Proposed SSL version detection probe changes Brandon Enright (Feb 09)
- Re: Proposed SSL version detection probe changes Kristof Boeynaems (Feb 10)
- Re: Proposed SSL version detection probe changes Fyodor (Feb 16)
- Re: Proposed SSL version detection probe changes Kristof Boeynaems (Feb 09)
- Re: Proposed SSL version detection probe changes Fyodor (Feb 16)
- Re: Proposed SSL version detection probe changes Brandon Enright (Feb 17)
- Re: Proposed SSL version detection probe changes Kristof Boeynaems (Feb 17)
- Re: Proposed SSL version detection probe changes Kristof Boeynaems (Feb 17)
- Re: Proposed SSL version detection probe changes Brandon Enright (Feb 17)
- Re: Proposed SSL version detection probe changes doug (Feb 08)