☰

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

tag-icon • tag-icon ssl https curl http-basic-authentication alpn
“服务器证书验证正常”但“ALPN，服务器不同意协议”

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

答案1

TLS 是传输层安全性。在上述成功的情况下，没有问题。

从维基百科：

应用层协议协商 (ALPN) 是用于应用层协议协商的传输层安全 (TLS) 扩展。ALPN 允许应用层协商应通过安全连接执行哪种协议，以避免额外的往返，并且哪种协议独立于应用层协议。安全的 HTTP/2 连接需要它，与 HTTP/1.x 相比，它可以提高网页的压缩率并降低其延迟。

自从亚太地区肺动脉网是一个扩大的TLS，这意味着TLS 是正在使用。即使服务器不使用 ALPN，而是使用其他早期协议，两种协议都必须是TLS否则他们将无法沟通。

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

基本认证只是指基本API 密钥/密码协议。（这些包含在 curl 命令行中，但未显示）。 这里是一个很好的比较基本认证对比开放授权：

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

因此没有证据表明 TLS 降级 - 而且我怀疑这是不可能的。将--tlsv1.2标志添加到 curl 会产生相同的输出。

这句话

* ALPN, server did not agree to a protocol

手段仍然是个谜，但我猜它的意思是 (1) 不同意 HTTP/2，或者不太可能 (2) 客户端询问是否在没有授权的情况下继续并被拒绝，因此使用授权。 对于诊断输出来说，这确实是一个糟糕的语言选择。 Google 针对该文字表达返回了数千个结果。

相关内容