如何在 ssl 密钥交换期间查看 Wireshark 中的加密密钥？答案

【问题标题】：How to see the encrypted key in wireshark, during ssl key exchange?如何在 ssl 密钥交换期间查看 Wireshark 中的加密密钥？
【发布时间】：2012-05-01 23:52:00
【问题描述】：

在 Wireshark 中，我可以看到来自我的 PC 的加密数据。它不使用 diffie hellman 算法进行密钥交换，因为我只看到 Client Key Exchange 数据包，但有 no Server Key Exchange 数据包。这意味着浏览器正在向服务器发送加密密钥（使用服务器的公钥加密）。
但我在该数据包（“客户端密钥交换”）中看不到任何加密数据。如何查看加密密钥？

【问题讨论】：

我有点惊讶你选择接受一个实际上并没有回答你问题的答案，除非我错过了什么......
@Bruno 现在我从正确的人那里得到了正确的答案，我接受了。谢谢你告诉我我的错误:)
如果您和@Ashwin 选择加入 SO 以相互提供代表，请不要打扰（很容易看到您各自的个人资料，包括已删除的答案）。您问的是一个非常详细的问题，需要具备 SSL 方面的专业知识（并假设询问它的人知道查看数据包的基础知识）。诚然，我虽然您对加密的内容更感兴趣，而不仅仅是结果。 Ashwin 的回答对于试图了解 SSL 的人来说是微不足道的：如果您无法删除前 2 个字节（无论如何都要使用最新版本的 Wireshark），请不要费心学习更多。
至于不赞成和反对我的正确答案，你们只是厚颜无耻，特别是考虑到阿什温已经询问了有关主秘密本身的更多细节（很明显，你们两个一起研究这些问题，这当然不是问题）。是的，我否决了你的问题（只有这个问题），只是因为你似乎没有决定要问什么（就像你在许多其他关于 SSL 或 security.SE 的问题中所做的那样）。

标签： encryption ssl wireshark

【解决方案1】：

这里写的很棒，解释了 SSL 的工作原理，在握手过程中任何时候都不要注意是通过网络发送的私钥。

http://4orensics.wordpress.com/2011/10/21/ssl-in-a-nutshell/

长话短说，没有服务器的私钥就无法解密 SSL 流（除非您为 NSA 或其他机构工作），但是您可能需要考虑在握手期间进入服务器和客户端之间，如果用户不检查您在业务中出示的证书的有效性。

这里有一个工具可以为你做到这一点

http://mitmproxy.org/

值得注意的是，我强烈推荐关于 SSL Mitm（中间人）攻击的 sans 阅览室文章。

【讨论】：

我认为 OP 根本没有尝试访问私钥，而是尝试访问共享密钥（可能已经访问了服务器的私钥）。
没有“私钥（证书）”之类的东西。服务器的证书通过网络发送。私钥，不，当然不是。

【解决方案2】：

您不会看到加密的共享密钥，它没有被交换。使用RSA authenticated key exchange 时可以看到加密的预主密钥。（请注意，使用 Ephemeral Diffie-Hellman 并不是看不到服务器密钥交换消息的唯一原因：它还可以使用 DH_DSS 或 DH_RSA 密码套件，但据我所知这是不寻常的）。

如果您按照有关decrypting SSL with Wireshark 的说明进行操作，请使用“SSL 调试文件”选项将日志存储到文件中。（请注意，在较新版本的 Wireshark 中，用户界面在配置私钥的方式上略有变化。）

日志文件将包含预主密钥和共享密钥。

（顺便说一句，您当然需要服务器的私钥来执行此操作。）

使用 Wireshark 页面上提供的示例数据，您可以获得：

pre master encrypted[128]:
65 51 2d a6 d4 a7 38 df ac 79 1f 0b d9 b2 61 7d 
73 88 32 d9 f2 62 3a 8b 11 04 75 ca 42 ff 4e d9 
cc b9 fa 86 f3 16 2f 09 73 51 66 aa 29 cd 80 61 
0f e8 13 ce 5b 8e 0a 23 f8 91 5e 5f 54 70 80 8e 
7b 28 ef b6 69 b2 59 85 74 98 e2 7e d8 cc 76 80 
e1 b6 45 4d c7 cd 84 ce b4 52 79 74 cd e6 d7 d1 
9c ad ef 63 6c 0f f7 05 e4 4d 1a d3 cb 9c d2 51 
b5 61 cb ff 7c ee c7 bc 5e 15 a3 f2 52 0f bb 32 

