「サーバー証明書の検証はOKですが、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、サーバーはプロトコルに同意しませんでした」および「ユーザー「api」を使用したBasicを使用したサーバー認証」というメッセージは、完全な自信を呼び起こしません。

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 / 1.xと比較してWebページの圧縮を改善し、待ち時間を短縮する安全なHTTP / 2接続で必要です。

APLNはTLSの拡張であるため、TLS が使用されていることを意味します。サーバーがALPNを使用していない場合でも、以前のプロトコルが使用されていたとしても、両方のプロトコルがTLSの拡張である必要があります。そうでない場合、それらは通信できます。

上記の詳細出力の「ALPN」は、行の残りがクライアント側によるALPNネゴシエーションのステータスであることを示すプレフィックスです。

基本認証は、基本的なAPIキー/パスワードプロトコルを参照するだけです。（これらはcurlコマンドラインに含まれていましたが、表示されていませんでした）。 基本認証とOAuthの良い比較を次に示します。

ここ数年私が気付いた気がかりな傾向の1つは、ますます多くのAPIサービスがOAuthを支持してHTTP基本認証（別名：基本認証）のサポートを徐々に廃止していることです。...基本認証は「安全でない」という悪い評判を得ますが、これは必ずしも本当ではありません。APIサービス（Basic Authで保護されている）が可能な限り安全であることを確認するには、いくつかの方法があります。すべての要求を常にHTTP経由で実行します。SSLを使用していない場合は、使用する認証プロトコルに関係なく、安全になることはありません。HTTPを使用している場合を除き、すべての資格情報はネットワーク経由でプレーンテキストで送信されます。これは恐ろしい考えです。...

したがって、TLSからのダウングレードの証拠はありません-可能かどうかは疑問です。--tlsv1.2フラグをcurlに追加すると、同じ出力になります。

まさにこの線

* ALPN, server did not agree to a protocol

手段はまだ謎ですが、（1）hhtp2に同意しない、または可能性が低い（2）クライアントが許可なしに続行するかどうかを尋ねられ、拒否されたため、許可を使用したことを意味していると思います。 診断出力のための言語の本当に悪い選択。 Googleはそのリテラル式に対して何千もの結果を返します。