Я ищу простой способ узнать, использует ли сервер расширение SSL с указанием имени сервера для своего сертификата HTTPS на веб-сайте. Метод, который использует браузер или командную строку Unix, подойдет.
Благодарность!
Я ищу простой способ узнать, использует ли сервер расширение SSL с указанием имени сервера для своего сертификата HTTPS на веб-сайте. Метод, который использует браузер или командную строку Unix, подойдет.
Благодарность!
Ответы:
SNI инициируется клиентом, поэтому вам нужен клиент, который его поддерживает. Если вы не используете Windows XP, ваш браузер подойдет. Если ваш клиент позволяет правильно отлаживать SSL-соединения (к сожалению, даже команды CLI gnutls / openssl этого не делают), вы можете увидеть, отправляет ли сервер обратно поле server_name в расширенном привете. Обратите внимание, что отсутствие этого поля означает только то, что сервер не использовал server_name в клиенте hello, чтобы помочь выбрать сертификат, а не то, что он не поддерживает его.
Таким образом, на практике самый простой тест - просто попытаться подключиться. Для этого вам нужно знать два имени, которые разрешают один и тот же IP-адрес, к которому можно установить ssl-соединение. https проще всего, так как вы можете просто просмотреть оба имени и посмотреть, представлен ли вам правильный сертификат.
Есть три результата:
Немного более сложный тест, который даст больше информации - это открыть и захватить Wireshark во время просмотра. Затем вы можете найти соответствующие пакеты, отфильтровав ssl.handshake. Снимки экрана ниже являются примером клиент-привет / сервер-привет-пара, где поддерживается SNI:
Опять же, конечно, отсутствие поля server_name на сервере hello не означает, что SNI не поддерживается. Просто, что предоставленное клиентом имя_сервера не использовалось при принятии решения о том, какой сертификат использовать.
Один из лайнеров, который вы, вероятно, ищете, чтобы обнаружить наличие заголовка расширения индикации имени сервера SSL / TLS:
openssl s_client -servername www.SERVERNAME.com -tlsextdebug -connect www.YOURSERVER.com:443 2>/dev/null | grep "server name"
где www.SERVERNAME.com
- значение SNI, которое вы тестируете, и www.YOURSERVER.com
имя домена или IP-адрес тестируемого сервера с поддержкой TLS.
Командная строка использует openssl
s s_client
(см. S_client (1) ) для подключения к серверу через www.YOURSERVER.com
порт 443
. В -tlsextdebug
опции включает расширение TLS отладочный. Эта -servername
опция указывает s_client
программе передать www.SERVERNAME.com
значение поля SNI в пакете ClientHello во время квитирования TLS.
Наконец, 2>/dev/null
просто скрывает вывод stderr (который может быть шумным), и | grep "server name"
конвейер фильтрует stdout для отображения расширения TLS, называемого «имя сервера», в s_client
выходных данных отладки расширения TLS.
Если вы видите строку вывода, такую как
TLS server extension "server name" (id=0), len=0
затем сервер возвращает информацию заголовка SNI в своем ответе ServerHello. Если вы этого не сделаете, возможно, сервер либо не поддерживает SNI, либо он не настроен на возврат информации SNI с указанием имени, которое вы запрашиваете. В этом случае дважды проверьте, что вы используете доменное имя в -servername
опции, о которой сервер должен ответить информацией SNI.
-servername
или нет. -servername sdfsdlkfjsdf23.somedomain.somewhere -connect realhost.somedomain.somewhere
= TLS server extension "server name" (id=0), len=0
(И тот же вывод, если они совпадают.) Как проверить, что он не соответствует хосту на сервере из вывода?
-msg
в дополнение к вышеприведенным параметрам и grep для «Alert». Если это -servername
не так, вы получите что-то вроде TLS 1.2 Alert ... warning unrecognized_name
с сервера. @Meitar Думаю, если вы добавите это к ответу, это будет полезно для других людей.
-msg
Коммутатор просто добавляет hexdump сообщений протокола TLS. Не требуется наблюдать ошибку рукопожатия TLS, поэтому было бы неправильно добавить к этому ответу. Более того, подобные ошибки рукопожатия TLS выводятся в STDOUT, что означает, что их 2>/dev/null
нужно будет удалить из ответа, чтобы он был обработан grep
в первую очередь. На самом деле @bshea запрашивает: «Как я могу обнаружить ошибки TLS?» который полностью отличается от вопроса «Использует ли этот сервер функцию SNI протокола TLS?» это тема здесь.
STDERR
текстовый файл, я не получу эту ошибку там. Без -msg
я не мог найти другой вариант, который показывает сообщения рукопожатия. (используя openssl 1.0.2q). Пока уместность ответа, вы можете быть правы.
Вы можете использовать openssl
для получения и запроса сертификата.
openssl s_client -connect
openssl x509
grep
найти информацию "DNS:"openssl s_client -connect alice.sni.velox.ch:443 | openssl x509 -noout -text | grep DNS:
% openssl s_client -connect alice.sni.velox.ch:443 | openssl x509 -noout -text | grep DNS:
depth=2 C = BM, O = QuoVadis Limited, CN = QuoVadis Root CA 2
verify return:1
depth=1 C = BM, O = QuoVadis Limited, CN = QuoVadis Global SSL ICA G2
verify return:1
depth=0 C = CH, ST = Zuerich, L = Zuerich, O = Kaspar Brand, CN = alice.sni.velox.ch
verify return:1
DNS:alice.sni.velox.ch, DNS:carol.sni.velox.ch
Последняя строка показывает все записи SNI, присутствующие в сертификате:
DNS:alice.sni.velox.ch, DNS:carol.sni.velox.ch
DNS:...
записи на последней строке показать все действительные имена SNI в сертификате.
openssl
. Некоторые подробности доступны:openssl s_client -servername alice.sni.velox.ch -tlsextdebug -msg -connect alice.sni.velox.ch:443
Некоторые указания на использование SNI даются во время теста Qualys SSL .