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

Я выполняю curl-вызов

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
......
8
задан 14 July 2018 в 13:19
1 ответ

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

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

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

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

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

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

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

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

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

* ALPN, server did not agree to a protocol

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

7
ответ дан 2 December 2019 в 23:03

Теги

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