HTTPS详解

shonencc

于 2025-07-07 17:59:18 发布

阅读量538

点赞数 9

CC 4.0 BY-SA版权

文章标签： https 网络协议 wireshark

本文链接：https://blog.youkuaiyun.com/shonencc/article/details/149178434

首先申明，因为缺时间自己写（看之前的博文），现在发的都是相关知识点，把我认为非常好的文章发给大家共同学习，非软文。

文章来源：科来公众号

科来官网：https://www.colasoft.com.cn/training

文章中使用的软件为科来抓包软件技术交流版（科来官网免费下载），和试用方法和wireshark类似，多了很多小功能。之前也说过，作为客户曾参加科来的网络分析培训，推荐大家试用国产软件，有部分很好的功能：数据包属于哪个进程、哪个应用、矩阵等功能。个人认为分析会话数据流和数据包交互比wireshark更直观，如果是看数据包字段解码更推荐用wireshark。

前言

要做好运维工作，对协议的深入理解至关重要，今天我们为大家带来HTTPS协议讲解，一起从流量分析角度来学习一下HTTPS协议。前面我们用一个短篇系列详细讲解了HTTP协议，随着互联网发展，很多网站和WEB应用都已经将一般的HTTP升级为HTTPS，后文会讲解HTTPS的概念、工作过程、数据包解码及简单的分析方法。希望通过本篇系列文章，为大家在分析HTTPS协议带来帮助。

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的工作过程，还需要了解一点点密码学知识。不用担心，不会涉及复杂的算法和概念，大家都能懂。

对称加密

如下图：

我们用秘钥先把数据包进行加密，加密后再传给对面，对面收到数据包后再用同一把秘钥进行解密。这样只要加密算法够强健，就算中间人捕获到了通信数据包，解不了密就无法看到我们的通信内容。是不是很简单？

这种简单又快速的加密传输过程就叫对称加密。但这种设想却有一个bug……就是主机1用来加密的秘钥，怎么传递给主机2，如果传秘钥的过程中，秘钥被攻击者截获了，那加密还有什么意义呢？

非对称加密

如下图：

对上图作一下解释：

为了解决对称加密秘钥的传输问题。非对称的通信双方各自维护一对秘钥：公钥和私钥。其中公钥用作加密，私钥用作解密。过程如下：

首先，双方把公钥放到网上，让对方能够获取，而私钥保存在本地没有第二人能获取到。当主机1要发送数据给主机2时，主机1找到主机2的公钥，使用公钥对要发送的数据进行加密（通过某种非对称加密算法）；
加密后将数据发送出去，这时攻击者在互联网上截获数据后，因没有主机2的私钥，所以不能进行解密，看不到数据包的内容；
当主机2收到主机1用自己公钥加密的数据后，用自己的私钥进行解密，即能查看到解密后的数据。
同理，主机2要发数据给主机1，先获取到主机1的公钥对数据进行加密，加密后传输给主机1，主机1收到数据后用自己的私钥进行解密即可。

从上面步骤可见，非对称加密完美解决了秘钥传输的问题。但仍然存在问题，通信主机要为每一个会话都保存2个秘钥，加密解码过程复杂会影响通信速度。

问题来了，HTTPS选择速度快效率高的对称加密呢？还是选为了秘钥安全而牺牲速度的非对称加密呢？答案是：全都要！

HTTPS的完整过程

（学习HTTPS的成败在此一举，建议这部分一口气读完）

上面我们说HTTPS既要速度又要保证安全，怎么做到呢？核心思想如下：

我们首先用非对称加密算法，传递HTTPS的通信秘钥到对面；当秘钥安全到达对面后，双方再使用对称加密算法进行通信！

好了，当你理解了HTTPS加密通信的核心思想后，再来看HTTPS的完整过程就很好理解了（传递秘钥的过程也就是SSL/TLS通道建立的过程）。

为了让读者更易理解，我们选择最通用的HTTPS完整过程（只验证服务器身份），如下图：

秘钥协商过程（上图中的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数据包，提示协商失败的原因。

秘钥生成并验证（上图5~9步）：

步骤5：SSL第一次握手结束之后（上文介绍的阶段一），客户端以ClientKeyExchange 报文作为回应。

报文中包含随机数R3（预主密钥，英文文献中提及的Pre-master secret）。该报文用步骤3中获得的公钥进行加密（使用阶段一选定的非堆成加密算法）。

至此，客户端和服务器端就都拥有了三个随机数，然后用他们生成后面对称加密部分的秘钥（见步骤1中关于随机数的解释）。

步骤6：接着客户端继续发送ChangeCipherSpec报文。该报文会提示服务器，在此报文之后的通信会采用Pre-master secret生成的密钥进行加密。

步骤7：客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。

步骤8：服务器同样发送ChangeCipherSpec报文。客户端验证解密能力。

步骤9：服务器发送Finished报文。

HTTPS通信（上图10-12步）：

步骤10：服务器和客户端的Finished报文交换完毕之后，SSL/TLS加密通道就算建立完成。从此处开始进行应用层协议的通信，HTTPS即发送HTTP请求。

步骤11： 应用层协议通信，即发送HTTP响应。

步骤12： 最后由客户端断开连接。断开连接时，发送close_notify报文。上图中这步之后再发送TCP FIN报文来关闭TCP通信部分就省略掉了。

读到这里，恭喜你，HTTPS协议你已经完全理解和掌握了！（密码学内容，如具体的对称加密算法、非对称加密算法和摘要算法等需另外学习）

HTTPS数据包解码

在理解了HTTPS协议后，我们再从流量角度来看HTTPS的数据包。因为HTTPS的解码字段很多，不用每个字段都掌握，我们只用掌握对我们分析有帮助的信息即可。

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

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的流量，必须满足以下条件：

得到客户端或服务器端的私钥（客户端可通过设置浏览器环境变量导出秘钥日志文件）；
从ServerHello中确定服务器端选中的非对称加密算法是否支持解密（计算出秘钥后可解RAS或有条件的解部分DH、ECDHE算法；服务器仅能用私钥解RSA算法，对DH和各种曲线无能为力）；
有流量软件（或代码）支持导入秘钥进行解密（CSNAS及Wireshark均支持）；

具体流量解密方法，可访问科来官网查阅“HTTPS流量解密公开课”或参加“CSNA网络分析认证培训”进行深入学习，本篇文章点到为止，不再深入讲解密码学相关内容。

Certificate包解码

这一部分内容，可直接查看解码信息，也可以在CSNAS中的SSL证书日志中直观查看证书信息，还可以手动恢复证书后直接看证书文件。

SSL日志查看举例：

其他数据包解码

第二阶段和第三阶段的数据包因为已经加密，不再讲解解码。加密后的包解码如下：

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的联系和区别：

联系

继承关系：TLS（Transport Layer Security）是SSL（Secure Sockets Layer）的标准化升级版本。TLS 1.0基于SSL 3.0设计，由IETF（互联网工程任务组）正式规范，后续版本逐步优化。
目标一致：两者均旨在为网络通信提供加密、身份认证和数据完整性保护，防止窃听和篡改。
协议结构相似：均采用握手协议建立安全连接，通过记录协议加密传输数据。
区别

	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）