我有一个嵌入式设备,使用 mBedTLS,尝试打开与https://www.cloudflare.com的连接,但失败:
#define MBEDTLS_ERR_PK_UNKNOWN_NAMED_CURVE -0x3A00 /**< Elliptic curve is unsupported (only NIST curves are supported). */
Run Code Online (Sandbox Code Playgroud)
由于硬件限制,设备仅支持以下曲线:
MBEDTLS_ECP_DP_SECP192R1
MBEDTLS_ECP_DP_SECP224R1
MBEDTLS_ECP_DP_SECP256R1
Run Code Online (Sandbox Code Playgroud)
并启用了以下 TLS 扩展:
Supported Elliptic Curves
Supported Point Formats
Run Code Online (Sandbox Code Playgroud)
查看 cloudflare.com 证书:https ://www.ssllabs.com/ssltest/analyze.html ? d = www.cloudflare.com & s = 104.17.210.9
我可以看到 cloudflare.com 支持 RSA 和 ECDSA 证书。
ECDSA 服务器证书使用 256 位 EC 密钥,但该证书的颁发者使用 384 位 EC 密钥。
这就是导致设备出现故障的原因。设备无法验证链中的 384 位证书。
那么,这是 cloudflare.com 的问题吗?服务器是否应该看到客户端不支持其证书链中的所有曲线并恢复为 RSA 证书?
即设备提供了它支持的曲线列表,但服务器返回一个证书链,链中包含一个不受支持的 EC。如果所有曲线都受支持,服务器是否会检查客户端提供的“支持的椭圆曲线”TLS 扩展,是否仅返回证书链?
任何见解表示赞赏。
每当您不确定协议的行为方式时,请参阅其定义。对于 Internet 上广泛使用的协议,这通常是一个或多个 RFC。
在这种情况下,RFC 8422非常明确地说明了在这种情况下必须发生的事情:如果客户端不支持该证书中使用的椭圆曲线,则服务器不得尝试使用该证书。
第 5.1 节解释了如果协商失败,服务器不得尝试协商 ECC:
收到包含这些扩展之一或两者的 ClientHello 的服务器必须使用客户端的枚举功能来指导其选择适当的密码套件。仅当服务器可以在使用客户端支持的曲线和点格式时成功完成握手时,才必须协商提议的 ECC 密码套件之一(参见第 5.3 和 5.4 节)。
注意:参与 ECDHE_ECDSA 密钥交换的服务器可能对其证书中的 ECDSA 或 EdDSA 密钥以及 ServerKeyExchange 消息中的临时 ECDH 密钥使用不同的曲线。服务器必须考虑这两种情况下的扩展。
如果服务器不理解支持的椭圆曲线扩展,不理解支持的点格式扩展,或者无法完成 ECC 握手同时将自身限制为枚举的曲线和点格式,则它不得协商使用 ECC 密码套房。根据客户端提出并由服务器支持的其他密码套件,由于缺少通用密码套件,这可能会导致致命的握手失败警报。
第 5.3 节还说:
服务器构建一个合适的证书链,并在证书消息中将它传送给客户端。如果客户端使用了受支持的椭圆曲线扩展,则服务器证书中的公钥必须尊重客户端对椭圆曲线的选择。不能满足此要求的服务器不得在其 ServerHello 消息中选择 ECC 密码套件。
看起来您毕竟正在向 CloudFlare 提交错误报告。
| 归档时间: |
|
| 查看次数: |
516 次 |
| 最近记录: |