Errors while running ssl-enum-ciphers

I'm getting some errors while running nmap with --script ssl-enum-ciphers.

Maybe the domain name is too long? It has 24 chars in total, including dots. Estructure is: xxxxxxx.xxxxxxxxx.xxx.xx

Nmap vers: 7.70, over kali lnux. Same results in Windows server 2012.

nmap -d --script ssl-enum-ciphers -p 11443 xxxxx.xxxxxxxx.xx.xx nmap -d --script ssl-enum-ciphers -p 443 xxxxx.xxxxxxxx.xx.xx

Both ports have the same result: .. .. Initiating NSE at 09:33 NSE: Starting ssl-enum-ciphers against xxxxx.xxxxxxxx.xx.xx (xxxxxxx:11443). NSE: [ssl-enum-ciphers xxxxxx:11443] Trying protocol TLSv1.1. NSE: [ssl-enum-ciphers xxxxxx:11443] Trying protocol SSLv3. NSE: [ssl-enum-ciphers xxxxxx:11443] Trying protocol TLSv1.0. NSE: [ssl-enum-ciphers xxxxxx:11443] Trying protocol TLSv1.2. NSE: ssl-enum-ciphers against xxxxxx.xxxxxx.xxxxxx.xx (xxxxxx:11443) threw an error! /usr/bin/../share/nmap/nselib/tls.lua:1209: bad argument #2 to 'unpack' (data string too short) stack traceback: [C]: in function 'string.unpack' /usr/bin/../share/nmap/nselib/tls.lua:1209: in local 'parser' /usr/bin/../share/nmap/nselib/tls.lua:1270: in local 'parser' /usr/bin/../share/nmap/nselib/tls.lua:1309: in function 'tls.parse_messages' /usr/bin/../share/nmap/nselib/tls.lua:1369: in function 'tls.record_read' /usr/bin/../share/nmap/scripts/ssl-enum-ciphers.nse:339: in local 'get_next_record' /usr/bin/../share/nmap/scripts/ssl-enum-ciphers.nse:391: in upvalue 'try_params' /usr/bin/../share/nmap/scripts/ssl-enum-ciphers.nse:603: in upvalue 'find_ciphers_group' /usr/bin/../share/nmap/scripts/ssl-enum-ciphers.nse:811: in upvalue 'find_ciphers' /usr/bin/../share/nmap/scripts/ssl-enum-ciphers.nse:987: in function </usr/bin/../share/nmap/scripts/ssl-enum-ciphers.nse:981> NSE: ssl-enum-ciphers against xxxxx.xxxxxxxx.xx.xx (xxxxxx:11443) threw an error! /usr/bin/../share/nmap/nselib/tls.lua:1209: bad argument #2 to 'unpack' (data string too short) stack traceback: [C]: in function 'string.unpack' /usr/bin/../share/nmap/nselib/tls.lua:1209: in local 'parser' /usr/bin/../share/nmap/nselib/tls.lua:1270: in local 'parser' /usr/bin/../share/nmap/nselib/tls.lua:1309: in function 'tls.parse_messages' /usr/bin/../share/nmap/nselib/tls.lua:1369: in function 'tls.record_read' /usr/bin/../share/nmap/scripts/ssl-enum-ciphers.nse:339: in local 'get_next_record' /usr/bin/../share/nmap/scripts/ssl-enum-ciphers.nse:391: in upvalue 'try_params' /usr/bin/../share/nmap/scripts/ssl-enum-ciphers.nse:603: in upvalue 'find_ciphers_group' /usr/bin/../share/nmap/scripts/ssl-enum-ciphers.nse:811: in upvalue 'find_ciphers' /usr/bin/../share/nmap/scripts/ssl-enum-ciphers.nse:987: in function </usr/bin/../share/nmap/scripts/ssl-enum-ciphers.nse:981> NSE: ssl-enum-ciphers against xxxxx.xxxxx.xxxx.xx (xxxxxx:11443) threw an error! /usr/bin/../share/nmap/nselib/tls.lua:1209: bad argument #2 to 'unpack' (data string too short) stack traceback: [C]: in function 'string.unpack' /usr/bin/../share/nmap/nselib/tls.lua:1209: in local 'parser' /usr/bin/../share/nmap/nselib/tls.lua:1270: in local 'parser' /usr/bin/../share/nmap/nselib/tls.lua:1309: in function 'tls.parse_messages' /usr/bin/../share/nmap/nselib/tls.lua:1369: in function 'tls.record_read' /usr/bin/../share/nmap/scripts/ssl-enum-ciphers.nse:339: in local 'get_next_record' /usr/bin/../share/nmap/scripts/ssl-enum-ciphers.nse:391: in upvalue 'try_params' /usr/bin/../share/nmap/scripts/ssl-enum-ciphers.nse:603: in upvalue 'find_ciphers_group' /usr/bin/../share/nmap/scripts/ssl-enum-ciphers.nse:811: in upvalue 'find_ciphers' /usr/bin/../share/nmap/scripts/ssl-enum-ciphers.nse:987: in function </usr/bin/../share/nmap/scripts/ssl-enum-ciphers.nse:981> .. .. .. Note: The output without the debugging option mention nothing about TLS's founds, just say https service found in port. Other tools as testssl.sh detect the offered TLS's, so looks like they are there.

