Discrepância na varredura da versão TLS entre nmap, openssl, ssllab

Question

Estou tentando verificar um ponto de extremidade para ver qual versão do TLS está sendo executada e estou vendo alguma discrepância entre a varredura do nmap e a varredura do openssl. Analisando o mesmo host, vejo apenas o TLSv1.0 do nmap (7.40) e consigo ver o TLSv1.2 com o openssl (1.0.1e). Eu também escaneio o mesmo host com Qualys SSL Labs e parece estar recebendo TLSv1.2 também. Então eu estava me perguntando por que o nmap está mostrando apenas TLSv1.0? (resultado da digitalização abaixo)

varredura do nmap:

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)
---

    

Answer 1

O script ssl-enum-ciphers nmap é apenas informando sobre os ciphersuites que um servidor suporta. Ele não informa a versão máxima de SSL / TLS que um servidor suporta. Cada ciphersuite é definido para um conjunto de versões SSL / TLS. O nmap está informando que os 6 ciphersuites listados são definidos a partir da versão TLSv1.0 para cima (incluindo TLSv1.1 e TLSv1.2).

    

Answer 2

Este foi um tipo de erro em ssl-enum-ciphers . Pode ser muito difícil lidar com todas as implementações diferentes do TLS e, nesse caso, o script interpretou uma mensagem de alerta com uma versão TLS incompatível como uma rejeição da versão do TLS que o script tentou. Eu confirmei com outro sistema na Internet que esse comportamento não era na verdade uma rejeição da versão do protocolo, mas sim uma rejeição dos pacotes de criptografia oferecidos. Para tornar as coisas mais complicadas, se uma cifra for suportada em uma versão (TLS 1.1), mas não em outra (TLS 1.2), este servidor apenas trocará as versões para a que suporta a cifra, mesmo que essa versão de protocolo não fosse oferecida por o cliente!

Eu fiz algumas alterações no script que devem lidar com esses casos estranhos. A varredura deste servidor leva mais tempo do que um mais compatível com RFC, mas funciona agora. Você pode obter o script atualizado através do link Download na página do NSEdoc que eu criei acima, e ele será incluído na próxima versão do Nmap.