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

«Проверка сертификата сервера в порядке», но «ALPN, сервер не согласен с протоколом»

Я делаю локон

curl -v ... https://... 

а подробный вывод содержит

....
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
*    server certificate verification OK
....
* ALPN, server did not agree to a protocol
* Server auth using Basic with user 'api'
> POST /v3/pindertek.com/messages HTTP/1.1
> Host: api.mailgun.net
> Authorization: Basic sdfsdfsdfsadfsdfsdfsadfsadfsadfsdfsdfasdfsdf=
....
< HTTP/1.1 100 Continue
< HTTP/1.1 200 OK
......

Мои вопросы:

Я вижу, что проверка сертификата TLS прошла успешно. Но тогда сообщения «ALPN, сервер не согласен с протоколом» и "Серверная аутентификация с использованием Basic с пользователем 'api'" не внушают полного доверия.

Я надеюсь, что это просто относится к протоколу отдельного уровня, который используется под / внутри / поверх протокола шифрования TLS, но я не знаю.


Более подробный подробный вывод:

* Connected to api.mailgun.net (34.215.83.50) port 443 (#0)
* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 1060 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
*    server certificate verification OK
*    server certificate status verification SKIPPED
*    common name: *.mailgun.net (matched)
*    server certificate expiration date OK
*    server certificate activation date OK
*    certificate public key: RSA
*    certificate version: #3
*    subject: C=US,ST=California,L=San Francisco,O=MAILGUN TECHNOLOGIES\, INC,OU=MAILGUN TECHNOLOGIES\, INC,CN=*.mailgun.net
*    start date: Thu, 18 Jan 2018 00:00:00 GMT
*    expire date: Wed, 18 Mar 2020 12:00:00 GMT
*    issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=Thawte TLS RSA CA G1
*    compression: NULL
* ALPN, server did not agree to a protocol
* Server auth using Basic with user 'api'
> POST /v3/pindertek.com/messages HTTP/1.1
> Host: api.mailgun.net
> Authorization: Basic sdfsdfsdfsadfsdfsdfsadfsadfsadfsdfsdfasdfsdf=
> User-Agent: curl/7.47.0
> Accept: */*
> Content-Length: 464
> Expect: 100-continue
> Content-Type: multipart/form-data; boundary=------------------------df265bf86c971664
> 
< HTTP/1.1 100 Continue
< HTTP/1.1 200 OK
......

TLS - это безопасность транспортного уровня. В приведенном выше случае это не проблема.

Из Википедия:

Согласование протоколов прикладного уровня (ALPN) - это расширение безопасности транспортного уровня (TLS) для согласования протоколов прикладного уровня. ALPN позволяет прикладному уровню согласовывать, какой протокол должен выполняться через безопасное соединение, таким образом, чтобы избежать дополнительных циклов передачи данных и который не зависит от протоколов прикладного уровня. Это необходимо для безопасных соединений HTTP / 2, что улучшает сжатие веб-страниц и снижает их задержку по сравнению с HTTP / 1.x.

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

В приведенном выше подробном выводе «ALPN» - это префикс, указывающий, что остальная часть строки является статусом согласования ALPN на стороне клиента.

Базовая аутентификация просто имеет в виду основные Ключ / пароль API протокол. (Они были включены в командную строку curl, но не показаны). Вот хорошее сравнение Базовая аутентификация против OAuth:

Одна из тревожных тенденций, которые я заметил за последние несколько лет, заключается в том, что все больше и больше API-сервисов постепенно отказываются от поддержки базовой аутентификации HTTP (также известной как Basic Auth) в пользу OAuth. ... Базовая аутентификация имеет плохую репутацию «небезопасной», но это не обязательно так. Чтобы обеспечить максимальную безопасность службы API (защищенной базовой аутентификацией), вы можете сделать несколько вещей: Всегда выполнять все запросы через HTTP. Если вы не используете SSL, то независимо от того, какой протокол аутентификации вы используете, вы никогда не будете в безопасности. Если вы не используете HTTP, все ваши учетные данные будут отправлены в виде обычного текста по сети: ужасная идея. ...

Итак, нет доказательств перехода с TLS - и я сомневаюсь, что это возможно. Добавление --tlsv1.2 флаг для завивки приводит к тому же результату.

Что именно эта строка

* ALPN, server did not agree to a protocol

означает, что это все еще загадка, но я предполагаю, что это означает либо (1) несогласие с hhtp2, либо менее вероятно (2) клиент спросил, продолжает ли он без авторизации, и получил отказ, и после этого использовал авторизацию. Действительно плохой выбор языка для вывода диагностики. Google возвращает тысячи результатов для этого буквального выражения.