«Проверка сертификата сервера в порядке», но «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, но не показаны). Вот хорошее сравнение Basic Auth против OAuth :

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

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

Именно то, что эта линия

* ALPN, server did not agree to a protocol

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