Тестирование HTTP / 2 с использованием `openssl s_client`

Сообщение в блоге CloudFlare об инструментах для отладки, тестирования и использования HTTP / 2 упоминает этот подход к выяснению того, какие протоколы поддерживаются данным server:

$ openssl s_client -connect www.cloudflare.com:443 -nextprotoneg ''
CONNECTED(00000003)
Protocols advertised by server: h2, spdy/3.1, http/1.1

Этот подход, кажется, отлично работает для многих доменов, которые я тестировал. Однако (с поддержкой HTTP / 2) домен benchmarkjs.com выдает результаты, которые выглядят совершенно иначе, и я не знаю почему:

$ openssl s_client -connect benchmarkjs.com:443 -nextprotoneg ''
CONNECTED(00000003)
depth=0 C = US, ST = Washington, L = Seattle, O = Odin, OU = Plesk, CN = Plesk, emailAddress = info@plesk.com
verify error:num=18:self signed certificate
verify return:1
depth=0 C = US, ST = Washington, L = Seattle, O = Odin, OU = Plesk, CN = Plesk, emailAddress = info@plesk.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=Washington/L=Seattle/O=Odin/OU=Plesk/CN=Plesk/emailAddress=info@plesk.com
   i:/C=US/ST=Washington/L=Seattle/O=Odin/OU=Plesk/CN=Plesk/emailAddress=info@plesk.com
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDfTCCAmUCBFXIlUswDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAlVTMRMw
EQYDVQQIDApXYXNoaW5ndG9uMRAwDgYDVQQHDAdTZWF0dGxlMQ0wCwYDVQQKDARP
ZGluMQ4wDAYDVQQLDAVQbGVzazEOMAwGA1UEAwwFUGxlc2sxHTAbBgkqhkiG9w0B
CQEWDmluZm9AcGxlc2suY29tMB4XDTE1MDgxMDEyMTMwMFoXDTE2MDgwOTEyMTMw
MFowgYIxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApXYXNoaW5ndG9uMRAwDgYDVQQH
DAdTZWF0dGxlMQ0wCwYDVQQKDARPZGluMQ4wDAYDVQQLDAVQbGVzazEOMAwGA1UE
AwwFUGxlc2sxHTAbBgkqhkiG9w0BCQEWDmluZm9AcGxlc2suY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvLgc48tQHJaVZj4btZhGySqNlQeXRti8
Nansm15wJXS45EIFx6lYqFbDjD22VBwwDrILNZBY9BiKLV+VsZYuu1sOK+Ctatww
gcOf4UB5pT6kOP48vBJlsaxqf+kCQpiVBniliLs7yAxl3BjjzQBluI4DUMXGpsuD
u2tBi/fsUV6QRBzsebQ6cH5cZ9XPGiirPyFe7yNNbXurooYmeD1YjEH6qYIPhU9O
lTOU9rssii8ShmHL/X54ekIqZ9y5b3eD+Dhp45/WjxXcgSxWZHx8SYcKndiSOJFa
KUXlBKREmvH1nQLtp1BdCH6BiLPXaMMcRPY1BUhLSLt6M68B5vRDqQIDAQABMA0G
CSqGSIb3DQEBCwUAA4IBAQAvTuPoc0RYHXeHW61s6PPC7pRtp1t+roknJPa/po1P
vFtINtR9vuCfeUfS7K8ryfduBkX/km8qjCxjNvjQsJdya5mfMdPzW4AabJs06qUp
h5PPk2ER1OcPzraemcHHL8gzStVk3n9C23ZRAwZaEIsgnOQ58YGf4eyrzKXBClfL
NPL28cQQH5+d4lIsQc7B9d0OiiUQNTBfVD/CA67SPvc/f6Xq7ARdrc44GhA03cUN
0Vr60j2kv9IkdSnRPtt40R8AD97bKu9E/jOJCrSOfCbB3Qz1Pdm2lZqSEnoHdlbg
2KY8HrvoEXvuPUNXRIQEhpR7f9y70iBPORs0PbuC+qDf
-----END CERTIFICATE-----
subject=/C=US/ST=Washington/L=Seattle/O=Odin/OU=Plesk/CN=Plesk/emailAddress=info@plesk.com
issuer=/C=US/ST=Washington/L=Seattle/O=Odin/OU=Plesk/CN=Plesk/emailAddress=info@plesk.com
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 1409 bytes and written 448 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: C0474D42297C21B374C558E698A69EEBBFF537B35E6365D31B4D7AA2CD4192AD
    Session-ID-ctx:
    Master-Key: 2292DF581DAE3CE4A4E8CFF5A351A3F4E99602A7DCDBD090998C38926498743B4E3A808A1C4505136D51FC847F0153A6
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1455103745
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)
---

Обратите внимание, что он не возвращается к приглашению; вы подключены к серверу и теперь можете ввести, например, GET / HTTP / 1.1 , а затем Host: benchmarkjs.com .

Итак, у меня два вопроса:

  1. Чем отличается benchmarkjs.com , из-за чего этот метод не работает?
  2. Можно ли использовать openssl s_client для обнаружения поддержки HTTP / 2 в общий способ, который работает даже для этого домена?
1
задан 10 February 2016 в 17:00
1 ответ

Мое мнение: в руководстве openssl s_client указано:

-nextprotoneg протоколы

включают расширение TLS согласования следующего протокола и предоставляют список запятых- разделенные имена протоколов, поддержку которых должен рекламировать клиент. В Список сначала должен содержать наиболее востребованные протоколы. Имена протоколов печатаемые строки ASCII, например «http / 1.1» или «spdy / 3». Пустой список протоколы обрабатываются специально и заставят клиента рекламировать поддержка расширения TLS, но отключение сразу после получения ServerHello со списком поддерживаемых сервером протоколов.

(выделено мной.)

Я бы сказал, что механизм SSL / TLS, завершающий ваш запрос на benchmarkjs.com , просто не поддерживает это согласование следующего протокола. расширение или отключено по какой-либо причине. Следовательно, в вашем тесте команда openssl s_client объявляет, что поддерживает NPN, но сервер закрывает глаза на ot. Рукопожатие по-прежнему проходит нормально, потому что расширение кажется несущественным (или, по крайней мере, считается таковым openssl ), и вы получаете подключенный туннель TLS.

Что касается реализации надежной проверки, я ' м боюсь, поскольку openssl s_client , по-видимому, не имеет какой-либо опции командной строки, которая заставила бы его немедленно завершить сеанс, вам придется пойти на уровень глубже и написать свою собственную программу, связывающуюся с libssl , который реализует желаемое поведение. (И я бы лично реализовал его в Go , используя пакет crypto / tls из его стандартной библиотеки, поскольку его не сложнее программировать, чем JavaScript, но он создает статически связанную программу, что означает простоту развертывается.)

2
ответ дан 3 December 2019 в 20:42

Теги

Похожие вопросы