2

I am trying to scan an endpoint to see what TLS version it is running and I am seeing some discrepancy between the nmap scan and the openssl scan. Scanning the same host I see only TLSv1.0 from nmap (7.40) and I can see TLSv1.2 with openssl (1.0.1e). I also scan the same host with Qualys SSL Labs and it seem to be getting TLSv1.2 also. So I was wondering why nmap is only showing TLSv1.0? (result of scan below)

nmap scan:

localhost:~ localuser$ nmap -sV --script ssl-enum-ciphers -p 443 example.com

Starting Nmap 7.40 ( https://nmap.org ) at 2017-02-11 13:13 PST
Nmap scan report for example.com (###.###.###.###)
Host is up (0.016s latency).
PORT    STATE SERVICE  VERSION
443/tcp open  ssl/http Apache Tomcat/Coyote JSP engine 1.1
|_http-server-header: Apache-Coyote/1.1
| ssl-enum-ciphers:
|   TLSv1.0:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp192r1) - D
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp192r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp192r1) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|     compressors:
|       NULL
|     cipher preference: client
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|       Key exchange (secp192r1) of lower strength than certificate key
|_  least strength: D

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 24.51 seconds
localhost:~ localuser$

openssl scan

SSL handshake has read 8589 bytes and written 453 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 589F81CE166178A7DA49EC4EF9F86412FA161E6B4C54CB65E7111784B48A2054
    Session-ID-ctx:
    Master-Key: 94179213B34A8DCA54A4AD23661E2C8EBF3E46BC0E251426DC377FD27513584B9C978357CAE0663AF77B488AC6158887
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1486848462
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
YTKColumba
  • 43
  • 1
  • 3
  • 6
  • This is likely a bug in ssl-enum-ciphers, and I'd like to get it fixed. Can you run the command again without `-sV` and with `-d`? There will be a lot of output, but you can limit it to just the lines containing "ssl-enum-ciphers". – bonsaiviking Feb 13 '17 at 14:32
  • @bonsaiviking here's the output for -d flag https://gist.github.com/anonymous/5f2d8d1c9af8139fbdc68cffbf5abf16 looks like TLSv1.1 and TLSv1.2 was rejected? – YTKColumba Feb 13 '17 at 15:07
  • Ok, I can see how the line might be generated due to some alert that doesn't actually mean the protocol is rejected, but now I wonder what the alert was? I either need permission to scan, a packet capture, or you add `ctx_log(1, protocol, "Protocol rejected: %s, %s", alert.protocol, alert.description)` at line 608 of ssl-enum-ciphers.nse and provide debug output again. dmiller at nmap dot org – bonsaiviking Feb 15 '17 at 03:57
  • Oops, had a bug in that ctx_log line. Should be `alert.body[1].description` instead of `alert.description` – bonsaiviking Feb 15 '17 at 13:43
  • @bonsaiviking, here's the new scan with the line 608 replacement you provided: https://gist.github.com/anonymous/6b74e2ab7f2447e4dae4ea15757148d6 – YTKColumba Feb 17 '17 at 17:40
  • Thanks; I'm trying to figure out what it is that is wrong with the TLS 1.1 and 1.2 handshake messages that could be causing `illegal_parameter` alerts. I'm guessing it might have to do with sending SSLv3-compatible handshakes, but I don't have any evidence. Could you contact me privately with more info about how the target is set up so I can try to reproduce? dmiller at nmap.org – bonsaiviking Feb 17 '17 at 23:22

2 Answers2

1

The ssl-enum-ciphers nmap script is only telling you about the ciphersuites that a server supports. It does not tell you the maximum SSL/TLS version a server supports. Each ciphersuite is defined for a set of SSL/TLS versions. nmap is telling you that the 6 ciphersuites listed are defined from version TLSv1.0 upwards (including TLSv1.1. and TLSv1.2).

Matt Caswell
  • 111
  • 2
  • This is incorrect; Nmap will list the same list multiple times, each under a different TLS version, if that is what it detects the target as supporting. – bonsaiviking Feb 13 '17 at 14:19
  • ok, that makes sense, but one other questions is for the nmap scan that does list TLSv1.1 and TLSv1.2, does that mean the cipher they use are only for TLSv1.1 and TLSv1.2? – YTKColumba Feb 13 '17 at 14:52
  • @bonsaiviking - you are correct. I'd withdraw my answer if I knew how :-). An interesting aspect I missed in the original question is that openssl negotiates ECDHE-RSA-AES256-GCM-SHA384, which is a TLSv1.2 only ciphersuite that is entirely missing from the nmap output. – Matt Caswell Feb 13 '17 at 15:28
1

This was a bug of sorts in ssl-enum-ciphers. It can be quite difficult to handle all the different implementations of TLS, and in this case, the script interpreted an alert message with a mismatched TLS version as a rejection of the TLS version that the script attempted. I confirmed with another system on the Internet that this behavior was not actually a rejection of the protocol version, but instead a rejection of the offered cipher suites. To make things more complicated, if a cipher is supported in one version (TLS 1.1) but not in another (TLS 1.2), this server will just switch versions to the one that supports the cipher, even if that protocol version was not offered by the client!

I made a few changes to the script that should handle these weird edge cases. Scanning this server takes longer than a more RFC-compliant one, but it does work now. You can get the updated script via the Download link on the NSEdoc page I linked above, and it will be included in the next Nmap release.

bonsaiviking
  • 4,420
  • 17
  • 26