三种解密 HTTPS 流量的方法介绍

标签: 网络系统 | 发表时间:2016-04-05 14:54 | 作者:JerryQu 的小站
出处:http://www.blogread.cn/it/

标签:   HTTPS

   Web 安全是一项系统工程,任何细微疏忽都可能导致整个安全壁垒土崩瓦解。拿 HTTPS 来说,它的「内容加密、数据完整性、身份认证」三大安全保证,也会受到非法根证书、服务端配置错误、SSL 库漏洞、私钥被盗等等风险的影响。很多同学认为只要访问的网站地址前有一把小绿锁就绝对安全,其实不然。本文通过介绍三种最常规的 HTTPS 流量解密方法及原理,浅谈一下 HTTPS 的安全风险。

Man-in-the-middle

   Man-in-the-middle(中间人,简称为 MITM),能够与网络通讯两端分别创建连接,交换其收到的数据,使得通讯两端都认为自己直接与对方对话,事实上整个会话都被中间人所控制。简而言之,在真正的服务端看来,中间人是客户端;而真正的客户端会认为中间人是服务端。

   实现中间人攻击有各种各样的手段,这里不展开讨论。一些常见的 HTTP/HTTPS 抓包调试工具,都是通过创建本地 Proxy 服务,再修改浏览器 Proxy 设置来达到拦截流量的目的,他们的工作原理与中间人攻击一致。我用过的这一类工具有: FiddlerCharleswhistle。我在「 HTTP 代理原理及实现(一)」一文中介绍的 HTTP 普通代理,扮演的就是 HTTP 中间人角色。

   本文主要讨论 HTTPS 中间人,简单示意如下:

  Server <---> Local Proxy <---> Browser         ^                 ^       HTTPS(1)          HTTPS(2)

   上述 HTTPS(1) 连接,是中间人冒充客户端,与服务端建立的连接,由于 HTTPS 服务端一般不认证客户端身份,这一步通常没有问题。而对于 HTTPS(2) 连接来说,中间人想要冒充服务端,必须拥有对应域名的证书私钥,而攻击者要拿到私钥,只能通过这些手段:1)去网站服务器上拿;2)从 CA 处签发证书;3)自己签发证书。

   要防范前两点,需要网站做好各个方面的安全防护,从主机安全到网站安全(避免私钥被盗),从域名解析安全到域名邮箱安全(避免攻击者重签证书)。而攻击者自己签发的证书,无法通过系统内置根证书的验证,默认无法用于中间人攻击。

   对于 Fiddler 这一类调试工具来说,能够解密 HTTPS 流量的关键在于他们会往系统受信任的根证书列表导入自己的证书,这样他们的自签证书就能被浏览器信任。进入 Fiddler 设置中的「HTTPS」Tab,勾选相关功能后,就可以顺利解密和修改 HTTPS 流量。这时在浏览器中可以看到这样的证书链:

    fiddler root

