NSE scripts do not run on every port, which would generate lots of unnecessary traffic. Instead, they try to intelligently guess which ports are best for them to run on using a function called the "rule". The rule for ssl-enum-ciphers causes it to be run on about 15 ports that traditionally have SSL/TLS on them (e.g. 443, 992-995, etc.), or on ports that have been detected by -sV as having an SSL transport. Since you did not use -sV and port 6666 is not one of the traditional SSL ports, ssl-enum-ciphers will not run against it.

The quickest way to get ssl-enum-ciphers to run on unusual ports is to add the -sV --version-intensity 1 options to use Nmap's service version detection engine to detect the SSL service. The SSL probe has rarity 1 so the --version-intensity 1 will allow it to be sent, but avoid sending lots of other probes that are not necessary and could slow down the scan.

Another option (not recommended for general-purpose port scanning) is to use --script +ssl-enum-ciphers which will bypass the rule and execute the script on all scanned ports. This can be handy for cases where you know what service is running on a single port, and want to run the script on that port alone in one command. But if you use this with a regular port scan of thousands of ports, it will send lots of unnecessary traffic to non-SSL services, which is noisy and potentially dangerous.

Thanks for the info, @dmiller-nmap
nmap --script +ssl-enum-ciphers localhost -p 6666
did the trick.

I think this particular script is usually used on specific port, where SSL/TLS service is expected, so bypassing the rule could be the default mode for this script (if it can be done on the script level). That's the way other cipher suite testing tools work (sslyze.py, testssl.sh, etc.).

@MichalStaruch Thanks for the challenge. I just committed r34677 and r34678 which should let ssl-enum-ciphers be used in this manner safely. It only works when the script is selected by name and -sV is not used or failed to detect a service.

@dmiller-nmap I've just checked the latest 6.49SVN (commit 06e6062) and now all 3 commands, that is
nmap --script ssl-enum-ciphers localhost -p 6666
nmap --script +ssl-enum-ciphers localhost -p 6666
nmap -sV --script ssl-enum-ciphers localhost -p 6666
are broken, cipher suite test is omitted in every case.

Did you perform any checks prior to pushing this change? On my side it's simple HTTPS (limited to TLSv1.2 and 4 strong cipher suites) moved to port 6666.

@MichalStaruch Yes, I tested, but I'm pretty sure I know what's wrong. TLSv1.2 adds extensions for supported signature algorithms, and if they're missing, it assumes SHA1. Your server cert is probably SHA2 (a good thing!), so your TLS engine just drops the connection attempt (I used our older probe, which is SSLv3 only). This is why I added the TLSSessionRequest probe to -sV recently. I'm a little confused why -sV didn't work, but in r34681 I moved the extra probe test into the portrule function, so the "+force" syntax should work again. Additionally, I added the TLSSessionRequest probe to the set of probes the script uses if -sV was not used, so all the variants you listed ought to work as soon as our bot syncs Github with SVN (it will put a mention into this thread).

@dmiller-nmap Yup, SHA-2-384 here. SHA-1 is nice alternative for CRC32, but not really good choice for collision-resistant signatures :). Anyway - nmap works fine, now (commit a881712), except the
nmap -sV --script ssl-enum-ciphers localhost -p 6666
variant, which recognizes http service, but doesn't run cipher suite tests unless forced with +. Good enough for my humble needs, though.

@MichalStaruch I'm glad it's working for you.

I'd guess your web server (Apache does this) responds to plaintext HTTP requests on HTTPS ports with a redirect or error message; this is challenging to check for, since -sV needs to send plaintext queries first since those services are more popular. If you send a copy of the output of this command to dev@nmap.org, we can maybe put in a special signature to detect it as SSL anyway:

(echo -e 'GET / HTTP/1.0\r\n\r\n'; sleep 3) | ncat localhost 6666

@dmiller-nmap Output sent to dev@nmap.org.

I came across this super old issue - remapping the port to some local matching port using ssh or netcat helped.

@hphde This issue has been solved since Nmap 6.49BETA6, released almost 2 years ago. If you are still experiencing this with Nmap 7.60, please open a new issue so that we can solve your problem.