Erlang/OTP中ssl:handshake/3函数在指定{handshake, hello}时的问题分析

问题背景

在Erlang/OTP的SSL/TLS模块中，ssl:handshake/3函数用于在已建立的TCP连接上执行SSL/TLS握手过程。从OTP 27版本开始，该函数在7a0723974提交后，要求必须提供证书和密钥才能执行握手操作。

问题描述

当开发者使用{handshake, hello}选项时，ssl:handshake/3函数仍然强制要求提供证书和密钥。这在技术逻辑上是不合理的，因为在"hello"模式下，握手过程可能只需要完成初始的ClientHello消息交换，而实际的证书和密钥可能会在后续的ssl:handshake_continue/3调用中根据返回的信息（如SNI主机名）动态确定。

技术细节分析

1. 握手阶段分离：TLS握手过程可以分为多个阶段，{handshake, hello}选项允许开发者只执行初始的握手阶段，获取对端信息后再决定后续操作。

2. 证书延迟绑定：在实际应用中，服务器可能需要根据客户端提供的SNI(Server Name Indication)信息来选择不同的证书。强制在初始阶段提供证书会破坏这种灵活性。

3. 版本兼容性：在OTP 26及更早版本中，这种行为是允许的，但在OTP 27中变成了强制要求，这导致了向后兼容性问题。

影响范围

该问题影响OTP 27的所有版本，包括从27.0到27.2的各个发布版本。使用{handshake, hello}选项进行分阶段TLS握手的应用都会受到影响。

临时解决方案

开发者可以使用一个虚拟的证书和密钥作为临时解决方案：

ssl:handshake(TcpSocket, [
    {handshake, hello}, 
    {versions, ['tlsv1.3']}, 
    {key, #{algorithm => eddsa, sign_fun => undefined}},
    {cert, <<>>}
], 5000).

预期修复方向

从技术实现角度，正确的修复应该是：

1. 当检测到{handshake, hello}选项时，应跳过证书和密钥的强制检查
2. 只有在完整握手或需要证书验证的阶段才进行相关检查
3. 保持与早期版本的兼容性

总结

这个问题展示了在安全协议实现中平衡灵活性和强制要求的重要性。TLS协议本身就设计为支持分阶段握手和动态证书选择，因此实现时应该尊重这种设计理念。开发者在使用OTP 27的SSL模块时需要注意这个问题，特别是在实现需要SNI功能的TLS服务器时。