Best regards

This is very odd. I can see where the certificate message parsing function ran off the end of the certificate chain, since there's not an explicit check for that. That's an easy fix. But there's no good reason why it would be doing that if the certificates are correct. Can you do the same test but add --script-trace to your options and report at least the hex dump from one of the certificate messages? It will look something like:

NSE: TCP 72.14.177.105:45018 < 45.33.49.119:443 | 00000000: 16 03 03 00 50 02 00 00 4c 03 03 b3 8b 90 9c 00     P   L
00000010: b4 08 03 98 39 0e 34 51 90 ac 8f 9e c2 7a c8 4f     9 4Q     z O
00000020: be 64 01 48 b8 54 91 da 41 10 41 20 61 db 4b 1d  d H T  A A a K
00000030: c2 97 30 48 f2 96 b1 ac 40 12 eb 16 c9 b2 02 f4   0H    @
00000040: 7f 57 78 96 e4 3f f8 6c 13 de 00 5d 00 07 00 00  Wx  ? l   ]
00000050: 04 00 00 00 00 16 03 03 10 d4 0b 00 10 d0 00 10
00000060: cd 00 05 40 30 82 05 3c 30 82 04 24 a0 03 02 01    @0  <0  $
00000070: 02 02 10 6d 54 14 a6 12 28 25 98 05 97 15 32 7a    mT   (%    2z
00000080: dc ca c8 30 0d 06 09 2a 86 48 86 f7 0d 01 01 0b    0   * H
00000090: 05 00 30 81 90 31 0b 30 09 06 03 55 04 06 13 02   0  1 0   U
000000a0: 47 42 31 1b 30 19 06 03 55 04 08 13 12 47 72 65 GB1 0   U    Gre
000000b0: 61 74 65 72 20 4d 61 6e 63 68 65 73 74 65 72 31 ater Manchester1
000000c0: 10 30 0e 06 03 55 04 07 13 07 53 61 6c 66 6f 72  0   U    Salfor
000000d0: 64 31 1a 30 18 06 03 55 04 0a 13 11 43 4f 4d 4f d1 0   U    COMO
000000e0: 44 4f 20 43 41 20 4c 69 6d 69 74 65 64 31 36 30 DO CA Limited160
000000f0: 34 06 03 55 04 03 13 2d 43 4f 4d 4f 44 4f 20 52 4  U   -COMODO R
00000100: 53 41 20 44 6f 6d 61 69 6e 20 56 61 6c 69 64 61 SA Domain Valida
00000110: 74 69 6f 6e 20 53 65 63 75 72 65 20 53 65 72 76 tion Secure Serv
00000120: 65 72 20 43 41 30 1e 17 0d 31 38 30 33 31 36 30 er CA0   1803160
00000130: 30 30 30 30 30 5a 17 0d 32 30 30 33 31 35 32 33 00000Z  20031523
00000140: 35 39 35 39 5a 30 4c 31 21 30 1f 06 03 55 04 0b 5959Z0L1!0   U
00000150: 13 18 44 6f 6d 61 69 6e 20 43 6f 6e 74 72 6f 6c   Domain Control
00000160: 20 56 61 6c 69 64 61 74 65 64 31 14 30 12 06 03  Validated1 0
00000170: 55 04 0b 13 0b 50 6f 73 69 74 69 76 65 53 53 4c U    PositiveSSL
00000180: 31 11 30 0f 06 03 55 04 03 13 08 6e 6d 61 70 2e 1 0   U    nmap.
00000190: 6f 72 67 30 82 01 22 30 0d 06 09 2a 86 48 86 f7 org0  "0   * H

etc.

Hello, nmap -d --script-trace --script ssl-enum-ciphers -p 11443 xeptpre.mitramiss.gob.es namp w --script-trace.txt Atached a txt with full output. Let me know if you need something elst. and, thank you very much for your help!!

Thanks, that's helpful. It seems there's something wrong with the ServerCertificate message; even Wireshark isn't parsing it correctly. What I see is a ServerCertificate message with length 0x4000, an oddly round number, with a long chain of certificates. It is followed by another Handshake-protocol message without a proper header that is also full of certificate data. As tls.lua is parsing through the certificates, it gets off by 1 byte, which has essentially no chance of happening without corruption of the data, since each certificate is length-prefixed and the first 7 certs parse just fine. I think there may be a bug in your server's code that can't cope with so many certificates.

I could be wrong. Maybe I'm reconstructing the packet data incorrectly. A packet dump would be ideal, as well as confirmation from openssl s_client that handshaking can actually succeed.

I'm going to add a simple check that will avoid crashes in this case. It will simply bail and jump to the end of the TLS record if there's a problem, which should allow scripts to continue as before; most NSE scripts will be able to get the information they want from the ServerHello message without needing to parse the whole cert chain.

Thanks a lot. Actually Im not sure I understand all of what you say :) but will try to test if the openssl s_cliente handshake is happening.

Best regards

nmap / nmap

Errors while running ssl-enum-ciphers #1399