I'm trying to use the nmap script ssl-dh-params to identify what specific 1024-bit Diffie-Hellman group a TLS server is using. However, the script is not giving me any output at all and I can't figure out why:

C:\Users\user3553031>nmap -p 1234 --script=ssl-dh-params
Starting Nmap 7.70 ( https://nmap.org ) at 2018-07-09 17:55 Pacific Daylight Time
Nmap scan report for somehost.somedomain (
Host is up (0.022s latency).

1234/tcp open  unknown
MAC Address: 01:01:01:01:01:01 (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 3.34 seconds

I know that there is a TLS listener on that port and that it supports DHE ciphersuites: the script ssl-enum-ciphers gives output including the following:

1234/tcp open  unknown syn-ack ttl 55
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 1024) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 1024) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 1024) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 1024) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       Key exchange (dh 1024) of lower strength than certificate key
|_  least strength: A

That also tells me that scripting is not completely broken in my nmap build. I know that the script is installed because when I try to run a script with a nonsense name, I get an error. So it seems that the preconditions to ssl-dh-params are satisfied. Yet I get no output from it, or from nmap to indicate that tried to run that script at all, even when I run nmap with -vvvvv -ddddd.

What's going on? Am I making some mistake? Is the script broken?

2 Answers 2


Nmap's scripts require the "rule" function to return true before they will run against a target. The rule function for ssl-dh-params checks for common SSL port numbers, but also for whether version detection (-sV) found SSL present. You can get it to work on any port easily by adding -sV, or if you are in a hurry, -sV --version-light.

Because ssl-enum-ciphers is a very popular script that people often request to run on unusual ports, we expanded the rule function for that script to also send some SSL-detecting probes if version detection was not requested. We didn't make this change to other ssl-* scripts because fewer users complained of missing results in this way. We'll consider adding this to other scripts in the future.

EDIT: Today I moved the extra probing code from ssl-enum-ciphers into the shortport.ssl function so that all SSL/TLS-related scripts can work the same way. The probes will only be sent once per port; the result is cached and will be checked by the other scripts as needed. Watch for it in the next Nmap release.

  • It doesn't work for me with -sV on port 443 on a host which has DH TLS ciphers... Jan 31 at 20:01

You might want to check the script source code in /usr/share/nmap/scripts.

From what I can see it seems to have a portrule i.e. a rule that deciedes if the script is actually applicable for this port:

portrule = function(host, port)
  return shortport.ssl(host, port) or sslcert.getPrepareTLSWithoutReconnect(port)

From the doucmentation it would seem that shortport.ssl checks if the port is a common ssl port. So maybe that is the issue here. Try copying the NSE Script and modifying the return line (I did not test this myself):

portrule = function(host, port)
  return shortport.port_or_service(1234,"ssl")

Check out the NSE Script Writing Tutorial for more info on rules.

  • I modified it to always return true and the script still doesnt execute Jan 31 at 20:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.