“服务器证书验证正常”，但“ 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 / 2连接需要它，与HTTP / 1.x相比，它可以改善网页的压缩并减少其延迟。

由于APLN是一个扩展的TLS，它意味着TLS 正在被使用。即使服务器未使用ALPN，而是其他一些较早的协议，这两个协议也必须是TLS的扩展，否则它们将能够通信。

在上面的详细输出中，“ ALPN”是一个前缀，指示该行的其余部分是客户端进行ALPN协商的状态。

基本身份验证仅指基本API密钥/密码协议。（这些都包含在curl命令行中，但未显示）。 这是Basic Auth与OAuth的比较：

我在过去几年中注意到的令人不安的趋势之一是，越来越多的API服务正在逐渐放弃对HTTP基本身份验证（又名：基本身份验证）的支持，而转而使用OAuth。...基本身份验证因“不安全”而声誉不佳，但这不一定是正确的。您可以采取几种措施来确保您的API服务（由Basic Auth保护）尽可能安全：始终通过HTTP运行所有请求。如果您不使用SSL，那么无论您使用哪种身份验证协议，都将永远不会安全。除非您使用HTTP，否则所有凭证都将以纯文本格式通过网络发送：这是一个可怕的想法。...

因此，尚无从TLS降级的证据-我怀疑是否有可能。将--tlsv1.2标记添加到curl会得到相同的输出。

这行到底是什么

* ALPN, server did not agree to a protocol

手段仍然是个谜，但我想这意味着（1）不同意hhtp2，或者可能性较小（2）客户询问是否未经授权继续进行并被拒绝，因此使用了授权。 诊断输出的语言选择确实很差。 Google会为该文字表达式返回数千个结果。