SSL-related improvements last week

[Daniel Miller <bonsaiviking () gmail com>]

List,

Last week I made a series of changes to better support and detect TLS/SSL
and TLS-wrapped services. I want to summarize them here to see if anyone
else has ideas for similar improvements or sees any problem with the
changes:

1. In response to a user's blog post [1] about how to run ssl-cert.nse on
RDP servers, I added port 3389 to the list of LIKELY_SSL_PORTS in
shortport.lua and to the list of sslports in the TerminalServer probe in
nmap-service-probes (r34108). Unfortunately, when testing against Windows
8.1's Remote Assistance service, none of Nmap's service probes yield any
response. The rdp-enum-encryption script does get a valid response, though,
so maybe we should add a service probe based on that?

2. The TLS implementation for Windows RDP doesn't support SSLv3 at all, so
it silently drops the SSLSessionReq probe. From working with
ssl-enum-ciphers, I know that other implementations do this with protocol
mismatches. Given the trend towards eliminating SSLv3 on the Internet, it's
likely that more services will fail to be detected as TLS by -sV.

We cannot modify the SSLSessionReq probe to be more compatible, since there
are match lines for several different protocols under it (which may respond
differently if the probe data is different). Instead, I added a new probe
in r34109, TLSSessionReq, that is a ClientHello message claiming to support
any version from SSLv3 to TLSv1.2. We will avoid adding any
product-specific match lines below this probe, and use it *only* to detect
a TLS wrapper (-sV will then restart detection within the TLS tunnel). I
gave this probe a very conservative "rarity" of 7 (in r34110) so that it
will run by default, but still allow SSLSessionReq to run first, since
that's what the file is tuned for.

3. Some services are explicitly intended to be SSL-wrapped: ircs, smtps,
imaps, pop3s, ftps, telnets. Where necessary, I added these to the ports
directive of the SSL/TLS probes so that those probes could run first and
detect the SSL tunnel (r34110). (I use "SSL" here because these are
generally deprecated or unused services and not likely to be using modern
TLS). In a few cases, I moved these ports to the "sslports" sections of
probes that are intended to detect the service within the tunnel.

The upshot of all this is that service detection should go a little bit
faster, since the most appropriate probes ought to be sent to the most
likely ports, resulting in fewer probes sent before a match is found.

There is still research to be done regarding RDP; In addition to a plain
TLS wrapper, there's a kind of "STARTTLS" support as well. I think that a
TLS tunnel can always be established right away (if supported at all), but
if there is a configuration that only allows TLS after establishing an RDP
connection, then a "specialized SSL connection function" ought to be
written in the sslcert.lua library.

Dan

[1] http://webstersprodigy.net/2015/04/01/rdp-cert-scan-with-nmap/

_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/