use*_*657 2 encryption ssl wireshark
它接缝,如果使用HTTPS协议,在浏览器和Web服务器之间传输的包都是加密的.并且所有浏览器都必须支持与Web服务器的通信会话,即所谓的证书.
所以我认为很明显我们可以使用相同的证书来解密在HTTPS站点登录期间由Wireshark捕获的包.
我用谷歌搜索,并找到一些教程说应该提供私钥,我认为这是不可能和不实用的.
BTW.以下shell命令从主机获取证书,是否有工具来生成公钥？
echo QUIT | openssl s_client -connect <site>:443 | sed -ne '/BEGIN CERT/,/END CERT/p'
提前致谢.
不,即使您拥有证书,也无法从网络捕获中解密HTTPS/SSL会话.这就是SSL所基于的公钥加密的重点.
您在浏览器密钥库中拥有的是将验证服务器公钥有效性的证书.所述公钥是可访问的,但是它们不能用于解密会话分组,因为加密算法不是对称的.
您需要在私人的的密钥服务器,以descrypt SSL会话,在正常情况下,它是非常难获得这些.
有关更多信息,另请参阅有关TLS的Wikipedia文章.
编辑:
我将以外行术语添加更多信息,大部分都是从上面的两个链接中删除,以使事情更加清晰.
公钥加密基于非对称加密算法.这些涉及两个密钥,而不是一个,一个公钥和一个私钥.这两个键由一对密钥组成.假设一个足够强大的算法,用公钥加密的任何东西只能用私有加密,反之亦然.公钥可以被"每个人"广泛访问,而私钥被安全地存储并且仅由其所有者使用.这有什么用？
服务器有一个密钥对,由一个世界可读的公钥和一个安全存储(除了服务器本身以外的任何人都无法访问)私钥组成.
客户端使用服务器的公共密钥在每个加密会话的开始加密的对称算法相当长的随机密钥.该密钥被发送到服务器.
由于对称密钥是这样加密的,因此只能使用服务器的私钥对其进行解密.这意味着,它不能从捕获的网络流中提取,并且由于它被用于会话的其余部分,可以既没有任何的被发送以后的信息.
服务器使用其私钥来检索会话对称密钥,一切都很好.
是吗？上述方案还有一个问题!客户端如何获取服务器的公钥？更具体地说,它是如何知道它与服务器正确对话,而不是一些设法插入中间的骗子(参见Man In The Middle攻击)？
客户端不可能知道每一个公钥 - 它们有数百万个.它必须从服务器检索它们,然后以某种方式确保它们属于他们感兴趣的服务器.
这是公钥加密的另一个功能的用武之地.以前我们使用公钥来加密数据,这样只有它的预定目的地才能解密它.现在我们做相反的事情:我们使用私钥来加密数据,这样它只能用公钥解密.基本上我们签署数据,以便如果用公钥解密,人们就会知道数据来自服务器.这有什么用？
安装浏览器时,它预安装了相对较少数量的公钥(通常称为证书).属于证书颁发机构(CA)的是那些被认为值得信赖的实体(通常是Verisign,政府或某些机构等公司).证书颁发机构使用相应的私钥来签署 Internet中可用的其他公钥等.
因此,当浏览器联系服务器并接收其公钥时,该密钥应使用证书对中的私钥进行签名.该证书对同样会被另一个证书对等签名,直到浏览器出现一个公钥,该公钥是使用与其预安装的根证书之一对应的私钥签名的.您可能想要阅读我以前的答案,了解有关根证书的更多信息,或者只是阅读维基百科的文章.
由于每个公钥都是在我们到达可信密钥之前连续签名的,所以客户现在可以确定连接另一端的服务器确实是例如MyBank.com而不是,例如,在下一个咖啡桌中的某个犯罪笔记本电脑正在搞乱无线连接.
虽然存在弱SSL算法(因此SSL协议版本的连续性),但现在攻击通常针对实现:
使用特制或格式错误的证书来欺骗浏览器(及其弱实现),使其认为公钥是由可信实体签署的,而实际上并非如此.
妥协客户端软件(例如病毒)的完整性,以在生成对称密钥时捕获它们.然而,在大多数情况下,通过例如在用户键入其信用卡号时捕获键盘敲击来将有趣数据输入浏览器中通常更容易捕获有趣数据.
妥协服务器本身并窃取私钥.虽然它并不像针对毫无戒心的客户那么容易,但它已经发生了,它有可能危及大量加密会话.当前的公钥基础结构(PKI)具有用于撤销和禁用受损密钥或其他无效密钥的整体机制.
如果客户端发送自己的临时公钥而不是对称密钥并且对整个会话使用非对称算法,则可以取消最后一次攻击.这将使攻击者无法通过窃取服务器的私钥来破坏过去的会话.此技术是确保完全向前保密的基础,但遗憾的是,由于兼容性或性能原因,并非所有服务器都实现了它.
| 归档时间： |
|
| 查看次数： |
3618 次 |
| 最近记录： |