Как узнать версию tls linux

Проверка сервера Linux на поддержку TLS

TLS — это аббревиатура от Transport Layer Security. TLS облегчает безопасную связь между компьютерами в Интернете. На момент написания этой статьи TLS 1.3 является последней версией. Эта инструкция объясняет, как вы можете проверить, какие версии TLS поддерживает ваш сервер или веб-сайт работающие на сервере Linux. А также какой алгоритм шифрования используется.

Требования

• Сервер с операционной системой Linux
• Пользователь с привилегиями sudo

Проверка поддержки TLS с помощью Openssl

Openssl — это инструмент с открытым исходным кодом для реализации безопасных коммуникаций в Интернете. Инструмент openssl доступен во всех основных дистрибутивах Linux.

Если вдруг openssl не установлен на вашем компьютере или сервере Linux, вы можете установить его следующим образом.

В дистрибутивах на базе Ubuntu/Debian:

В дистрибутивах на базе CentOS/Red Hat:

Для того чтобы проверить поддержку TLSv1.3 на вашем сервере или веб-сайте, выполните следующую команду.

$ sudo openssl s_client -connect setiwik.ru:443 -tls1_3

Примечание: Не забудьте изменить проверяемый домен ‘setiwik.ru’, на свой домен.

Кроме того, вы можете заменить -tls1_3 на:

• -tls1_2 для TLSv1.2
• -tls1_1 для TLSv1.1
• -tls1 для TLSv1

Если вы видите цепочку сертификатов, а также сведения об успехе в выходных данных, то указанная версия TLS поддерживается. Если нет, то указанная версия TLS не поддерживается.

Цепочка сертификатов TLS Версия и шифрования TLS

Вы так же можете проверить поддерживается ли конкретное шифрование. Это можно сделать следующим образом.

$ openssl s_client -cipher ‘AES256-GCM-SHA384’ -connect setiwik.ru:443

Как и прежде, обратите внимание на цепочку сертификатов и успешный ответ, который подтверждает, что указанное шифрование поддерживается.

Проверка поддержки TLS с помощью Nmap

Nmap — это инструмент, который в основном используется для поиска доступных сервисов и портов в сети. Выполните приведенную ниже команду, чтобы установить Nmap.

В дистрибутивах на базе Ubuntu/Debian:

В дистрибутивах на базе CentOS/Red Hat:

После установки вы можете использовать инструмент nmap для тестирования вашего сервера или веб-сайта на поддержку TLS. Делается это следующим следующим образом.

Ниже приведен пример ответа, показывающий версию TLS и шифрования, которые поддерживает мой сервер.

Проверка поддержки TLS с помощью инструмента nmap

Заключение

В этом статье мы рассмотрели, как проверить поддерживает ли сервер или веб-сайт TLS с помощью openssl и nmap. Тест TLS может сказать вам, насколько сильна безопасность вашего сайта. Надеемся, что эта информация будет полезной для вас.

Источник

Командная строка для проверки версии TLS, требуемой хостом

Есть ли команда для проверки версии TLS, требуемой хост-сайтом. На данный момент я знаю, что единственный способ проверить это настроить максимальную версию TLS в моем браузере и проверить, могу ли я получить доступ к сайту. Однако я подозреваю, что есть более изощренный способ сделать это.

4 ответа

Вы можете проверить, используя следующие команды

openssl s_client -connect www.google.com:443 -tls1_2

openssl s_client -connect www.google.com:443 -tls1_1

openssl s_client -connect www.google.com:443 -tls1

Если вы получаете цепочку сертификатов и рукопожатие, то поддерживается версия tls. Если вы не видите цепочку сертификатов и что-то похожее на «ошибку рукопожатия», значит, это не так.

Другой вариант проверки поддержки версий SSL / TLS — это nmap. Nmap обычно не устанавливается по умолчанию, поэтому вам придется установить его вручную. После установки вы можете использовать следующую команду, чтобы проверить поддержку версии SSL / TLS…

$ nmap —script ssl-enum-ciphers -p 443 www.google.com

Сценарий nmap ssl-enum-ciphers не только проверяет поддержку версий SSL / TLS для всех версий (TLS 1.0, TLS 1.1 и TLS 1.2) за один раз, но также проверяет поддержку шифров для каждой версии, включая выставление оценок.

Кажется, самый изощренный способ — это проверить для каждой версии вот так:

Источник

Как узнать версию TLS и как обновить ее до TLS v1.3

У меня есть сервер Ubuntu 16.04, и я хотел бы знать, что версия TLS уже установлена на моем сервере.

И как перейти на версию 1.3, если версия версии под v1.3

3 ответа

