我正在为radius服务器使用TLS_RSA_WITH_3DES_EDE_CBC_SHA密码套件，在客户端的ChangeCipherSpec之后立即收到加密的握手消息（40字节），我曾尝试使用3des和cbc模式来解密这些字节，但是有异常（不好）数据），试图查看https://tools.ietf.org/html/rfc2246上的peap tls v1.0但是，没有找到很多关于完成握手加密/解密的信息。任何帮助都会很精彩，非常感谢!!
这是我用来计算主密钥和密钥材料的代码。
{{1}}
答案 0 :(得分：1)
包含完成握手消息的记录的认证/加密和解密/验证与SSL / TLS中的所有其他记录相同，除了它是CCS之后的第一个。
首先（握手期间）来自密钥交换的预主密钥用于导出主密钥和多个工作密钥和IV，具体取决于套件。这与协议版本有所不同;对于TLS1.0，请参阅rfc2246第8.1.1节（适用于普通RSA）6.3（适用于所有密钥交换）和5.
使用＆＃39; GenericBlock＆＃39; （CBC）密码 - 这是除了RC4在TLS1.0和1.1中唯一的选择 - 使用6.2.3.1分段（此记录不需要）6.2.3.2可选压缩（由于CRIME等攻击现在通常不使用对于EAP流量而言毫无用处）和6.2.3.2。
具体来说，首先添加一个HMAC（对于这个套件HMAC-SHA1），然后填充，然后使用数据密码（3DES-CBC）加密结果，其中第一个记录（完成的是）来自IV从上面的密钥派生步骤和后续记录来自前一记录的最后一个块。 （后者是Rogaway首先报道并被BEAST利用的缺陷。）
解密和验证以明显的方式颠倒了这一过程。注意rfc2246没有指定接收器必须检查填充的所有字节，但这显然是有意的; rfc4346（1.1）确实指定了它，而不更改内容。 （rfc4346 更改IV处理以修复Rogaway缺陷.SSLv3指定随机填充除了最终长度字节，因此可以检查;这是POODLE缺陷。）
为任意数据提供块密码（包括3DES）的CBC模式的某些库/ API默认为PKCS5 / 7填充。填充TLS使用类似于但不兼容PKCS5 / 7填充，因此使用这些库您可能必须按照6.2.3.2中的说明 - 或大约十几个开源TLS实现中的任何一个中的代码来处理填充和取消填充。