Re: Proposed SSL version detection probe changes

[doug () hcsw org]

On Sun, Feb 08, 2009 at 06:41:51PM +0100 or thereabouts, Kristof Boeynaems wrote:
> Hi,
>
> while looking at SSL support in Ncat (see other thread), I ended up
> digging into the Nmap version probing code as well.

Nice. You may have already read this but version detection handles
SSL specially:

http://nmap.org/book/vscan-post-processors.html#vscan-ssl-postprocess

The idea is that if with probing we detect that a port is SSL, then
we open up a real SSL connection with OpenSSL and run version detection
through that.

Any improvements to the SSL probes would be great. I'm just now
processing a bunch of fingerprints and there are always a few
SSL ones that don't get properly recognized.

> 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.

Although I don't know much about the SSL wire protocol, if these probes
will cover more SSL services I'm all them. Will the match lines in the
existing SSL probe work with these new probes? If so you can add a
fallback directive:

http://nmap.org/book/vscan-fileformat.html#vscan-db-fallback

Thanks,

Doug

Attachment: _bin
Description:

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