Хотя вы не указываете это, вы, вероятно, спрашиваете о поддержке TLS на вашем веб-сервере и / или почтовом сервере. Для распространенных серверов в Linux поддержка реализована с помощью OpenSSL. Поскольку вы используете Ubuntu 16.04, у вас по умолчанию установлена версия OpenSSL 1.0.2, которая поддерживает TLS до TLS 1.2. Но учтите, что конфигурация серверов может привести к ограничению фактической поддержки протокола.

Официального TLS 1.3 пока нет, то есть протокол еще не завершен. Ожидается, что поддержка TLS 1.3 будет доступна в OpenSSL 1.1.1, которая все еще находится в разработке.

Обнюхивание пакетов с помощью какого-либо приложения, такого как Wireshark, выявит информацию; версия протокола, используемая в соединении, указана в сообщении ServerHello или используйте инструмент http://ssl-checker.online-domain-tools.com, чтобы проверить

Я бы посоветовал вам использовать тестовый сайт SSL от Qualys. Если вы запустили свой веб-сервер с SSLProtocol +All для простого теста, он сообщит вам, какие протоколы SSLP обслуживаются вашими страницами, и даст рекомендации о том, какие из них следует и не следует использовать.

Кстати, я сделал повторяющуюся задачу для проверки своих сайтов; Даже сегодня я нашел что-то, что изменилось с тех пор, как я последний раз проверял 3 месяца назад.

Источник

Как узнать версию TLS, используемую веб-сайтом с расширением

При просмотре Интернета мы можем найти зашифрованные страницы и другие, которые не являются. Логически, ввод данных, заполнение формы или совершение покупки на сайте, который не зашифрован, может быть серьезной проблемой для нашей безопасности и конфиденциальности. Однако на сайтах, которые зашифрованы, также могут быть различия. Мы говорим о протоколе TLS и его различных версиях. В этой статье мы поговорим о Укажите TLS расширение, которое показывает нам, какую версию протокола TLS использует веб-сайт.

Различные версии протокола TLS

Сайты могут использовать разные версии протокола TLS для шифрования. Это то, что было с нами на протяжении многих лет и со временем обновилось. Это делает первые версии TLS 1.0 и TLS 1.1 устаревшими. На самом деле, некоторые браузеры по умолчанию даже не разрешают доступ к этим сайтам.

Поэтому может быть интересно узнать простым способом, какую версию протокола TLS использует веб-сайт. Последняя версия, как мы знаем, это 1.3. Они считаются безопасными и соответствуют текущим требованиям 1.2 и 1.3.

Эти две версии присутствуют на большинстве сайтов. Тем не менее, все еще есть много тех, кто продолжает использовать первые версии, которые уже устарели. Это расширение, о котором мы собираемся поговорить, имеет функцию показа пользователям точной версии, которую использует веб-сайт. Таким образом, мы всегда будем знать безопасность этого сайта.

IndicateTLS, расширение, которое указывает версию TLS

IndicatTLS это расширение, которое доступно для Mozilla Firefox , Как мы знаем, это один из самых популярных и используемых браузеров сегодня. Он имеет много ориентированных на безопасность плагинов, которые пользователи могут использовать на своих компьютерах. Цель этого расширения — указать, какую версию протокола TLS использует веб-сайт.

Первое, что мы должны сделать, это добавить плагин в нашем браузере. Мы всегда рекомендуем устанавливать расширения этого типа в официальном магазине. Таким образом, мы гарантируем, что программное обеспечение не было злонамеренно модифицировано и что мы не добавляем что-то, что может обернуться против нас. Поэтому мы получаем доступ к официальной ссылке Firefox хранения.

Процесс установки очень прост и быстр. Как только расширение будет успешно установлено, в адресной строке появится значок. Здесь он покажет нам версию протокола TLS, которую использует введенный нами веб-сайт.

Если мы нажмем на иконку, которая появляется в Адресная строка, окно будет отображаться, как мы видим на изображении выше. Он покажет нам всю информацию, касающуюся этого сайта, относительно того, является ли он безопасным, и версию TLS, которую он использует. Мы увидим состояние подключения, шифрование, если включена предварительная загрузка HSTS и т. Д.

Также, более простым и быстрым способом, на том же значке мы увидим номер версии.

Короче говоря, IndicateTLS — это расширение для Mozilla Firefox, которое очень просто в использовании и показывает нам соответствующую информацию о веб-странице, которую мы посещаем. Мы уже знаем, что безопасность является фундаментальным фактором для пользователей, и мы можем использовать множество инструментов, которые помогают нам защитить себя. В этом случае это расширение, которое само по себе не защищает нас, но может дать нам интересную информацию, чтобы узнать, стоит ли нам доверять веб-сайту.

