Назад | Перейти на главную страницу

Несоответствие сканирования версий TLS между nmap, openssl, ssllab

Я пытаюсь просканировать конечную точку, чтобы узнать, какая версия TLS на ней запущена, и вижу некоторое расхождение между сканированием nmap и сканированием openssl. Сканируя тот же хост, я вижу только TLSv1.0 из nmap (7.40), и я вижу TLSv1.2 с openssl (1.0.1e). Я также сканирую тот же хост с помощью Qualys SSL Labs, и, похоже, он также получает TLSv1.2. Так что мне было интересно, почему Nmap показывает только TLSv1.0? (результат сканирования ниже)

сканирование 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

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

В ssl-enum-ciphers скрипт nmap только рассказываю вам о наборы шифров что сервер поддерживает. Оно делает не сообщить вам максимальную версию SSL / TLS, поддерживаемую сервером. Каждый набор шифров определяется для набора версий SSL / TLS. Nmap сообщает вам, что перечисленные 6 шифровальных наборов определены начиная с версии TLSv1.0 и выше (включая TLSv1.1. и TLSv1.2).

Это была своего рода ошибка в ssl-enum-ciphers. Обработка всех различных реализаций TLS может быть довольно сложной, и в этом случае сценарий интерпретировал предупреждающее сообщение с несоответствующей версией TLS как отклонение версии TLS, которую попытался выполнить сценарий. Я подтвердил с помощью другой системы в Интернете, что такое поведение на самом деле было не отклонением версии протокола, а отказом от предлагаемых наборов шифров. Чтобы усложнить задачу, если шифр поддерживается в одной версии (TLS 1.1), но не в другой (TLS 1.2), этот сервер просто переключит версии на ту, которая поддерживает этот шифр, даже если эта версия протокола не была предложена клиент!

Я внес несколько изменений в скрипт, который должен обрабатывать эти странные крайние случаи. Сканирование этого сервера занимает больше времени, чем сервер, более совместимый с RFC, но теперь он работает. Вы можете получить обновленный скрипт по ссылке Download на странице NSEdoc, на которую я ссылался выше, и он будет включен в следующий выпуск Nmap.