RSA Private Key

   我在「 使用 Wireshark 调试 HTTP/2 流量」这篇文章中写到:Wireshark 的抓包原理是直接读取并分析网卡数据,要想让它解密 HTTPS 流量,有两个办法:1)如果你拥有 HTTPS 网站的加密私钥,可以用来解密这个网站的加密流量;2)某些浏览器支持将 TLS 会话中使用的对称密钥保存在外部文件中,可供 Wireshark 加密使用。那篇文章介绍了第二种方案,本文简单介绍第一种。

   打开 Wireshark 的 SSL 协议设置,参考下图,把 IP、端口、协议和证书私钥都配上(私钥必须存为 PEM 格式):

    wireshark ssl config

   然后访问私钥对应的网站,可以看到流量已被解密:

    decrypt http1 over tls

   截图中的加密数据是以 HTTP/1 传输的,这种方式能解密 HTTP/2 流量吗?结论是:不能!具体原因下面慢慢分析。

   我们知道,TLS 握手阶段需要进行密钥交换和服务端认证这两个重要的操作,密钥交换是为了在不安全数据通道中产生一个只有通信双方知道的共享密钥 Premaster Secret,进而生成 Master Secret 以及后续对称加密 Session Key 和 MAC Key。而客户端进行服务端认证的目的是确保连接到拥有网站私钥的合法服务器。

   最常见的密钥交换方式是 RSA,下面这张图清晰的描述了这个过程:

    ssl handshake rsa 图片来源

   Client Random 和 Server Random 明文传输,中间人可以直接查看。客户端生成 Premaster Secret 后,用服务端证书公钥加密后发送,如果服务端拥有对应的私钥,就可以成功解密得到 Premaster Secret。这时,客户端和服务端拥有相同的 Client Random、Server Random 和 Premaster Secret,可以各自算出相同的后续所需 Key。

   可以看到,这种方式合并了密钥交换和服务端认证两个步骤,如果服务端能解密 Premaster Secret,也就意味着服务端拥有正确的私钥。中间人没有私钥,无法得到 Premaster Secret,也就无法解密后续流量。

   对于 Wireshark 来说,配置某个网站的私钥后,能解密这个网站「使用 RSA 进行密钥交换」的加密流量就很容易理解了。

   显然,RSA 密钥交换有一个很大的问题:没有前向安全性(Forward Secrecy)。这意味着攻击者可以把监听到的加密流量先存起来,后续一旦拿到了私钥,之前所有流量都可以成功解密。

   实际上,目前大部分 HTTPS 流量用的都是 ECDHE 密钥交换。ECDHE 是使用椭圆曲线(ECC)的 DH(Diffie-Hellman)算法。下图是 DH 密钥交换过程:

    ssl handshake diffie hellman 图片来源

   上图中的 Server DH Parameter 是用证书私钥签名的,客户端使用证书公钥就可以验证服务端合法性。相比 RSA 密钥交换,DH 由传递 Premaster Scret 变成了传递 DH 算法所需的 Parameter,然后双方各自算出 Premaster Secret。

   对于这种情况,由于 Premaster Secret 无需交换,中间人就算有私钥也无法获得 Premaster Secret 和 Master Secret。也就是说 Wireshark 无法通过配置 RSA Private Key 的方式解密「使用 ECDHE 进行密钥交换」的加密流量。当然,使用 ECDHE 后,虽然中间人拿到私钥也无法解密之前的流量,但他可以实施 MITM 攻击来解密之后的流量,所以私钥还是要保管好。

   相比 RSA 既可以用于密钥交换,又可以用于数字签名;ECC 这边就分得比较清楚了:ECDHE 用于密钥交换,ECDSA 用于数字签名。也就是目前密钥交换 + 签名有三种主流选择:

  • RSA 密钥交换、RSA 数字签名;

  • ECDHE 密钥交换、RSA 数字签名;

  • ECDHE 密钥交换、ECDSA 数字签名;

   以下是使用这三种密钥交换方式的网站在 Chrome 中的截图:

    key exchange

   HTTP/2 中只能使用 TLSv1.2+,还禁用了几百种 CipherSuite(详见: TLS 1.2 Cipher Suite Black List)。实际上,HTTP/2 允许使用的 CipherSuite 必须采用具有前向安全性的密钥交换算法,不允许使用 RSA 密钥交换。这也是为什么 RSA Private Key 无法解密 HTTP/2 加密流量。

SSLKEYLOGFILE

   Firefox 和 Chrome 都会在系统环境变量存在 SSLKEYLOGFILE 文件路径时,将每个 HTTPS 连接产生的 Premaster Secret 或 Master Secret 存下来。有了这个文件,Wireshark 就可以轻松解密 HTTPS 流量,即使是使用了 ECDHE 这种具有前向安全性的密钥交换,如下图:

    decrypt http2 over tls

   这种方案的详细介绍请参考「 使用 Wireshark 调试 HTTP/2 流量」这篇文章。

    SSLKEYLOGFILE 文件记录的是 HTTPS 数据传输中最重要的加密信息,如果不是出于调试目的,一般也没人会主动配置这个环境变量,所以这个方案基本不会对 HTTPS 安全性产生影响。

总结

   Fiddler 这类工具通过往系统导入根证书来实现 HTTPS 流量解密,充当中间人角色。要防范真正的 HTTPS 中间人攻击,网站方需要保管好自己的证书私钥和域名认证信息,为了防范不良 CA 非法向第三方签发自己的网站证书,还要尽可能启用 Certificate TransparencyHTTP Public Key Pinning 等策略;用户方不要随便信任来历不明的证书,更不要随意导入证书到根证书列表,还要养成经常检查常用网站证书链的习惯。

   RSA 密钥交换没有前向安全性,这意味着一旦私钥泄漏,之前所有加密流量都可以解开。为此,网站方需要启用使用 ECDHE 作为密钥交换的 CipherSuite,或者直接使用 ECC 证书;用户方需要弃用不支持 ECDHE 的古董操作系统及浏览器。

   对于浏览器而言,HTTPS 毫无秘密,通过浏览器生成的 SSLKEYLOGFILE 文件,Wireshark 可以轻松解密 HTTPS 流量。另外,如果浏览器被安装恶意扩展,即使访问安全的 HTTPS 网站,提交的数据一样可以被截获。这种客户端被攻击者控制引发的安全问题,无法通过 HTTPS 来解决。


