“服务器证书验证正常”但“ALPN，服务器不同意协议”

Question

我正在拨打 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
......

Answer 1

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 服务（由基本身份验证保护）尽可能安全： 始终通过 HTTP 运行所有请求。如果您不使用 SSL，那么无论您使用何种身份验证协议，您都将永远不会安全。除非您使用 HTTPS，否则您的所有凭据都将以纯文本形式通过网络发送：一个可怕的想法。...

所以没有从 TLS 降级的证据 - 我怀疑这是可能的。将--tlsv1.2标志添加到 curl 会产生相同的输出。

这行到底是什么

* ALPN, server did not agree to a protocol

手段仍然是一个谜，但我猜这意味着（1）不同意hhtp2，或者不太可能（2）客户询问是否未经授权继续并被拒绝，因此使用授权。 诊断输出语言的真正糟糕选择。 Google 会为该文字表达式返回数千个结果。