pre master secret[48]:
03 00 ff 84 56 6d a0 fb cc fd c6 c8 20 d5 f0 65 
18 87 b0 44 45 9c e3 92 f0 4d 32 cd 41 85 10 24 
cb 7a b3 01 36 3d 93 27 12 a4 7e 00 29 96 59 d8 

master secret[48]:
1e db 35 95 b8 18 b3 52 58 f3 07 3f e6 af 8a a6 
ab c3 a4 ed 66 3a 46 86 b6 e5 49 2a 7c f7 8c c2 
ac 22 bb 13 15 0f d8 62 a2 39 23 7b c2 ff 28 fb 

key expansion[136]:
11 60 e4 e1 74 e9 a1 cf 67 f9 b7 bc ef bc a7 c7 
b3 f7 33 aa b2 42 d0 1c a6 4e fb e9 9b 13 dd 29 
63 aa 17 1f 47 71 95 71 08 e0 4b 8e e1 da 7b 4a 
5a f3 c2 32 bd e0 a5 82 6d 14 44 3a d6 cb 2d c0 
7d 57 be a8 37 de 5d d9 a1 07 fd 1b 22 71 b9 4b 
7a 1e 0f 70 37 14 97 0a f0 db 98 3b 7b 74 e3 2d 
51 66 2e 31 68 90 ac 6f e6 53 3c c9 5e 48 0c 05 
bc 9f 92 e7 f9 91 98 f5 95 1c c4 bf d9 cb 26 ef 
35 70 5e ad 21 22 3e f6 
Client MAC key[20]:
11 60 e4 e1 74 e9 a1 cf 67 f9 b7 bc ef bc a7 c7 
b3 f7 33 aa 
Server MAC key[20]:
b2 42 d0 1c a6 4e fb e9 9b 13 dd 29 63 aa 17 1f 
47 71 95 71 
Client Write key[32]:
08 e0 4b 8e e1 da 7b 4a 5a f3 c2 32 bd e0 a5 82 
6d 14 44 3a d6 cb 2d c0 7d 57 be a8 37 de 5d d9 
Server Write key[32]:
a1 07 fd 1b 22 71 b9 4b 7a 1e 0f 70 37 14 97 0a 
f0 db 98 3b 7b 74 e3 2d 51 66 2e 31 68 90 ac 6f 
Client Write IV[16]:
e6 53 3c c9 5e 48 0c 05 bc 9f 92 e7 f9 91 98 f5 
Server Write IV[16]:
95 1c c4 bf d9 cb 26 ef 35 70 5e ad 21 22 3e f6

【讨论】：

所以在“客户端密钥交换”数据包中无法查看加密的主密钥？
@Ashwin，当然可以，我刚刚添加了它。您为什么不自己尝试 Wireshard 示例？顺便说一句，加密的主密钥直接是客户端密钥交换数据包内容的（部分）内容，它周围只有几个额外的字节用于 ASN.1 结构。
抱歉，我之前的评论中的意思是 XDR 而不是 ASN.1。

【解决方案3】：

直到最近对 ClientKeyExchange 的剖析是这样的（1.6 及以下版本）：

TLSv1 Record Layer: Handshake Protocol: Client Key Exchange
    Content Type: Handshake (22)
    Version: TLS 1.0 (0x0301)
    Length: 134
    Handshake Protocol: Client Key Exchange
        Handshake Type: Client Key Exchange (16)
        Length: 130

但如果你使用this verison(1.7.2 以上)，关键剖析会是这样的：

TLSv1 Record Layer: Handshake Protocol: Client Key Exchange
    Content Type: Handshake (22)
    Version: TLS 1.0 (0x0301)
    Length: 134
    Handshake Protocol: Client Key Exchange
        Handshake Type: Client Key Exchange (16)
        Length: 130
        RSA Encrypted PreMaster Secret
            Encrypted PreMaster length: 128
            Encrypted PreMaster: 761b1beac35e59de9a3bb9f74ebf9109b738e8ad346

可以看到加密的pre-master:)

【讨论】：