它接缝，如果使用 HTTPS 协议，浏览器和 Web 服务器之间传输的包都是加密的。浏览器必须支持其与 Web 服务器的通信会话，即所谓的证书。
所以我认为很明显，我们可以使用相同的证书来解密 Wireshark 在登录 HTTPS 站点期间捕获的包。
我用谷歌搜索，发现一些教程说应该提供私钥，我认为这是不可能和不切实际的。
顺便提一句。以下 shell 命令从主机获取证书，是否有生成公钥的工具？
echo QUIT | openssl s_client -connect <site>:443 | sed -ne '/BEGIN CERT/,/END CERT/p'
提前致谢。
不，即使您拥有证书，您也无法从网络捕获中解密 HTTPS/SSL 会话。这就是SSL 所基于的公钥密码术的全部要点。
您在浏览器密钥库中拥有的证书将验证服务器公钥的有效性。所述公钥是可访问的，但它们不能用于解密会话数据包，因为加密算法不是对称的。
您需要服务器的私钥才能解密 SSL 会话，在正常情况下很难获得这些私钥。
另请参阅有关TLS的 Wikipedia 文章以获取更多信息。
编辑：
我将以外行的方式添加更多信息，主要是从上面的两个链接中窃取的，以使事情更清楚一些。
公钥密码术基于非对称加密算法。这些涉及两个密钥，而不是一个，一个公钥和一个私钥。这两个密钥组成一个密钥对。假设一个足够强大的算法，任何用公钥加密的东西都只能用私钥加密，反之亦然。“每个人”都可以广泛访问公钥，而私钥则安全存储并且仅供其所有者使用。这有什么帮助？
服务器有一个密钥对，它由一个世界可读的公钥和一个安全存储（除了服务器本身之外的任何人都无法访问）的私钥组成。
客户端使用服务器的公钥在每个加密会话开始时为对称算法加密一个相当长的随机密钥。该密钥被发送到服务器。
由于对称密钥是这样加密的，所以只能使用服务器的私钥解密。这意味着它不能从捕获的网络流中提取，并且由于它用于会话的其余部分，因此以后传输的任何信息也不能。
服务器使用它的私钥来检索会话对称密钥，一切都很好。
是吗？上述方案还有一个问题！客户端如何获取服务器的公钥？更具体地说，它如何知道它与服务器正确对话，而不是某个设法将自己插入中间的骗子（参见中间人攻击）？
客户不可能知道每一个公钥——有数百万个。它必须从服务器中检索它们，然后以某种方式确保它们属于他们感兴趣的服务器。
这就是公钥密码学的另一个功能的用武之地。以前我们使用公钥来加密数据，以便只有它的预期目的地才能解密它。现在我们做相反的事情：我们使用私钥来加密数据，这样它就只能用公钥来解密。本质上，我们对数据进行签名，这样如果使用公钥解密，人们就会知道数据来自服务器。这有什么帮助？
安装浏览器时，它预装了数量相对较少的公钥（通常称为证书）。这些属于证书颁发机构 (CA)，它们是被认为值得信赖的实体（通常是威瑞信等公司、政府甚至某些机构）。证书颁发机构使用相应的私钥对 Internet 上可用的其他公钥等进行签名。
因此，当浏览器联系服务器并接收其公钥时，该密钥应使用证书对中的私钥进行签名。该证书对同样由另一个证书对签名，依此类推，直到浏览器找到一个公钥，该公钥使用与预安装的根证书之一相对应的私钥签名。您可能想阅读我以前的答案以了解有关根证书的更多信息，或者只是阅读 Wikipedia 文章。
由于每个公钥都是连续签名的，直到我们得到一个可信密钥，客户端现在可以确定连接另一端的服务器确实是 MyBank.com，而不是下一个咖啡馆桌子上的某个罪犯的笔记本电脑。正在弄乱无线连接。
虽然 SSL 算法很弱（因此有一系列 SSL 协议版本），但如今这些攻击通常针对以下实现：
使用特制或格式错误的证书来欺骗浏览器（及其弱实现），使其认为公钥是由可信实体签署的，而实际上并非如此。
破坏客户端软件（例如病毒）的完整性以在生成对称密钥时捕获它们。然而，在大多数情况下，通常更容易在将感兴趣的数据输入浏览器时捕获它们，例如捕获用户输入信用卡号时的键盘敲击。
破坏服务器本身并窃取私钥。虽然它不像针对毫无戒心的客户那么容易，但它已经发生了，它有可能破坏大量加密会话。当前的公钥基础设施 (PKI)具有用于撤销和禁用受损或其他无效密钥的完整机制。
The last attack can be defeated if the client sends a temporary public key of its own instead of a symmetric key and use an asymmetric algorithm for the whole session. That would make it impossible for an attacker to compromise past sessions by stealing the server's private key. This technique is the basis for ensuring Perfect Forward Secrecy, but unfortunately not all servers implement it yet due to compatibility or performance reasons.
thkala is spot on. You can, assuming you have MiTM, under common circumstances forward a self signed certificate to the victim for which you have the private key, then forward the requests by the victim to the destination server using the servers' real certificate. This will require the vicitm to accept a certificate warning though.
击败 Ssl 的另一种方法是剥离 ssl 会话，查找 sslstrip。