这是一个创建于 290 天前的主题，其中的信息可能已经有所发展或是发生改变。
看到流行的解法基本都是自身作为通信的一方直接抓包，通过拿到的密钥在 wireshark 里是可以解密的。现在的问题是如果拿到已经抓好的 RSA 加密包，一对密钥都有，能否对其解密呢？请大佬指教。
 |
1
tool2d 290 天前
我试过用 chrome 实时导出 SSLKEYLOGFILE 密钥文件，然后正常抓包。过后，用 wireshark 命令行参数(tshark 的 tls.keylog_file)，可以读取这个文件，并且后期解密到明文。
但这文件里，并不是完全是密钥，主要是 masterkey 。 /t/922534 |
 |
2
neilp 290 天前
大概率不行. 当今 tls 协议中, RSA 的加密方式已经废弃. 所以无论 RSA 证书还是 ECC 证书, 都只负责签名.
Dh/ECdh 负责交换对称密钥. AES 负责加密. 所以要想解密, 必须要有 SSLKEYLOGFILE . 来获得 AES 的密钥. 楼上说的 wireshark 解密, 是我知道的可能唯一的方式. 你只有证书和私钥没用. |
 |
3
yumusb 290 天前
只有密钥不行
|
 |
4
billlee 290 天前 via Android
现在的 TLS 密钥交换都是前向保密的，要中间人攻击才行。
|
 |
5
iX8NEGGn 290 天前 via iPhone
不行，密钥协商时，两端临时使用的参数，只保存在内存中，交换参数计算得到主密钥后就销毁了，这玩意叫完美向前安全
|
 |
6
kelaoli OP 谢谢各位大佬，我在信息安全面前感受到了自己的无知。
我想实现的功能是，通信双方的完整交互报文都拿到了，要在第三台机器上将 TLS 解密。 不懂 TLS ，大概了解了下密钥是由双方生成的随机数和 pre-master-key 组成，两边的随机数虽然会变，但开始交互随机数的时候报文还是未加密的，我理解是可以拿到，就是这个 master key 不知道怎么理解？是公钥还是私钥呢，还是说对通信双方来说正好是反的。 大神们说了很多，我还是没理解，为啥在本机上有办法可以直接抓解密后的包，到了另一台机器上就解不了？这里的区别还是没弄懂。请大佬不吝赐教。 |
|
7
iX8NEGGn 289 天前  1
我简单的介绍下“DH 密钥协商算法”，想了解更多可以搜索这个关键字。
算法步骤： 步骤 1 ）发送方和接收方协商一个大质数 p 和 p 的一个原根 g ； 步骤 2 ）发送方秘密选择一个大随机整数 a ，计算 A = ga % p ，公开发送 A 给接收方； 步骤 3 ）接收方秘密选择一个大随机整数 b ，计算 B = gb % p ，公开发送 B 给发送方； 步骤 4 ）双方计算出密钥 发送方：Sa = Ba % p = (gb % p)a % p = gab % p ； 接收方：Sb = Ab % p = (ga % p)b % p = gab % p ； 可知：K = Sa = Sb ； 知道 p 、g 、A 、B 不能计算出密钥 K ，除非还至少知道 a 或 b 其中一个，a 、b 并不发送给对方，只保存在各自内存中，协商出 K 后就销毁了。 也就是，虽然开始的大质数和原根 p 、g 以及随机数 A 、B 都未加密，但是算不出 K 。 实例： 假如 p = 23 ，g = 5 发送方选取的秘密数字 a = 6 ， 那么 A = 56 % 23 = 8 ， 将 A 发送给接收方 接收方选取的秘密数字 b = 15 ，那么 B = 515 % 23 = 19 ，将 B 发送给发送方 发送方计算出的密钥 Sa = 196 % 23 = 2 接收方计算出的密钥 Sb = 815 % 23 = 2 |
|
8
iX8NEGGn 289 天前
|
|
9
iX8NEGGn 289 天前 1
“两边的随机数虽然会变，但开始交互随机数的时候报文还是未加密的，我理解是可以拿到”
随机数就上面说的 a 、b ，你拿不到。 “就是这个 master key 不知道怎么理解？是公钥还是私钥呢” 既不是公钥也不是私钥，公钥和私钥是为了确保上面说的公开参数 p 、g 、A 、B 被中间人两边冒充。 上面说的 K 便是 “pre-master-key （预主密钥）”，然后由预主密钥经过一系列变化得到“master key （主密钥）”。 “本机上有办法可以直接抓解密后的包，到了另一台机器上就解不了” 本机抓包就是交换公开参数 p 、g 、A 、B 时，中间人两边冒充是对方把 A 和 B 都替换掉。也就是对客户端替换掉服务端发来的 B ，自己和客户端协商了一个预主密钥。对服务端替换掉客户端发来的 A ，自己和服务端协商了另一个预主密钥。中间人拿着两个预主密钥分别和两端通信，但两端都误以为是和真正的对方通信。 |
|
13
iX8NEGGn 289 天前 via iPhone
#11 ，理解正确。
不过我有一句话少打了一个“不”字，应该是：“公钥和私钥是为了确保上面说的公开参数 p 、g 、A 、B 不被中间人两边冒充。（使用私钥、公钥对它们进行签名和验签）”。 以及信任本机本地证书后，中间人欺骗两端替换掉 A 、B 时，可以选择替换成同一个数，这样两个预主密钥就是相同的，只有一个预主密钥。 |
|
14
neilp 289 天前
@julyclyde
早期有支持 用 RSA 作为密钥交换算法. 用 服务端的 RSA 公钥加密 对称密钥. wireshark 中最初的解密 ssl 流量就支持 RSA. 后来被废弃了. 都用 dh/ecdh 了. |
|
16
neilp 288 天前
@julyclyde 那个版本真记不得. 我曾经解密过.
这个页面下: https://www.openssl.org/docs/man1.1.1/man1/ciphers.html 参照这一段: kRSA, aRSA, RSA Cipher suites using RSA key exchange or authentication. RSA is an alias for kRSA. 其他的自行谷歌吧. |
Select Language