При просмотре Интернета вы должны учитывать важность правильного шифрования сайтов. Таким образом, наши данные будут в безопасности, и мы избежим проблем. Расширения браузера, которые мы используем, также могут нам помочь. Таким образом, они будут работать как дополнение к антивирусу, который мы можем установить в системе.

Источник

Проверка параметров SSL/TLS-серверов в консоли FreeBSD

Если Вы захотите выяснить параметры SSL/TLS некоторого публичного HTTPS-сервера, Вам поможет не нуждающийся в представлении SSL Server Test от Qualys SSL Labs. А что делать, если потребуется проверить аналогичные параметры HTTPS-серверов, доступ к которым ограничен, или серверов FTP, IRC, IMAP, POP3, SMTP, XMPP и PostgreSQL, которые поддерживают SSL/TLS? Не думаю, что Вы сильно удивитесь, если я предложу воспользоваться популярными в мире Linux и Unix инструментами, к числу которых относятся OpenSSL, nmap и SSLScan.

Какие параметры мы будем проверять?

Эта заметка описывает относительно простые в использовании и доступные в большинстве операционных систем семейства Linux / Unix способы проверки таких параметров SSL/TLS-серверов, как свойства и отсутствие ошибок установки их собственных SSL-сертификатов (далее — сертификатов), свойства и корректность работы цепочек сертификатов, в состав которых входят серверные сертификаты, поддержка TLS-расширений Server Name Indication и OCSP stapling, поддержка SSL/TLS-протоколов (далее — протоколов), а также соответствующих им наборов шифров, и, наконец, наличие некоторых опасных уязвимостей. Невзирая на то, что для решения перечисленных задач хватит функциональности OpenSSL, я рекомендую Вам не игнорировать соответствующие возможности nmap и SSLScan, использование которых не требует специальной подготовки, а результаты работы предоставляются в более простой для восприятия форме.

Подготовка OpenSSL, nmap и SSLScan

Все действия, которые описаны в данной заметке, выполнялись на компьютере с операционной системой FreeBSD 9.3 RELEASE. Все упоминаемое программное обеспечение устанавливалось из обновленной коллекции портов. Обязательно учтите, что для корректного решения поставленной задачи требуется заменить устаревший пакет OpenSSL, входящий в состав FreeBSD, более свежим аналогом из коллекции портов. Для его установки необходимо выполнить команды:

Следует отметить, что выбор опции [X] ZLIB zlib compression support (добавление WITH=»ZLIB» в команду make install ) не является обязательным, но он будет полезен в том случае, если Вы планируете не только проверять параметры SSL/TLS-серверов, но и тестировать их на наличие уязвимостей.
После завершения установки OpenSSL нужно добавить в файл /etc/make.conf строку:

Теперь устанавливаемые порты будут использовать обновленный OpenSSL (порты, установленные до обновления OpenSSL, придется пересобрать).
Для установки nmap и SSLScan необходимо выполнить команды:

В связи с тем, что браузеры и другие SSL/TLS-клиенты используют корневые сертификаты из своих собственных хранилищ доверенных корневых сертификатов, поставщики сертификатов не рекомендуют устанавливать корневые сертификаты на серверы. Для избавления от проблем, связанных с отсутствием тех или иных корневых сертификатов, входящих в состав цепочек сертификации, достаточно установить порт security/ca_root_nss командами:

После завершения установки / переустановки перечисленных портов можно приступать к проверке параметров TLS/SSL-серверов.

Общий случай использования команды openssl s_client

Команда openssl s_client предназначена для установки соединения с удаленным SSL/TLS-сервером, передачи ему команд, приема результатов их выполнения и отображения информации об используемых параметрах SSL/TLS. Если команда не содержит ключ -connect host:port , выполняется подключение к серверу localhost:4433 . По умолчанию сведения о параметрах SSL/TLS имеют среднюю детальность (на мой взгляд, она устроит подавляющее большинство системных администраторов), если добавить ключ -brief — минимальную, ключи -debug и / или -tlsextdebug — повышенную. В общем случае для проверки параметров какого-либо SSL/TLS-сервера достаточно указать команду s_client и единственный ключ -connect host:port . Например, команда:

отобразит примерно такие сведения о HTTPS-сервере, на котором размещается мой персональный сайт (для сокращения размера данной заметки значительная часть содержимого сертификата сервера (Server certificate) и мандата сессии TLS (TLS session ticket) заменена точками):

