python做网站快吗,自己做网站想更换网址,玉溪市建设局网站,音乐制作软件手机版Web 安全是一项系统工程#xff0c;任何细微疏忽都可能导致整个安全堡垒土崩瓦解。拿 HTTPS 来说#xff0c;它的「内容加密、数据完整性、身份认证」三大安全保证#xff0c;也会受到非法根证书、服务端配置错误、SSL 库漏洞、私钥被盗等等风险的影响。很多同学认为只要访问…Web 安全是一项系统工程任何细微疏忽都可能导致整个安全堡垒土崩瓦解。拿 HTTPS 来说它的「内容加密、数据完整性、身份认证」三大安全保证也会受到非法根证书、服务端配置错误、SSL 库漏洞、私钥被盗等等风险的影响。很多同学认为只要访问的网站地址前有一把小绿锁就绝对安全其实不然。本文通过介绍三种最常规的 HTTPS 流量解密方法及原理浅谈一下 HTTPS 的安全风险。
Man-in-the-middle
Man-in-the-middle中间人简称为 MITM能够与网络通讯两端分别创建连接交换其收到的数据使得通讯两端都认为自己直接与对方对话事实上整个会话都被中间人所控制。简而言之在真正的服务端看来中间人是客户端而真正的客户端会认为中间人是服务端。
实现中间人攻击有各种各样的手段这里不展开讨论。一些常见的 HTTP/HTTPS 抓包调试工具都是通过创建本地 Proxy 服务再修改浏览器 Proxy 设置来达到拦截流量的目的他们的工作原理与中间人攻击一致。我用过的这一类工具有Fiddler、Charles 和 whistle。我在「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 流量。这时在浏览器中可以看到这样的证书链 RSA Private Key
我在「使用 Wireshark 调试 HTTP/2 流量」这篇文章中写到Wireshark 的抓包原理是直接读取并分析网卡数据要想让它解密 HTTPS 流量有两个办法1如果你拥有 HTTPS 网站的加密私钥可以用来解密这个网站的加密流量2某些浏览器支持将 TLS 会话中使用的对称密钥保存在外部文件中可供 Wireshark 加密使用。那篇文章介绍了第二种方案本文简单介绍第一种。
打开 Wireshark 的 SSL 协议设置参考下图把 IP、端口、协议和证书私钥都配上私钥必须存为 PEM 格式 然后访问私钥对应的网站可以看到流量已被解密 可以看到截图中的 HTTP/1 加密数据已被还原为明文。那么这种方式能解密 HTTP/2 流量吗先说结论不能具体原因下面慢慢分析。
我们知道TLS 握手阶段需要进行密钥交换和服务端认证这两个重要的操作密钥交换是为了在不安全数据通道中产生一个只有通信双方知道的共享密钥 Premaster Secret进而生成 Master Secret 以及后续对称加密 Session Key 和 MAC Key。而客户端之所以要进行服务端认证是为了确保连接到拥有网站私钥的合法服务器。
最常见的密钥交换方式是 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的 DHDiffie-Hellman算法。下图是 DH 密钥交换过程 上图中的 Server DH Parameter 是用证书私钥签名的客户端使用证书公钥就可以验证服务端合法性。相比 RSA 密钥交换DH 由传递 Premaster Scret 变成了传递 DH 算法所需的 Parameter然后双方各自算出 Premaster Secret。
对于这种情况由于 Premaster Secret 无需交换中间人就算有私钥也无法获得 Premaster Secret 和 Master Secret。也就是说 Wireshark 无法通过配置 RSA Private Key 的方式解密「使用 ECDHE 进行密钥交换」的加密流量。当然使用 ECDHE 后如果被中间人拿到私钥尽管无法用于解密之前流量但他可以实施 MITM 攻击来解密之后的流量所以私钥还是要保管好。
在 ECDHE 密钥交换中签名算法可以使用 RSA 或 ECDSA取决于证书类型也就是目前密钥交换 签名有三种主流选择
RSA 密钥交换无需数字签名ECDHE 密钥交换、RSA 数字签名ECDHE 密钥交换、ECDSA 数字签名
以下是使用这三种密钥交换方式的网站在 Chrome 中的截图 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 这种具有前向安全性的密钥交换。如下图 这种方案的详细介绍请参考「使用 Wireshark 调试 HTTP/2 流量」这篇文章。
SSLKEYLOGFILE 文件记录的是 HTTPS 数据传输中最重要的加密信息如果不是出于调试目的一般也没人会主动配置这个环境变量所以这个方案基本不会对 HTTPS 安全性产生影响。
总结
Fiddler 这类工具通过往系统导入根证书来实现 HTTPS 流量解密充当中间人角色。要防范真正的 HTTPS 中间人攻击网站方需要保管好自己的证书私钥和域名认证信息为了防范不良 CA 非法向第三方签发自己的网站证书还要尽可能启用 Certificate Transparency、HTTP Public Key Pinning 等策略用户方不要随便信任来历不明的证书更不要随意导入证书到根证书列表还要养成经常检查常用网站证书链的习惯。
RSA 密钥交换没有前向安全性这意味着一旦私钥泄漏之前所有加密流量都可以解开。为此网站方需要启用使用 ECDHE 作为密钥交换的 CipherSuite或者直接使用 ECC 证书用户方需要弃用不支持 ECDHE 的古董操作系统及浏览器。
对于浏览器而言HTTPS 毫无秘密通过浏览器生成的 SSLKEYLOGFILE 文件Wireshark 可以轻松解密 HTTPS 流量。另外如果浏览器被安装恶意扩展即使访问安全的 HTTPS 网站提交的数据一样可以被截获。这种客户端被攻击者控制引发的安全问题无法通过 HTTPS 来解决。
原文链接三种解密 HTTPS 流量的方法介绍 | JerryQu 的小站
