The Network Security Services Engine (NSE) is a critical component of Nmap, enabling advanced network scanning capabilities. However, users may encounter situations where specific NSE scripts, like ssl-cert, fail to function as expected. This article explores potential reasons why NSE might not be working and provides troubleshooting steps. One common issue arises when targeting different hostnames or IP addresses on specific ports. For instance, the ssl-cert script might work flawlessly when targeting “localhost” but fail against “127.0.0.1”, even though both resolve to the same IP address.
This discrepancy often stems from how applications handle these addresses. While they ultimately point to the loopback interface, software might interpret and configure connections differently based on the provided hostname. Using a Logstash TCP input with SSL on a non-standard port, like 6514, can exacerbate the issue. This is because the ssl-cert script relies on establishing a successful SSL/TLS handshake to retrieve certificate information. Variations in SSL/TLS configurations between the target service and the script can lead to connection failures. In contrast, connecting to an Nginx server listening on the standard HTTPS port (443) usually works seamlessly, highlighting potential port-specific or application-specific issues.
$ nmap -Pn -n --script +ssl-cert -p 6514 localhost --packet-trace Starting Nmap 7.01 ( https://nmap.org ) at 2016-02-18 14:15 EET CONN (0.3485s) TCP localhost > 127.0.0.1:6514 => Operation now in progress CONN (0.3485s) TCP localhost > 127.0.0.1:6514 => Connected NSOCK INFO [0.3470s] nsock_iod_new2(): nsock_iod_new (IOD #1) NSOCK INFO [0.3490s] nsock_connect_ssl(): SSL connection requested to 127.0.0.1:6514/tcp (IOD #1) EID 9 NSOCK INFO [0.4540s] nsock_trace_handler_callback(): Callback: SSL-CONNECT SUCCESS for EID 9 [127.0.0.1:6514] NSE: TCP 127.0.0.1:33968 > 127.0.0.1:6514 | CONNECT NSE: TCP 127.0.0.1:33968 > 127.0.0.1:6514 | CLOSE NSOCK INFO [0.4540s] nsock_iod_delete(): nsock_iod_delete (IOD #1) Nmap scan report for localhost (127.0.0.1) Host is up (0.00015s latency). Other addresses for localhost (not scanned): ::1 PORT STATE SERVICE 6514/tcp open unknown | ssl-cert: Subject: [...] | Public Key type: rsa | Public Key bits: 2048 [...] Nmap done: 1 IP address (1 host up) scanned in 0.46 seconds The above output shows a successful ssl-cert script execution against localhost on port 6514. Nmap successfully establishes an SSL connection and retrieves the certificate details. Troubleshooting such issues requires careful examination of network configurations, firewall rules, and the target service’s SSL/TLS settings. Verifying that the target service is properly configured to accept SSL/TLS connections on the specified port is crucial. Additionally, checking for any network restrictions or firewall rules blocking the connection attempt is essential.
$ nmap -Pn -n --script +ssl-cert -p 6514 127.0.0.1 --packet-trace Starting Nmap 7.01 ( https://nmap.org ) at 2016-02-18 14:15 EET CONN (0.3503s) TCP localhost > 127.0.0.1:6514 => Operation now in progress CONN (0.3503s) TCP localhost > 127.0.0.1:6514 => Connected NSOCK INFO [0.3480s] nsock_iod_new2(): nsock_iod_new (IOD #1) NSOCK INFO [0.3500s] nsock_connect_ssl(): SSL connection requested to 127.0.0.1:6514/tcp (IOD #1) EID 9 NSOCK INFO [0.3540s] handle_connect_result(): EID 9 reconnecting with SSL_OP_NO_SSLv2 NSOCK INFO [0.3540s] handle_connect_result(): EID 9 error:140750DD:SSL routines:ssl23_connect:ssl23 doing session id reuse NSOCK INFO [0.3540s] nsock_trace_handler_callback(): Callback: SSL-CONNECT ERROR [Input/output error (5)] for EID 9 [127.0.0.1:6514] NSE: TCP 127.0.0.1:33995 > 127.0.0.1:6514 | CONNECT NSE: TCP 127.0.0.1:33995 > 127.0.0.1:6514 | CLOSE NSOCK INFO [0.3540s] nsock_iod_delete(): nsock_iod_delete (IOD #1) Nmap scan report for 127.0.0.1 Host is up (0.00012s latency). PORT STATE SERVICE 6514/tcp open unknown Nmap done: 1 IP address (1 host up) scanned in 0.36 seconds Conversely, this output demonstrates the ssl-cert script failing against 127.0.0.1 on the same port. The SSL connection fails, preventing the script from obtaining the certificate. The error message suggests a potential problem with SSL session reuse or SSLv2 negotiation. Further investigation into the target service’s SSL/TLS configuration is necessary. Using packet capture tools like tcpdump or Wireshark can provide deeper insights into the network traffic and pinpoint the exact point of failure during the SSL/TLS handshake. Examining the SSL/TLS negotiation process can help identify mismatched cipher suites, protocol versions, or certificate validation issues.