Представленное сообщение содержит следующую информацию (для повышения удобства восприятия соответствующие группы строк выделены):
Строка 1 подтверждает факт установки соединения (CONNECTED);
Строки 2-8 содержат результат проверки цепочки сертификатов, использованной при установке соединения. Для каждого сертификата отображается глубина в цепочке сертификатов (depth), страна (C), организация (O), подразделение (OU), имя (CN) субъекта сертификации и результат проверки (verify return). Отсутствие части перечисленных сведений для бесплатного сертификата сервера связано с тем, что он не подтверждает принадлежность домена какой-либо организации;
Строки 9-14 отображают содержимое цепочки сертификатов, установленной на сервер (Certificate chain). Для каждого сертификата отображается назначение (s), содержащее, такие сведения, как страна (C), организация (O), подразделение (OU), имя (CN) субъекта сертификации и аналогичная информация об издателе (i). По описанной в предыдущем пункте причине для сертификата сервера отображаются только страна и имя субъекта сертификации;
Строки 15-23 содержат текст сертификата сервера в формате PEM, его назначение (subject) и информацию об издателе (issuer);
Строки 24-55 отображают подробную информацию как о параметрах сервера, так и о параметрах текущего соединения. В них можно увидеть, что используется современный (New) протокол TLSv1.2 и набор шифров (Cipher) ECDHE-RSA-AES256-GCM-SHA384 (такая аббревиатура обозначает, что для генерации сеансового ключа используется алгоритм Диффи-Хеллмана на эллиптических кривых, для аутентификации сервера — алгоритм RSA, для шифрования трафика — алгоритм AES с длиной ключа 256 бит в режиме GCM, для контроля целостности (MAC) — алгоритм SHA384), публичный ключ сервера (Server public key) имеет длину 2048 бит, сервер поддерживает возобновление TLS-сессии (Secure Renegotiation), не поддерживает сжатие (Compression) и т.д. и т.п.
В связи с тем, что даже минимальный вариант команды openssl s_client предоставляет внушительные объемы информации о параметрах SSL/TLS-серверов, имеет смысл внимательнее разобраться в том, какие сведения нам понадобятся, и как использовать их для решения наших задач.

Проверка сертификата сервера и цепочки сертификатов с помощью openssl s_client

Для проверки параметров и отсутствия ошибок установки сертификата сервера, а также корректности работы цепочки сертификатов, частью которой он является, подойдет все та же команда openssl s_client . В рассмотренном выше примере показан результат ее работы для случая, когда сертификат сервера установлен корректно, и цепочка сертификатов не содержит ошибок. Например, при подключении к SSL/TLS-серверу с просроченным самоподписным сертификатом будут отображены примерно такие сведения (сообщения об ошибках выделены, «лишние» данные заменены точками):

Для указания глубины верификации (или максимальной длины) цепочки сертификатов и включения проверки сертификата сервера необходимо добавить ключ -verify depth ( depth — глубина проверки). В настоящее время проверка продолжается при появлении сообщений об ошибках, что позволяет диагностировать все проблемы в цепочке сертификатов. При этом возникает побочный эффект, который заключается в том, что соединение не обрывается, даже если сертификат сервера признается некорректным.
Для прекращения проверки цепочки сертификатов при наличии критических ошибок следует указать ключ -verify_return_error . Например, его применение при проверке SSL/TLS-сервера с просроченным самоподписным сертификатом заметно сократит результат проверки цепочки сертификатов:

Для просмотра содержимого всех сертификатов цепочки сертификатов, а не только сертификата сервера нужно добавить ключ -showcerts .
Для проверки цепочки сертификатов, корневой сертификат которой отсутствует в хранилище доверенных корневых сертификатов, необходимо применить один из ключей -CApath или -CAfile . Первый ключ позволяет указать путь к папке, имеющей формат hash, с корневым сертификатом, второй — имя файла в формате PEM с корневым сертификатом. Описание формата hash и список ключей, позволяющих выполнять дополнительные проверки параметров сертификата сервера, можно найти в документе verify.

Проверка поддержки технологии Server Name Indication с помощью openssl s_client

Для проверки того, что SSL/TLS-сервер поддерживает технологию SNI (Server Name Indication) придется немного усложнить команду openssl s_client путем добавления ключей -servername (он включает TLS-расширение SNI путем изменения соответствующих полей сообщения ClientHello), а также -tlsextdebug (он включает отображение дампа TLS-расширений, полученных с сервера). В связи с тем, что из весьма внушительного объема предоставляемых данных нам будет нужна единственная строка с текстом server name, имеет смысл найти ее с помощью grep(1) и отправить все «лишние» сведения, отображаемые через stderr , в /dev/null (учтите, что перенаправлении данных в /dev/null может привести к перегреву центрального процессора 😆 ). С учетом сказанного для проверки поддержки SNI, например, на HTTPS-сервере google.com следует выполнить команду:

Если HTTPS-сервер поддерживает технологию SNI (google.com ее поддерживает), будет отображено примерно такое сообщение:

Если SNI не поддерживается, Вы не увидите никаких сообщений.

Проверка поддержки технологии OCSP stapling с помощью openssl s_client

Для проверки того, что SSL/TLS-сервер поддерживает технологию OCSP stapling, придется добавить в команду openssl s_client ключ -status (он включает отправку запроса состояния OCSP stapling и отображение полученного ответа). В связи с тем, что интересующие нас данные начинаются со строки, содержащей текст OCSP response: и занимают 17 строк, последняя из которых в случае поддержки OCSP stapling включает текст Next Update:, можно найти и обрезать нужные сведения с помощью двух вызовов grep(1), а заодно отправить «лишнюю» информацию, отображаемую через stderr , в /dev/null . Из-за того, что необходимые нам данные отправляются сервером после закрытия соединения, следует сразу передать ему команду QUIT . С учетом сказанного для проверки поддержки OCSP stapling, например, на HTTPS-сервере yandex.ru придется выполнить команду:

Если HTTPS-сервер поддерживает технологию OCSP stapling (yandex.ru ее поддерживает), будет отображено примерно такое сообщение:

Если OCSP stapling не поддерживается, Вы не увидите никаких сообщений.
Остается добавить, что я не рекомендую Вам запоминать рассмотренную в этом разделе команду, по крайней мере, до знакомства с SSLScan, который позволяет выполнять аналогичные действия более простым способом.

Проверка поддержки протоколов и наборов шифров с помощью openssl s_client

Поддержка тех или иных протоколов и наборов шифров определяет безопасность сервера и список клиентов, которые могут его использовать. Для получения хотя бы примерного представления о данном вопросе, имеет смысл познакомиться с документом ciphers и почитать качественные статьи соответствующей тематики, такие как Выбор ciphersuites для TLS и уязвимость Logjam. Опыт Яндекса. После этого можно начинать проверку поддержки протоколов и наборов шифров.
По умолчанию команда openssl s_client использует максимальную версию протокола, одновременно поддерживаемую клиентом и сервером.
Для проверки того, что SSL/TLS-сервер поддерживает протокол SSLv2, SSLv3, TLSv1, TLSv1.1 или TLSv1.2, нужно указать один из ключей -ssl2 , -ssl3 , -tls1 , -tls1_1 или -tls1_2 , соответственно. Например, для проверки поддержки протокола SSLv2 на HTTPS-сервере этого сайта необходимо выполнить команду:

Она должна закрыть соединение с HTTPS-сервером примерно с таким сообщением об ошибке:

При аналогичной проверке поддержки протокола SSLv3 сообщения об ошибке изменится:

Если интересующий Вас протокол поддерживается, Вы не только увидите упомянутые в двух предыдущих разделах параметрах сервера и текущего соединения, но и сможете обмениваться командами и результатами их выполнения с сервером (соединение будет оставаться открытым, пока Вы его не закроете).
Для того чтобы отказаться от использования протокола SSLv2, SSLv3, TLSv1, TLSv1.1 и TLSv1.2 (или любой комбинации данных протоколов), следует добавить ключ (или любую комбинацию ключей) -no_ssl2 , -no_ssl3 , -no_tls1 , -no_tls1_1 и -no_tls1_2 , соответственно.
Для получения списка наборов шифров, которые поддерживает OpenSSL, нужно выполнить команду:

Для того чтобы сведения о наборах шифров стали более подробными, необходимо указать ключ -v
Для отображения наборов шифров, соответствующих протоколам SSLv3-TLSv1.2, следует добавить ключ -ssl3 (или -tls1 ), протоколу SSLv2 -ключ -ssl2 .
Для гибкого ограничения списка используемого набора шифров нужно дополнить команду необязательной строкой cipherlist , позволяющей задать один или несколько наборов шифров, разделенных двоеточиями (запятые и пробелы допустимы, но почти не используются). Например, строка ‘RC4-SHA’ определяет один набор шифров, строка ‘SHA1’ — наборы шифров, включающие алгоритм SHA1, строка ‘SSLv3’ — наборы шифров, которые связаны с протоколом SSLv3. Строки могут объединяться с помощью символа + , обозначающего логическую операцию AND . Например, строка ‘SHA1+DES’ задает наборы шифров, имеющие в составе алгоритмы SHA1 и DES. Каждая из строк может предваряться символами ! , — или + , при этом ! обеспечивает удаление наборов шифров, определенных в следующей за ним строке (удаление происходит даже в случае последующего явного включения соответствующие наборов шифров), — удаляет соответствующие наборы шифров, но позволяет включить их в дальнейшем, + не добавляет дополнительные наборы шифров, а перемещает существующие в конец списка. Когда строка не начинается с перечисленных символов, она интерпретируется как определение набора шифров, которое необходимо добавить в существующий список наборов шифров. Если строка включает уже добавленные наборы шифров, она будет проигнорирована — соответствующие наборы шифров не будут помещены в конец списка. Строка, определяющая набор шифров, может быть дополнена суффиксом @STRENGTH , который обеспечивает сортировку списка наборов шифров по убыванию длины ключей (стойкости). Еще один полезный суффикс @SECLEVEL=n , позволяет указать security level , равный n . Подробное описание других возможностей строки cipherlist имеется в документе ciphers, а для первого знакомства, будет достаточно того, что здесь написано. Для улучшения понимания полученных сведений имеет смысл рассмотреть несколько примеров cipherlist из документации OpenSSL:
‘ALL:eNULL’ задает все наборы шифров, кроме не обеспечивающих шифрование (они же eNULL ), отсортированные по убыванию стойкости;
‘ALL:!ADH:@STRENGTH’ включает все наборы шифров, кроме анонимных DH и выключенных по умолчанию eNULL , отсортированные аналогично;
‘ALL:!aNULL’ задает все наборы шифров, кроме не обеспечивающих аутентификацию (они же aNULL ) и выключенных по умолчанию eNULL ;
‘3DES:+RSA’ включает все наборы шифров, содержащие алгоритм 3DES, при этом наборы шифров с алгоритмом RSA перемещаются в конец списка;
‘RC4:!COMPLEMENTOFDEFAULT’ задает все наборы шифров, включающие алгоритм RC4, кроме наборов шифров без аутентификации ( COMPLEMENTOFDEFAULT обозначает все, что включено в ALL , но выключено по умолчанию. В настоящее время это все наборы шифров, содержащие алгоритм RC4, и анонимные наборы шифров. Учтите, что если Вы захотите включить eNULL , не входящий в состав ALL , придется заменить COMPLEMENTOFDEFAULT на COMPLEMENTOFALL );
‘RSA:!COMPLEMENTOFALL’ включает все наборы шифров, содержащие алгоритм RSA, кроме описанных выше COMPLEMENTOFALL ;
‘ALL:@SECLEVEL=2’ задает все наборы шифров, соответствующие security level , равному 2 .
После получения элементарного представления о наборах шифров можно вернуться к команде openssl s_client , позволяющей проверять их поддержку на SSL/TLS-серверах. Для выполнения такой проверки необходимо указать ключ -cipher , дополненный рассмотренной выше строкой cipherlist . Признаки того, что набор шифров поддерживается или не поддерживается, аналогичны рассмотренным при описании проверки поддержки протоколов. Следует отметить, что как и в случае с протоколами, при указании нескольких наборов шифров используется самый стойкий, одновременно поддерживаемый клиентом и сервером. В связи с этим для выявления поддержки всех наборов шифров на некотором SSL/TLS-сервере нужно выполнить приличное количество команд openssl s_client , либо автоматизировать эту процедуру с помощью примерно таких скриптов. На мой взгляд, указанные способы выявления списка поддерживаемых наборов шифров хороши для хакеров специалистов по безопасности, но слишком сложны для применения в повседневной жизни, поэтому (как и в случае с проверкой поддержки OCSP stapling) я не рекомендую Вам использовать их до знакомства с соответствующими возможностями nmap и SSLScan.

Проверка параметров SSL/TLS-серверов с помощью nmap

Одна из многочисленных возможностей nmap заключается в поддержке скриптов, написанных на языке Lua. Сегодня в комплект поставки nmap входит более 500 таких скриптов. Вы можете познакомиться с ними на NSEDoc Reference Portal или изучить содержимое папки /usr/local/share/nmap/scripts . В нашем случае понадобятся скрипты с именами ssl-. nse , предназначенные для проверки таких параметров SSL/TLS-серверов, как свойства их сертификатов, списки поддерживаемые протоколов и наборов шифров, а также наличие некоторых уязвимостей. Для запуска одного (или нескольких) скриптов необходимо указать его имя (или несколько имен, разделенных запятыми) в качестве аргумента ключа -script . В связи с тем, что по умолчанию nmap проверяет все порты, имеет смысл ограничить их количество с помощью ключа -p , аргументом которого должен быть номер нужного порта (или номера нескольких портов, разделенные запятыми).
На этом можно закончить «вступительную часть» и перейти к рассмотрению примеров проверки параметров SSL/TLS-серверов с помощью nmap.
Для получения информации о сертификате HTTPS-сервера данного сайта с необходимо выполнить команду:

В отличие от команды openssl s_client , она отобразит параметры сертификата сервера в достаточно лаконичном виде:

Для выявления списка протоколов и наборов шифров, поддерживаемых на HTTPS-сервере этого сайта, следует выполнить команду:

В отличие от команды openssl s_client , она предоставит сведения обо всех поддерживаемых протоколах и наборах шифров:

Представленное сообщение содержит следующую информацию о том, что HTTPS-сервер:
поддерживает протоколы TLSv1, TLSv1.1 и TLSv1.2;
поддерживает перечисленные наборы шифров, сгруппированные по протоколам, при этом большинство наборов шифров имеет стойкость A, и только шифры, включающие алгоритм 3DES, отвечают уровню C (менее стойкие наборы шифров включены для обеспечения поддержки браузера Microsoft Internet Explorer 8.0 для Microsoft Windows XP). Стойкость наборов шифров обозначается буквами от A (максимальная) до F (минимальная), при этом оценка зависит от используемых алгоритмов обмена ключами и шифрования трафика, но не зависит от алгоритма контроля целостности. Для получения дополнительных сведений о методологии ранжирования конфигураций SSL/TLS-серверов стоит познакомиться с документом SSL Server Rating Guide;
не поддерживает сжатие ни для одного из протоколов;
самостоятельно задает предпочтительный набор шифров;
поддерживает наборы шифров со стойкостью не ниже уровня C.
Для сравнения рассмотрим результат проверки «заброшенного» SMTPS-сервера:

В отличие от предыдущего примера, в этот раз можно увидеть, что SMTPS-сервер:
поддерживает единственный протокол TLSv1;
поддерживает наборы шифров с минимальной стойкость F;
не предлагает клиентам предпочтительный набор шифров;
Кроме перечисленных сведений, сообщение содержит три предупреждения (они выделены) о том, что:
используются наборы шифров, содержащие алгоритм RC4, запрещенный в документе RFC 7465;
используются наборы шифров, включающие алгоритм контроля целостности MD5;
сертификат сервера подписан с помощью небезопасного алгоритма MD5.
Как видите, разница между относительно нормальной и плохой конфигурациями заметна даже невооруженным взглядом.
Для проверки HTTPS-сервера данного сайта на наличие уязвимостей Heartbleed (CVE-2014-0160), MITM CCS injection (CVE-2014-0224), а также Logjam (CVE 2015-4000) (в связи с тем, что протоколы SSLv2 и SSLv3 выключены, не имеет смысла искать связанные с ними уязвимости) нужно выполнить команду:

Если соответствующие уязвимости отсутствуют, она не отобразит никаких сведений, кроме номера порта, протокола, состояния и типа службы:

Это все, что я хотел рассказать о соответствующей функциональности nmap. Остается добавить, что Вы должны рассматривать упомянутые и «забытые» скрипты для nmap как удобные дополнительные инструменты, но ни в коем случае не как самодостаточный комплекс для выявления уязвимостей SSL/TLS-серверов.

Проверка параметров SSL/TLS-серверов с помощью SSLScan

SSLScan позиционируется автором как простой и быстрый инструмент проверки параметров SSL/TLS-серверов. Собственно, таковым он и является. Как и оба уже рассмотренных инструмента, SSLScan позволяет проверять параметры сертификатов SSL/TLS-серверов, получать списки поддерживаемых протоколов и наборов шифров, а также выявлять наличие уязвимости Heartbleed (CVE-2014-0160). Кроме этого, SSLScan позволяет проверять поддержку технологии OCSP.
Особенность SSLScan заключается в отображении разноцветных сообщений, при этом соответствующие цвета сигнализируют о нормальных, посредственных или нуждающихся в исправлении значениях параметров:
Красный цвет фона, сильнее всего привлекающий внимание, выделяет наборы шифров, не обеспечивающие шифрование;
Красный цвет текста — устаревшие наборы шифров (≤40 бит), устаревшие протоколы SSLv2 / SSLv3 и устаревший алгоритм подписи сертификатов MD5;
Желтый цвет текста — слабые наборов шифров (≤56 бит), наборы шифров, содержащие алгоритм RC4, и слабый алгоритм подписи сертификатов SHA1;
Розовый цвет текста — наборы шифров, содержащие анонимные DH-алгоритмы ADH или AECDH;
Зеленый цвет текста — стойкие наборы шифров и алгоритмы подписи сертификатов.
В общем случае при запуске SSLScan достаточно указать в командной строке только имя хоста и номер порта (если номер порта не задан, используется значение 443), разделенные двоеточием. Например, для проверки параметров HTTPS-сервера этого сайта необходимо выполнить команду:

