前言
要做好运维工作，对协议的深入理解至关重要，今天我们为大家带来HTTPS协议讲解，一起从流量分析角度来学习一下HTTPS协议。
前面说到《速通常见应用层协议：从流量视角打开HTTP（下）》为止，我们详细讲解完了HTTP协议这一重要知识点，而随着互联网发展，很多网站和WEB应用都已经将一般的HTTP升级为HTTPS，因此接下来我们就再讲讲HTTPS的概念、工作过程、数据包解码及简单的分析方法。希望通过本篇系列文章，为大家在分析HTTPS协议带来帮助。
本期互动问题，欢迎大家评论区一起聊聊：
由于HTTPS通过SSL/TLS协议对传输数据进行加密，要怎样才能突破限制进行解密？
HTTPS的概念和原理
HTTPS的概念
HTTPS（Hypertext Transfer Protocol Secure）是HTTP协议的安全增强版本。从名称就能知道，它实现的应用层功能就是HTTP，只不过它在HTTP的基础上加了“安全”的保障，这个安全保障就是在应用层和传输层中多加了一层SSL/TLS协议。因此，可以这样认为：HTTPS协议是通过SSL/TLS协议对HTTP数据进行加密，保护数据在传输过程中的完整性、机密性和身份认证。如下图：
我们前面讲HTTP协议时，可以从捕获的HTTP包中清晰的看到双方的通信内容，存在安全风险。因此HTTPS的核心目标是通过加密技术抵御HTTP通信中可能遇到的中间人攻击（MITM）、数据窃听和篡改风险。
HTTPS的工作原理
一图胜千言，如图：
从图中可以看出，HTTPS的关键就在SSL/TLS加密通道的建立！
HTTPS工作过程
对称加密和非对称加密
要真正理解HTTPS的工作过程，还需要了解一点点密码学知识。不用担心，不会涉及复杂的算法和概念，大家都能懂。
（1） 对称加密
如下图：
我们用密钥先把数据包进行加密，加密后再传给对面，对面收到数据包后再用同一把密钥进行解密。这样只要加密算法够强健，就算中间人捕获到了通信数据包，解不了密就无法看到我们的通信内容。是不是很简单？
这种简单又快速的加密传输过程就叫对称加密。但这种设想却有一个bug……就是主机1用来加密的密钥，怎么传递给主机2，如果传密钥的过程中，密钥被攻击者截获了，那加密还有什么意义呢？
（2） 非对称加密
如下图：
对上图作一下解释：
为了解决对称加密密钥的传输问题。非对称的通信双方各自维护一对密钥：公钥和私钥。其中公钥用作加密，私钥用作解密。过程如下：
i.首先，双方把公钥放到网上，让对方能够获取，而私钥保存在本地没有第二人能获取到。当主机1要发送数据给主机2时，主机1找到主机2的公钥，使用公钥对要发送的数据进行加密（通过某种非对称加密算法）；
ii.加密后将数据发送出去，这时攻击者在互联网上截获数据后，因没有主机2的私钥，所以不能进行解密，看不到数据包的内容；
iii. 当主机2收到主机1用自己公钥加密的数据后，用自己的私钥进行解密，即能查看到解密后的数据。
iv. 同理，主机2要发数据给主机1，先获取到主机1的公钥对数据进行加密，加密后传输给主机1，主机1收到数据后用自己的私钥进行解密即可。
从上面步骤可见，非对称加密完美解决了密钥传输的问题。但仍然存在问题，通信主机要为每一个会话都保存2个密钥，加密解码过程复杂会影响通信速度。
问题来了，HTTPS选择速度快效率高的对称加密呢？还是选为了密钥安全而牺牲速度的非对称加密呢？答案是：全都要！
2. HTTPS的完整过程
（学习HTTPS的成败在此一举，建议这部分一口气读完）
上面我们说HTTPS既要速度又要保证安全，怎么做到呢？核心思想如下：
我们首先用非对称加密算法，传递HTTPS的通信密钥到对面；当密钥安全到达对面后，双方再使用对称加密算法进行通信！
好了，当你理解了HTTPS加密通信的核心思想后，再来看HTTPS的完整过程就很好理解了（传递密钥的过程也就是SSL/TLS通道建立的过程）。
为了让读者更易理解，我们选择最通用的HTTPS完整过程（只验证服务器身份），如下图：
（1）密钥协商过程（上图中的1~4步）：
上图的数据交互过程用绿色线表示，因为这个过程，数据还是未加密的！
步骤1：客户端通过发送ClientHello报文开始SSL/TLS通信。报文中包含客户端支持的SSL/TLS指定版本、 加密组件（CipherSuite） 列表（所使用的加密算法及密钥长度等）、明文随机数R1、服务器hostname等信息 。
这里解释下随机数的概念（这一段很重要，千万不要跳过）：上面我们说SSL/TLS通道建立后，通信双方都会使用同样的密钥进行对称加密通信，现在有个致命问题：这个密钥由客户端生成安全，还是服务器端生成安全？因为双方都未验证对方身份，因此最好是双方都对对方持怀疑态度，双方共同来生成最终密钥才最安全！正因如此，科学家设计了解决方案：客户端生成随机数1通过ClientHello包发给服务器端、服务器生成随机数2通过ServerHello包发给客户端、在获取到服务器证书（和公钥后）验证服务器身份后客户端生成随机数3，用双方商量好的非对称加密算法将随机数3加密并发给服务器。所以非对称加密传输的实际是第3个随机数（又把它称之为预主密钥）。双方都有了3个随机数后，再使用PBF函数将它们计算生成真正的密钥。
步骤2：服务器可进行SSL/TLS通信时，会以ServerHello报文作为应答。包含协商SSL/TLS版本、确定加密组件（服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的）、明文随机数R2等。
步骤3：服务器发送Certificate报文。报文中包含服务器公钥和CA证书。
步骤4：最后服务器发送ServerHelloDone报文通知客户端最初阶段的SSL/TLS握手协商部分结束。（步骤2、3、4可能会合并到一个步骤完成）
当第一阶段完成后，通信双方实际得到了这些信息：使用的SSL/TLS协议版本、加密套件（对称加密算法、非对称加密算法、摘要算法）、两个明文随机数R1和R2、服务器证书（取得服务器公钥和验证服务器合法性）。
注意：双方握手协商可能不成功，比如版本不一致、证书有问题等，将通过发送一个Alert数据包，提示协商失败的原因。
（2）密钥生成并验证（上图5~9步）：
步骤5：SSL第一次握手结束之后（上文介绍的阶段一），客户端以ClientKeyExchange报文作为回应。
报文中包含随机数R3（预主密钥，英文文献中提及的Pre-master secret）。该报文用步骤3中获得的公钥进行加密（使用阶段一选定的非堆成加密算法）。
至此，客户端和服务器端就都拥有了三个随机数，然后用他们生成后面对称加密部分的密钥（见步骤1中关于随机数的解释）。
步骤6：接着客户端继续发送ChangeCipherSpec报文。该报文会提示服务器，在此报文之后的通信会采用Pre-master secret生成的密钥进行加密。
步骤7：客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。
步骤8：服务器同样发送ChangeCipherSpec报文。客户端验证解密能力。
步骤9：服务器发送Finished报文。
（3）HTTPS通信（上图10-12步）：
步骤10：服务器和客户端的Finished报文交换完毕之后，SSL/TLS加密通道就算建立完成。从此处开始进行应用层协议的通信，HTTPS即发送HTTP请求。
步骤11：应用层协议通信，即发送HTTP响应。
步骤12：最后由客户端断开连接。断开连接时，发送close_notify报文。上图中这步之后再发送TCP FIN报文来关闭TCP通信部分就省略掉了。
读到这里，恭喜你，HTTPS协议你已经完全理解和掌握了！（密码学内容，如具体的对称加密算法、非对称加密算法和摘要算法等需另外学习）
HTTPS数据包解码
在理解了HTTPS协议后，我们再从流量角度来看HTTPS的数据包。因为HTTPS的解码字段很多，不用每个字段都掌握，我们只用掌握对我们分析有帮助的信息即可。
（1） ClientHello包解码
在CSNAS捕获数据包后，可以通过多种过滤规则找到ClientHello包，如：protocol=ssl、protocol=https、sslhandshaketype=1等。
接着来看ClientHello中包含的信息：
图中标注①信息为：TLS的哪一种协议（包括握手协议（前面讲解的第一阶段）、改变密码协议（第二阶段）、应用数据协议（第三阶段）、警告协议（握手不成功或握手结束）等几种）；
图中标注②信息为：握手协议中的类型（1为ClientHello，2为ServerHello）;
图中标注③信息为：和服务器协商使用TLS的版本，图中为v1.2（如果两端支持的版本不一致，会导致握手失败）；
图中标注④信息为：客户端发送的第一个明文随机数R1；
图中标注⑤信息为：客户端提供给服务器端选择的密钥套件，对密钥套件中的每一条含义举例说明如下：
具体使用哪种算法，需要查看ServerHello中服务器作出的选择。
除这些关键信息外，还会在ClientHello中看到很多的扩展选项，用于客户端和服务器沟通运行TLS协议的一些具体事宜，CSNAS解码如下：
简单介绍下常见的扩展选项（新手可直接跳过）：
| 类型 | 扩展名称 | 功能描述 |
|---|---|---|
| 0xff01 | renegotiation_info | 表明可以支持安全的重协商 |
| 0x00 | server_name | 表明连接中要访问的virtual hostname |
| 0x23 | session_ticket | 表明支持没有状态的会话恢复 |
| 0x0d | signature_algorithms | 表明支持的签名算法和哈希函数对 |
| 0x05 | status_request | 表明支持OCSP Stapling |
| 0x3374 | next_protocol_negotiation | 表明支持NPN |
| 0x12 | signed_certificate_timestamp | 表明证书已通过Certificate Transparency公开 |
| 0x10 | application_layer_protocol_negotiation | 表明支持的应用层协议 |
对扩展选项有深入研究意向的，可查阅相关RFC文档：https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml
（2） ServerHello包解码
在CSNAS中解码如下：
图中标注①信息为：TLS协议类型，同上文ClientHello中的解释；
图中标注②信息为：握手协议中的类型（1为ClientHello，2为ServerHello）;
图中标注③信息为：和服务器协商使用TLS的版本，图中为v1.2（和上文中ClientHello协商一致）；
图中标注④信息为：客户端发送的第一个明文随机数R2；
图中标注⑤信息为：服务器端选定的密钥套件，后面交换密钥用非对称加密ECDHE_RSA算法、通信用AES_128对称加密算法、使用SHA256作摘要算法；
知识点扩展：
很多人总是想解密HTTPS的内容，那到底能不能解呢？下面简单讨论下此话题。
前面我们讲了HTTPS后面进行HTTP通信是用的对称加密，要解密就必须得到对称加密的密钥，而对称加密的密钥又是三个随机数生成的，R1和R2是明文，而R3是密文，通过非对称加密进行传输后，再经过计算得到真正的密钥。所以关键就是要得到R3才能得到HTTPS的解密密钥。怎么得到R3（预主密钥）？因为它是客户端生成的，所以可以让生成R3的应用（浏览器）将它另存一份在电脑中，这样我们就能得到R3进而计算出密钥。又或者在服务器端得到密文R3，将密文进行解密来得到R3（事实是R3常常是动态变化的密钥链，我们很难从服务器端获取到密钥链）。
以上是我们了解HTTPS加密过程后能推导出解密逻辑。但很不幸的是，最关键还是加密算法是否可逆（加密算法不在本篇讲解范围内）？否则就算拿到了密钥也可能解不了密！因为为了防止网络中间人的嗅探，保证HTTPS通信的绝对安全，很多算法是单向的（不可逆运算）或需要长时间超强算力，保证即使中间人捕获到数据包也无法解密。所以要解HTTPS的流量，必须满足以下条件：
i.得到客户端或服务器端的私钥（客户端可通过设置浏览器环境变量导出密钥日志文件）；
ii.从ServerHello中确定服务器端选中的非对称加密算法是否支持解密（计算出密钥后可解RAS或有条件的解部分DH、ECDHE算法；服务器仅能用私钥解RSA算法，对DH和各种曲线无能为力）；
iii. 有流量软件（或代码）支持导入密钥进行解密（CSNAS及Wireshark均支持）；
具体流量解密方法，可访问科来官网查阅“HTTPS流量解密公开课”或参加“CSNA网络分析认证培训”进行深入学习，本篇文章点到为止，不再深入讲解密码学相关内容。
（3） Certificate包解码
这一部分内容，可直接查看解码信息，也可以在CSNAS中的SSL证书日志中直观查看证书信息，还可以手动恢复证书后直接看证书文件。
（4） 其他数据包解码
第二阶段和第三阶段的数据包因为已经加密，不再讲解解码。加密后的包解码如下：
（5） HTTPS数据流解码
仅仅可以看到访问的域名信息，这是因为TLS握手的第一阶段还是明文的，有时还能看到一些证书的明文信息。
小结：在进行HTTPS流量分析时，一般就是看ClientHello、ServerHello和Certificate三种包的信息即可（注意：分析传输类故障是看数据包的四层信息，所有包都要看）。
HTTPS分析举例
例：浏览器访问某网站打开网页失败，请分析原因。
分析：从流量查看HTTPS中TLS建联是否成功，如果不成功，是否存在Alert信息，从Alert信息判断故障原因。
CSNAS抓包显示如下：
发现在ClientHello和ServerHello协议后，出现了Alert包，提示：版本不匹配。查看ClientHello包的版本信息：
客服端为TLS1.2
再查看ServerHello的版本信息：
服务器端为TLS1.0
造成TLS握手不成功，导致打开HTTPS网页失败。
知识点发散：
关于SSL和TLS的联系和区别：
（1）联系
继承关系：TLS（Transport Layer Security）是SSL（Secure Sockets Layer）的标准化升级版本。TLS 1.0基于SSL 3.0设计，由IETF（互联网工程任务组）正式规范，后续版本逐步优化。
目标一致：两者均旨在为网络通信提供加密、身份认证和数据完整性保护，防止窃听和篡改。
协议结构相似：均采用握手协议建立安全连接，通过记录协议加密传输数据。
（2）区别
| SSL | TLS | |
|---|---|---|
| 开发组织 | Netscape（1990年代） | IETF（1999年发布TLS 1.0） |
| 版本 | SSL 2.0、SSL 3.0（均已废弃） | TLS 1.0→1.1→1.2→1.3（逐步演进） |
| 安全性 | 存在严重漏洞（如POODLE攻击） | 逐步修复漏洞，安全性增强 |
| 加密算法 | 支持弱算法（如RC4、MD5） | 逐步淘汰弱算法，支持更安全的套件 |
| 密钥交换机制 | 静态RSA为主 | 支持前向保密（如ECDHE） |
（3）TLS1.3的优点
解决了之前版本的安全缺陷，逐步成为行业标准。
性能：更快的连接速度，适合高延迟场景（如移动网络）。
安全：强制前向保密、精简加密套件，抵御已知攻击。
简洁性：协议设计去冗余，降低实现错误风险。
总结
在学习了HTTP协议后，本篇文章我们又从数据包的角度深入介绍了HTTPS协议，相信大家对怎么通过流量分析HTTPS相关的应用和业务有了新的思路！在今后的工作中，通过不断地分析实践，大家会更深刻地理解HTTPS。后面我们还会陆续介绍更多常见应用层协议，请大家持续关注！