如何解密HTTPS（ECDHE）数据？

Question

我试图了解HTTPS的工作原理，并进行一些实际测试。

我有一个通过TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA加密的HTTPS通信捕获的数据。

如果我理解正确，客户端将在TLS握手期间创建一个主密钥，然后使用服务器的公钥对该主密钥进行加密并将其发送到服务器。然后将此主密钥（作为纯文本）用作对称密钥，用于加密正在进行的通信。它是否正确？

如果是，如果知道主密钥，如何解密数据？

一开始听起来很容易，所以我只写了这个脚本

$masterKey = '8ef36f0eb2c10ea6142693374f6c5c7ae65eee5f6bd45bd1990b08e6c144227382726496b795d62284bd8c6c0cadbbdb';

$someRandomEncryptedData = '170303001D314A69C7DF95E07AAF51FBDA01C178D45330BC902308DF8C418FA5B02B';

$sDecrypted = mcrypt_decrypt(MCRYPT_RIJNDAEL_256, pack('H*', $masterKey), pack('H*', $someRandomEncryptedData), MCRYPT_MODE_CBC);

echo $sDecrypted;

然后，我注意到主密钥的长度为96字节（二进制字符串为48），这导致PHP警告，因为密钥的长度应为256位（32字节）。我想念什么吗？

Answer 1

client during the request creates a master key, which is then encrypted using server's public key and sent to server. This master key (as a plain text) is then used as a symmetric key for encrypting ongoing communication. Is this correct?

Well, all-in-all, No.

因为你问的是DH和ECDH，它们是密钥协商协议：客户端不生成随机密钥，在服务器的公钥下对其进行加密，然后将其发送到服务器。这是密钥传输（如 RSA 密钥传输），而不是DH 或 ECDH。密钥传输将在 TLS 1.3 中消失。

TLS 有两个阶段：密钥协商和批量传输。这些阶段的定义不如 IPSec 中那样明确。当客户端和服务器使用 DH 或 ECDH 时，它们会到达一个premaster_secret. 这是 Diffie-Hellman 或椭圆曲线 Diffie-Hellman 的共享秘密。

他们采用premaster_secret，添加一个随机的客户端、一个随机的服务器，然后得到一个master_secret。然后他们获取master_secret并从中派生出 6 个对称密钥：

• 客户初始IV
• 客户端加密密钥
• 客户端mac密钥
• 服务器初始IV
• 服务器加密密钥
• 服务器 MAC 密钥

这些密钥用于为块密码或流密码提供密钥。

如果您注意到，每一方都会做出贡献premaster_secret- 客户端做出贡献g^a，服务器做出贡献g^b。然后每一方都对master_secret随机数做出贡献——客户端随机数和服务器随机数。

双方都有两个贡献的原因是传输方案（例如 RSA 密钥传输）不允许服务器为premaster_secret. 服务器必须等到派生后才能master_secret通过随机数贡献密钥材料。

所以进展是premaster_secret到master_secret6 个会话密钥。我不知道万能钥匙在哪里......

如果是，如果我知道主密钥，如何解密数据？

我认为如果你有主密钥，将其插入 Wireshark 通常会更容易。Wireshark wiki 讨论了主密钥（尽管我不知道它是什么 - 有一个premaster_secret和master_secret）。请参阅 Wireshark wiki 了解安全套接字层 (SSL)。

起初对我来说听起来很简单，所以我就写了这个脚本

是的... :) 查看 RFC 5246。这是传输层安全 (TLS) 协议版本 1.2。那我们就来说说简单的吧:)

然后我注意到主密钥是 96 字节长（48 作为二进制字符串）

96 字节是伪随机函数 (PRF) 的输出。查看 RFC 5246，第 13 页。