使用early_data时TLS v1.3出现Bad Record MAC告警问题排查

问题 #

我正在开发一个涉及TLS v1.3的Ruby项目，为优化请求决定使用early_data特性。当前使用tttls1.3库，客户端在发送early_data前正常工作，但发送early_data后，尽管请求能得到服务器响应，却会立即收到编号为20的Bad Record MAC告警。我甚至重新计算了疑似有问题的client-finished消息，但结果显示正确。

请问可能的原因是什么？是否存在TCP或其他可排查的问题？

示例代码：

require 'socket'
require 'tttls1.3'

settings2 = {
    alpn: ['http/1.1'],
    supported_groups: [TTTLS13::NamedGroup::SECP256R1],
    cipher_suites: [TTTLS13::CipherSuite::TLS_AES_256_GCM_SHA384],
    check_certificate_status: false,
}

settings1 = {
    alpn: ['http/1.1'],
    supported_groups: [TTTLS13::NamedGroup::SECP256R1],
    cipher_suites: [TTTLS13::CipherSuite::TLS_AES_256_GCM_SHA384],
    check_certificate_status: false,
    process_new_session_ticket: lambda do |nst, rms, cs|
        return if Time.now.to_i - nst.timestamp > nst.ticket_lifetime
        settings2[:ticket] = nst.ticket
        settings2[:resumption_master_secret] = rms
        settings2[:psk_cipher_suite] = cs
        settings2[:ticket_nonce] = nst.ticket_nonce
        settings2[:ticket_age_add] = nst.ticket_age_add
        settings2[:ticket_timestamp] = nst.timestamp
    end
}

# REQUEST

socket = TCPSocket.new("ssltest.louis.info", 443)
client = TTTLS13::Client.new(socket, "ssltest.louis.info", settings1)
client.connect 
client.write("GET / HTTP/1.1\r\n")
client.write("Host: ssltest.louis.info\r\n")
client.write("\r\n\r\n")
client.read
client.close
socket.close

sleep(1)

# RESUMPTION

socket = TCPSocket.new("ssltest.louis.info", 443)
client = TTTLS13::Client.new(socket, "ssltest.louis.info", settings2)
client.early_data("HEAD / HTTP/1.1\r\nHost: ssltest.louis.info\r\n\r\n\r\n")
client.connect 
p client.read
p client.read
p client.read
p client.read

可能的原因与排查方向 #

1. Early Data加密上下文切换异常 #

TLS 1.3中，Early Data使用基于PSK的早期密钥，与完整握手后的会话密钥是独立的。如果客户端发送Early Data后，没有正确切换到握手完成后的新加密上下文，或者解密服务器响应时误用了密钥，就会触发Bad Record MAC告警。

• 检查tttls1.3库中early_data与connect方法的交互逻辑：调用early_data后，是否正确处理了早期密钥和握手后密钥的切换流程。
• 确认会话恢复参数的完整性：resumption_master_secret、ticket_age_add、ticket_timestamp等参数是否正确传递，尤其是票据有效期的计算是否符合服务器预期——计算偏差会导致密钥派生错误。

2. TCP数据格式或粘包问题 #

虽然请求能得到响应，但TCP层的数据拆分或格式错误可能破坏TLS记录边界：

• 检查Early Data的HTTP格式：你代码中发送的HEAD请求多了一个\r\n（末尾是\r\n\r\n\r\n），可能导致服务器解析HTTP时出现异常，进而影响后续TLS记录的MAC验证。尝试改为合规格式HEAD / HTTP/1.1\r\nHost: ssltest.louis.info\r\n\r\n。
• 简化Early Data内容：发送更短的合规请求，排除数据长度或格式导致的记录拆分问题。

3. 服务器端Early Data限制 #

部分服务器对Early Data的请求类型、大小有严格限制：

• 确认目标服务器是否支持用当前会话票据发送Early Data：检查首次握手返回的New Session Ticket是否包含early_data_indicator标记，若服务器不允许该票据用于Early Data，客户端强行发送会触发后续握手异常。
• 验证服务器是否允许HEAD请求作为Early Data：部分服务器仅允许GET等特定请求方法使用Early Data。

4. 库实现bug #

从你重新计算client-finished正确仍报错的情况来看，可能是tttls1.3库的Early Data处理存在缺陷：

• 升级库到最新版本，查看是否有相关bug修复记录。
• 开启TLS调试日志（若库支持），对比发送的Early Data记录、握手记录的MAC值是否符合TLS 1.3规范。

内容的提问来源于stack exchange，提问作者xpepermint