互联网协议 — HTTPS 安全的超文本传输协议
目录
文章目录
- 目录
- 为什么需要 HTTPS
- HTTPS
- HTTPS 单向认证
- HTTPS 双向认证
- 解密 HTTPS 报文
- 使用 Fiddler 解密
- Decrypting HTTPS traffic without a key
- Decrypting HTTPS traffic with Wireshark
- 参考文档
为什么需要 HTTPS
-
保护隐私（Privacy）：所有信息都是加密传播，第三方无法窃听数据。如果使用 HTTP 明文传输数据的话，很可能被第三方劫持数据，那么所输入的密码或者其他个人资料都被暴露在他人面前，后果可想而知。
-
数据完整性（Integraty）：一旦第三方篡改了数据，接收方会知道数据经过了篡改，这样便保证了数据在传输过程中不被篡改。
-
身份认证（Identification）：第三方不可能冒充身份参与通信，因为服务器配备了由证书颁发机构（Certificate Authority，简称 CA）颁发的安全证书，可以证实服务器的身份信息，防止第三方冒充身份。
HTTPS
HTTPS 就是 HTTP 与 SSL/TLS 的组合，本质为 HTTP over SSL/TLS。这里所说的 HTTP 并不特指某个版本（HTTP/1.1、HTTP/2 或 HTTP/3）。使用 HTTPS，你的浏览器和服务器之间的通信将通过加密和经过身份验证的通道传输。通过 HTTPS 而不是 HTTP 提供内容可以让访问者确信他们所看到的内容是由合法内容所有者给出的，并且通信是安全的，不会被窃听。
因为是先有 HTTP 再有 HTTPS。所以，HTTPS 的设计要考虑到对原有 HTTP 的兼容性。兼容性包括很多方面。比如：已有的 Web 应用可以无缝地迁移到 HTTPS。所以，很容易得出如下几个结论：
- HTTPS 还是要基于 TCP 来传输的。
- 单独使用一个新的协议，把 HTTP 协议包裹起来，即 HTTP over SSL/TLS，在原有的 HTTP 数据外面加了一层 SSL 的封装。
TLS（Transport Layer Security Protocol，传输层安全协议）主要目的是提供隐私和数据两个通信应用之间的完整性。该协议由两层组成：TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。
当使用 TLS 时，客户端和服务器之间的 HTTPS 连接具有以下属性：
- 内容加密：采用混合加密技术，中间者无法直接查看明文内容。
- 验证身份：通过证书认证客户端访问的是自己的服务器。
- 保护数据完整性：防止传输的内容被中间人冒充或者篡改。
- 首先通过非对称加密建立通信过程。
- 在握手阶段，使用 3 个随机数，一方面防止 “随机数 C” 被猜出，另一方增加 Session key 随机性。
- Client 发出支持的 “对称/非对称加密” 算法。
- Server 返回选用的 “对称/非对称加密” 算法。
- Client 对算法进行确认。
- Server 对算法进行确认。
显然，HTTPS 能够带来可靠的安全性，但考虑到 HTTPS 要比 HTTP 更加消耗服务器资源，而且相比于 HTTP 建立连接握手时需要消耗的大量时间影响用户端的体验。还有 SSL 证书的成本也要算进去，使得很多人望而却步，尤其是在移动网络下。
在 Web 领域，传输延迟（Transmission Latency）是 Web 性能的重要指标之一，低延迟意味着更流畅的页面加载以及更快的 API 响应速度。而一个完整的 HTTPS 链接的建立大概需要以下四步：
- DNS 查询
- TCP 握手（ 1 RTT）
- TLS 握手 （2 RTT）：对于 TLS 1.2 或者更早的版本，这步需要 2 个 RTT。
- 建立 HTTP 连接（1 RTT）：一旦 TLS 连接建立，浏览器就会通过该连接发送加密过的 HTTP 请求。
我们假设 DNS 的查询时间忽略不计，那么从开始到建立一个完整的 HTTPS 连接大概一共需要 4 个 RTT，如果是浏览刚刚已经访问过的站点的话，通过 TLS 的会话恢复机制，第三步 TLS 握手能够从 2 RTT 变为 1 RTT。
总结：
- 建立新连接 ：4 RTT + DNS 查询时间。
- 会话恢复：3 RTT + DNS 查询时间。
直到 TLS 1.3 的发布，HTTPS 的性能才得到了一次飞跃。TLS 1.3 将是 Web 性能以及安全的一个新的里程碑，随之 TLS1.3 带来的 0-RTT 握手，淡化了大家之前对使用 HTTPS 性能上的隐忧。于此同时，在未来随着 HTTP/2 的不断普及，强制性使用 HTTPS 成为了一种必然。
HTTPS 单向认证
- 客户端向服务端发送 SSL 协议版本号、加密算法种类、随机数等信息。
- 服务端给客户端返回 SSL 协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书。
- 客户端使用服务端返回的信息验证服务器的合法性，包括：
- 证书是否过期。
- 发行服务器证书的 CA 机构是否可靠（通过查询浏览器或本机内的 CA 证书）。
- 返回的公钥是否能正确解开返回的 CA 证书中的数字签名（通过使用本机或浏览器内置的 CA 公钥进行解密）。
- 服务器证书上的域名是否和服务器的实际域名相匹配。
- 验证通过后，将继续进行通信，否则，终止通信。
- 客户端向服务端发送自己所能支持的对称加密方案，供服务器端进行选择。
- 服务器端在客户端提供的加密方案中选择加密程度最高的加密方式。
- 服务器将选择好的加密方案通过明文方式返回给客户端。
- 客户端接收到服务端返回的加密方式后，使用该加密方式生成产生随机码，用作通信过程中对称加密的对称密钥，使用服务端返回的公钥进行加密，将加密后的随机码发送至服务器。
- 服务器收到客户端返回的加密信息后，使用自己的私钥进行解密，获取对称加密密钥。
- 在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中信息的安全。
HTTPS 双向认证
双向认证和单向认证类似，它额外增加了服务端对客户端的认证。
- 客户端向服务端发送 SSL 协议版本号、加密算法种类、随机数等信息。
- 服务端给客户端返回 SSL 协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书。
- 客户端使用服务端返回的信息验证服务器的合法性，包括：
- 证书是否过期。
- 发行服务器证书的 CA 是否可靠（通过查询浏览器或本机内的 CA 证书）。
- 返回的公钥是否能正确解开返回证书中的数字签名（通过使用本机或浏览器内置的 CA 公钥进行解密）。
- 服务器证书上的域名是否和服务器的实际域名相匹配。
- 验证通过后，将继续进行通信，否则，终止通信。
- 服务端要求客户端发送客户端的证书即客户端证书公钥，客户端会将自己的证书发送至服务端。
- 验证客户端的证书，通过验证后，会获得客户端的公钥。
- 客户端向服务端发送自己所能支持的对称加密方案，供服务器端进行选择。
- 服务器端在客户端提供的加密方案中选择加密程度最高的加密方式。
- 将加密方案通过使用之前获取到的公钥进行加密，返回给客户端。
- 客户端收到服务端返回的加密方案密文后，使用自己的私钥进行解密，获取具体加密方式，而后，产生该加密方式的随机码，用作加密过程中的密钥，使用之前从服务端证书中获取到的公钥进行加密后，发送给服务端。
- 服务端收到客户端发送的消息后，使用自己的私钥进行解密，获取对称加密的密钥，在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中信息的安全。
解密 HTTPS 报文
使用 Fiddler 解密
当 Fiddler 安装在电脑上的时候，会特别询问用户：“您介意我将自己的自签名的证书安装在电脑上吗？”
如果你想让 Fiddler 帮你调试跑在 SSL/TLS 加密层上的 HTTP 代码，你不得不允许他安装证书。于是你的回答是：“好的，请继续！”
于是 Fiddler 就把自己的证书安装到用户电脑里，并受到操作系统/浏览器的信任。理论上只要从浏览器发出的任何 HTTPS 连接，都会被 Fiddler 劫持，Fiddler 发给浏览器的证书都受到浏览器的信任。
Fiddler 做为协助开发人员调试代码的一个工具，这样做是可以理解的。但是一旦测试完还是需要将安装的证书卸载，因为 “受信任的证书” 是一把双刃剑，既可以帮助你，同时也可能给你带来安全的隐患。
Decrypting HTTPS traffic without a key
这种解密方式不需要私钥文件，所以适用于客户端对 HTTPS 进行解密。
- 安装抓包工具
yum install -y tcpdump curl
- 抓包
tcpdump -i eth0 -ne -w https.pcap
- 访问 HTTPS 服务端
SSLKEYLOGFILE=ssl_log.txt curl --ciphers dhe_rsa_aes_128_cbc_sha_256 --insecure https://www.csdn.net/
注意：使用 --ciphers 选项强制 curl 作为客户端使用 RSA 密钥交换技术进行密钥交换。
如果报错：
curl: (35) Cannot communicate securely with peer: no common encryption algorithm(s).
说明 HTTPS 服务端不支持 dhe_rsa_aes_128_cbc_sha_256 加密算法，从 Server Hello 可以看出服务端采用的是 ECDHE_RSA_AES_128_GCM_SHA256。
所以我们可以不知道加密算法，让双方协商：
SSLKEYLOGFILE=ssl_log.txt curl --insecure https://www.csdn.net/
如此的，我们得到了两个文件：
- .pcap：抓包文件
- ssl_log.txt：包含在密钥交换期间生成的临时密钥 CLIENT_RANDOM。e.g.
# SSL/TLS secrets log file, generated by NSS
CLIENT_RANDOM a101a3296bb043a3f8a5cb583426fc2b079c14f41fb8f09621efc256f7b3a0b5 949c519906a38fb0f76468649aedf85f2c11fe31393ff7bfaf74a31d170d9cd5ebe6ff6dc7d3f86bdf6c070741270b13
CLIENT_RANDOM 2e99d3681c39a5b2de92524aa2914991d6d7e1a91131680e2323c7c67befd80a 45be6964023d6ead919a46de449684d8e544df692b2f5f5c7757fa4435d1ecef3b04cc7a55af7edeaf27cf43d64324db
接下来导入 .pcap 到 Wireshark，配置 TLS 协议的 (Pre)-Master-Secretlog filename 加载路径。
可以看见被 TLS 封装的 HTTP 报文就暴露出来了：
查看 TLS 流：
就可以得到 HTTPS 的解密数据了：
注：如果你在 CentOS7 上使用 Wireshark 来对加密算法 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 进行解密，那么你需要编译安装最新版本。
Decrypting HTTPS traffic with Wireshark
这种方式需要 HTTPS 服务端（Web 服务器）的私钥，所以适用于在服务端对 HTTPS 进行解密。
注：这种方式不适用于 TLS1 1.3，因为 1.3 版本使用了 ephemeral Diffie-Hellman 秘钥交换技术。
接下来的步骤与上述大同小异，区别在于导入到 Wireshark 的是服务端的私钥文件。
To decrypt the traffic go to Edit -> Preferences, find SSL under Protocols and add a new RSA key. The key should be the private key from the web server, the protocol should be http, the port should be 443 and the IP address should match the IP address of the web server in the packet capture:
If everything works as expected, after clicking Apply the HTTP requests should now be decrypted and visible in Wireshark:
参考文档
https://blog.csdn.net/mrpre/article/details/81532469