您可能还对下面的文章感兴趣:

  1. HTTPS证书生成原理和部署细节 [2016-02-29 23:47:16]
  2. 你所不知道的 HSTS [2016-02-29 23:39:07]
  3. iOS安全系列之二:HTTPS进阶 [2015-09-21 14:23:09]
  4. iOS安全系列之一:HTTPS [2015-09-21 14:13:58]
  5. HTTPS, SPDY和 HTTP/2性能的简单对比 [2015-01-21 23:38:40]
  6. SSLStrip 的未来 —— HTTPS 前端劫持 [2015-01-05 23:41:09]
  7. Linux使用curl访问https站点时报错汇总 [2014-12-28 23:46:32]
  8. 在 Django/Flask 开发服务器上使用 HTTPS [2014-11-07 00:00:46]
  9. HTTPS的七个误解 [2011-02-13 20:59:41]
  10. 外链点击没有 referrer 信息?! [2010-02-09 09:09:58]

相关 [解密 https 流量] 推荐:

三种解密 HTTPS 流量的方法介绍

- - IT技术博客大学习
标签:   HTTPS.    Web 安全是一项系统工程,任何细微疏忽都可能导致整个安全壁垒土崩瓦解. 拿 HTTPS 来说,它的「内容加密、数据完整性、身份认证」三大安全保证,也会受到非法根证书、服务端配置错误、SSL 库漏洞、私钥被盗等等风险的影响. 很多同学认为只要访问的网站地址前有一把小绿锁就绝对安全,其实不然.

https协议

- - 互联网 - ITeye博客
SSL 协议的握手过程   .       为了便于更好的认识和理解 SSL 协议,这里着重介绍 SSL 协议的握手协议. SSL 协议既用到了公钥加密技术(非对称加密)又用到了对称加密技术,SSL对传输内容的加密是采用的对称加密,然后对对称加密的密钥使用公钥进行非对称加密. 这样做的好处是,对称加密技术比公钥加密技术的速度快,可用来加密较大的传输内容,公钥加密技术相对较慢,提供了更好的身份认证技术,可用来加密对称加密过程使用的密钥.

Go和HTTPS

- - Tony Bai
近期在构思一个产品,考虑到安全性的原因,可能需要使用到 HTTPS协议以及双向数字证书校验. 之前只是粗浅接触过HTTP( 使用Golang开 发微信系列). 对HTTPS的了解则始于那次 自行搭建ngrok服务,在那个过程中照猫画虎地为服务端生成了一些私钥和证书,虽然结果是好 的:ngrok服务成功搭建起来了,但对HTTPS、数字证书等的基本原理并未求甚解.

Google https被屏蔽

- - 月光博客
  根据Google透明度报告 显示,从上周(5月27日)开始,Google的部分服务开始被屏蔽,其中最主要的是HTTPS搜索服务和Google登录服务,所有版本的Google都受到影响,包括Google.hk和Google.com等.   此次屏蔽的方法主要屏蔽Google部分IP地址的443端口,包括google.com.hk,accounts.google.com的部分IP的443端口被封,导致部分中国用户无法访问Google搜索和Gmail,由于Google的IP地址非常多,而被屏蔽的只是其中部分IP,因此只有部分用户受到了影响.

HTTPS的二三事

- - 细语呢喃
前几篇博文都是有关HTTPS的东西,有人可能会问,什么是HTTPS. 因此,本文主要来解答这些疑惑. Alice和Bob是情人,他们每周都要写信. Alice 写好后,送到邮局,邮局通过若干个快递员到Bob,Bob回信过程类似. 这是可以看成的简单的http的传输. 有一天,Alice觉得,要是写的信中途被人拆开了呢.

最新网址 https://72.52.124.208

- chanjw - 电驴下载基地
精彩世界 cmule.com 我们传递.

最新网址 https://72.52.124.209

- Asker - 电驴下载基地
精彩世界 cmule.com 我们传递.

Google升级HTTPS加密

- 请叫我火矞弟 - Solidot
民不拜天又不拜孔子留此膝何为 写道 "Google 修改了启用HTTPS服务的加密方法,以应对未来技术发展后可能造成的解密行为. 这项升级适用于Gmail、Docs和Google+. 现在的HTTPS实现借助于只有域名主人所掌握的私钥生成的session key来加密服务器和客户端之间的流量.

HTTPS那些事儿(一)

- - CSDN博客互联网推荐文章
最近看了《http权威指南》的几个章节,对HTTPS有了部分了解,同时在网上查阅了一些资料,遂打算记录一下心得,写的仓促,肯定有很多错误的地方,欢迎大家指正. 那么在介绍https之前,有必要先解释下http. http是一个非常简单又非常复杂的协议,说其简单,是我们每天都在用它,而且又浑然不觉,貌似很简单的样子.

Nginx 安装 HTTPS 证书

- - idea's blog
基本步骤可以参考 这篇文章, 但这篇文章有一个致命错误, 就是没有安装 INTERMEDIATE CA, 照样会被浏览器显示证书不可信.. 生成 server.key.orig. 生成 server.csr 和 server.key. 拿着 server.csr 去证书厂商买证书. 买完后, 厂商会给你发两个证书 server.crt 和 server.intermediate.crt.