web-dev-qa-db-ja.com

「サーバー証明書の検証は正常ですが、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' "完全な自信を刺激しないでください。

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
......
sslhttpscurlhttp-basic-authenticationalpn
10
Craig Hicks

TLSはトランスポート層のセキュリティです。上記の成功した場合、問題ありません。

Wikipedia から：

アプリケーション層プロトコルネゴシエーション（ALPN）は、アプリケーション層プロトコルネゴシエーション用のトランスポート層セキュリティ（TLS）拡張です。 ALPNを使用すると、アプリケーション層は、追加のラウンドトリップを回避し、アプリケーション層プロトコルから独立した方法で、安全な接続を介して実行する必要があるプロトコルをネゴシエートできます。これは、HTTP/1.xと比較してWebページの圧縮を改善し、待ち時間を短縮する安全なHTTP/2接続で必要です。

[〜＃〜] apln [〜＃〜]はextensionの[〜＃ 〜] tls [〜＃〜]、[〜＃〜] tls [〜＃〜]であることを意味します使用されています。サーバーがALPNを使用していない場合でも、他のいくつかの以前のプロトコルでは、両方のプロトコルが[〜＃〜] tls [〜＃〜]の拡張でなければなりません。そうでない場合、コミュニケーション。

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

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

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

したがって、TLSからのダウングレードの証拠はありません-可能であるとは思えません。 --tlsv1.2フラグを付けてカールすると、同じ出力になります。

まさにこの線

* ALPN, server did not agree to a protocol

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

8
Craig Hicks