Она отобразит примерно такие сведения о параметрах HTTPS-сервера и его сертификата, а также о поддерживаемых протоколах и наборах шифров:

В связи с тем, что информация, представленная в сообщении, прокомментирована выше, я не буду повторяться. Обратите внимание на значительное количество зеленого, небольшое желтого, и, наконец, полное отсутствие розового и красного цветов. Такая «цветовая гамма» является признаком относительно приемлемой конфигурации HTTPS-сервера. Для сравнения следует рассмотреть результат проверки уже упоминавшегося «заброшенного» SMTPS-сервера:

В отличие от предыдущего примера, в этот раз можно увидеть присутствие красного цвета, привлекающего внимание к устаревшему алгоритму подписи, слабому ключу, недоверенному издателю, а также истекшему сроку действия сертификата (все перечисленное совершенно естественно для самоподписного сертификата, сгенерированного более 10 лет назад). Кроме красного, можно заметить приличное количество розового и желтого цветов. Такая «цветовая гамма» говорит о том, что конфигурация SMTPS-сервера давно требует напильника обновления (жаль, что не все владельцы подобных серверов способны это услышать).
Для отключения некоторых проверок SSLScan и соответствующего уменьшения объема отображаемых сведений следует воспользоваться ключом (или любой комбинацией ключей) —no-check-certificate , —no-ciphersuites , —no-renegotiation , —no-compression , —no-heartbleed . Первый из них отключает выявление устаревших алгоритмов подписи сертификатов MD5 или SHA-1 и коротких ( Для проверки только тех наборов шифров, которые связаны с протоколом SSLv2, SSLv3, TLSv1, TLSv1.1, TLSv1.2 или всеми протоколами TLS версии от 1.0 до 1.2, следует указать ключ —ssl2 , —ssl3 , —tls10 , —tls11 , —tls12 или —tlsall , соответственно.
Для сокрытия имен эллиптических кривых и длин ключей EDH/RSA необходимо добавить ключ —no-cipher-details (он работает только с OpenSSL ≥1.0.2).
Для превращения цветных сообщений в монохромные (не представляю, зачем это может понадобиться) следует указать ключ —no-colour .
Для добавления в отображаемое сообщение подробной информации о параметрах сертификата сервера нужно добавить ключ —show-certificate .
Для проверки поддержки технологии OCSP необходимо указать ключ —ocsp (вспомните соответствующий вариант команды openssl s_client 😉 ).
На этом можно закончить краткий рассказ про SSLScan. Я не могу сказать, что SSLScan способен заменить рассмотренные выше инструменты, однако он имеет полное право стать их дополнением. Невзирая на «заброшенное» состояние, в настоящее время SSLScan корректно выполняет свои функции. Будем надеяться, что его форк rbsec/sslscan продолжит развиваться и рано или поздно заменит своего родителя.

Проверка параметров SSL/TLS-серверов с поддержкой STARTTLS

Остается добавить, что команда openssl s_client и SSLScan позволяют проверять параметры SSL/TLS-серверов с поддержкой технологии STARTTLS.
Для проверки параметров FTP-, IMAP-, POP3 и SMTP-серверов, поддерживающих STARTTLS, с помощью команды openssl s_client следует указывать ключ -starttls с аргументом ftp , imap pop3 или smtp , соответственно.
Для проверки параметров FTP-, IRC-, IMAP-, POP3-, SMTP-, PostgreSQL- и XMPP-серверов, поддерживающих STARTTLS, с помощью SSLScan нужно добавлять один из ключей —starttls-ftp , —starttls-irc , —starttls-imap , —starttls-pop3 , —starttls-smtp (в случае зависания соединения с SMTP-сервером из-за использования протокола SSLv3 поверх соединения STARTTLS необходимо указать описанный в предыдущем разделе ключ —tlsall ), —starttls-psql и —starttls-xmpp , соответственно. Если добавление ключа —starttls-xmpp не помогает, можно попробовать заменить его на —xmpp-server (данный ключ предназначен для инициирования XMPP-соединения сервер-сервер).

Заключение

Я надеюсь, что собранные здесь рекомендации помогут Вам начать проверку параметров обслуживаемых SSL/TLS-серверов, а затем плавно перейти к внесению изменений в их конфигурации. Ни в коем случае не торопитесь, старательно изучайте соответствующую документацию, и через некоторое время Ваши серверы будут иметь практически идеальные параметры SSL/TLS. При появлении свободного времени я постараюсь помогать Вам в этом, а пока предлагаю поучаствовать в обсуждении статьи (конструктивная критика приветствуется) и благодарю за внимание!

Понравилась статья?

Поделитесь ссылкой в социальной сети или блоге:

Источник