HTTPS 为什么是安全的 _ (下)

2401_84281703

于 2024-05-16 18:20:30 发布

阅读量361

点赞数 4

分类专栏： 2024年程序员学习文章标签：网络安全 web安全面试

本文链接：https://blog.csdn.net/2401_84281703/article/details/138971061

版权

2024年程序员学习专栏收录该内容

39 篇文章 0 订阅

订阅专栏

本人从事网路安全工作12年，曾在2个大厂工作过，安全服务、售后服务、售前、攻防比赛、安全讲师、销售经理等职位都做过，对这个行业了解比较全面。

最近遍览了各种网络安全类的文章，内容参差不齐，其中不伐有大佬倾力教学，也有各种不良机构浑水摸鱼，在收到几条私信，发现大家对一套完整的系统的网络安全从学习路线到学习资料，甚至是工具有着不小的需求。

最后，我将这部分内容融会贯通成了一套282G的网络安全资料包，所有类目条理清晰，知识点层层递进，需要的小伙伴可以点击下方小卡片领取哦！下面就开始进入正题，如何从一个萌新一步一步进入网络安全行业。

需要体系化学习资料的朋友，可以加我V获取：vip204888 （备注网络安全）

学习路线图

其中最为瞩目也是最为基础的就是网络安全学习路线图，这里我给大家分享一份打磨了3个月，已经更新到4.0版本的网络安全学习路线图。

相比起繁琐的文字，还是生动的视频教程更加适合零基础的同学们学习，这里也是整理了一份与上述学习路线一一对应的网络安全视频教程。

网络安全工具箱

当然，当你入门之后，仅仅是视频教程已经不能满足你的需求了，你肯定需要学习各种工具的使用以及大量的实战项目，这里也分享一份我自己整理的网络安全入门工具以及使用教程和实战。

项目实战

最后就是项目实战，这里带来的是SRC资料&HW资料，毕竟实战是检验真理的唯一标准嘛~

面试题

归根结底，我们的最终目的都是为了就业，所以这份结合了多位朋友的亲身经验打磨的面试题合集你绝对不能错过！

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以点击这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

HTTP 将不复存在？这其实是个伪命题。事实上，HTTP 将永远存在。因为 HTTPS 并不是一个全新的产物，它是基于 HTTP 的。

我们回顾一下 TCP/IP 分层模型 和 OSI 参考模型 。

OSI 参考模型对通信过程中必要的功能进行了归纳，但其只是一个模型，对各层的作用做了一系列粗略的界定。TCP/IP 协议分层与 OSI 参考模型略微不同，将传输层以上全部归为应用层。上图中的 TCP/IP 协议只分了四层，但一些资料中会将其分为五层，加上了物理层，倒也并不影响理解。

HTTP 属于应用层协议，它直接与用户交互，但并不负责真正的数据传输，它依赖于传输层协议 (一般是 TCP) 来将数据发送到对端。常见的传输层协议有 TCP 和 UDP 。同样，传输层也并不真正进行数据传输，它又依赖于网络层协议，一般是 IP 协议。网络层依赖链接层和物理设备进行真正的数据传输。正是得益于良好的分层结构，让我们可以很方便的实现 HTTPS 。

有这样一句广泛流传的话：计算机科学领域里的任何问题，都可以通过引入一个中间层来解决。(如果不行，那么就再来一层！) 用这句话来形容 HTTPS 是再适合不过了。

在原来的分层协议中，应用层直接将明文数据交给传输层来处理。而在 HTTPS 中，应用层和传输层之间加了一层 TLS 来负责数据的加密，这样一来，应用层和传输层无需任何改变，就可以安全传输信息了。所以除了 HTTP，理论上任何应用层协议都可以基于 TLS 进行安全传输，例如 FTPS，SMTP…

TLS 的前身是 SSL 。SSL(Secure Sockets Layer) 是网景公司设计的安全传输协议，有 1.0，2.0，3.0 三个版本，但目前均已弃用。互联网工程组 IETF 将 SSL 标准化，并改名为 TLS 。1999 年发布了 TLS 1.0，2006 年发布了 TLS 1.1，2008 年发布了 TLS 1.2，2018 年发布了 TLS 1.3 。每个新版本都强化了性能和安全性，目前使用最为广泛的是 TLS 1.2 ，之前的版本都将在今年被废弃。

说了半天 HTTPS ，那么它到底是如何运作的呢？我听很多朋友抱怨过，流程太复杂，看过一段时间就忘了。我在这里强烈建议大家用 wireshark 抓包分析一遍，再亲手画一个流程图，这样很容易就记住了。

认证密钥协商数据加密

HTTPS 的整体思路很简单，它其实就是做了三件事：认证、密钥协商、数据加密 。

通信双方身份的验证
通信双方协商出一个安全的会话密钥，注意中间人攻击的问题
使用会话密钥对称加密通信内容

看起来很简单，但 HTTPS 做了大量的工作来保证通信的安全。下面就来实战抓包来学习 HTTPS 的通信流程。

HTTPS 通信流程

下文以浏览器访问 zhihu.com 抓取到的实际通信流程进行分析。

建立 TCP 连接

TLS 是基于 TCP 连接上建立的安全层，所以第一步 三次握手 (SYN => SYN, ACK => ACK) 建立 TCP 连接是必不可少的。

Client Hello

建立 TCP 连接之后，浏览器率先发出 Client Hello 消息。

Client Hello

挑几个重点字段说一下。

Version 表示客户端最高支持的 TLS 版本，向下兼容。上图中是 TLS 1.2 (0x0301) 。

Random 是客户端生成的一个随机数，后面用于生成主密钥。下文中用 client_random 表示。Random 是 32 字节，但其实随机数的长度是 28 字节，前面四个字节是 UNIX 时间戳，并没有什么意义。

Session ID 传递给服务器用于复用缓存的 TCP 连接。这里 Session ID 是有值的，但并不代表就一定会复用之前的连接，这要看服务器是否能找到该 Session ID 的连接。

Cipher Suites 是客户端支持的密码套件列表，服务器会从中选择合适的密码套件，排在第一个的优先选择。密码套件是 TLS 协议的核心，可以说它是保证 TLS 安全性的根本。密码套件决定了 TLS 使用的身份认证、密钥交换、对称加密、消息认证码的算法。在 TLS 1.2 中可选择的密码套件比较多，但在 TLS 1.3 中进行了删减，去除了部分不再安全的密码套件。

Compression Methods 表示客户端支持的压缩方法。由于存在安全性问题，一般不启用，值为 null 。

Extension 为扩展字段，可以让客户端和服务器在不更新 TLS 版本的基础上获取更多的能力。客户端可以发送服务端不理解的扩展，但服务端不能返回客户端无法理解的扩展，否则将发生错误。另外在 TLS 1.3 中，为了保证向下兼容性，并没有去修改 Version 字段，而是通过 Supported Version: TLS 1.3 这样的扩展字段来说明支持 TLS 1.3 。

Server Hello

服务端在收到 Client Hello 之后，根据客户端发来的消息内容，作出回应。

Version 表示服务器选定使用的 TLS 版本，上图中是 TLS 1.2 (0x0303) 。

Random 是服务器生成的随机数，其作用和 client_random 一样，也是用来计算主密钥，下文中用 server_random 表示。现在浏览器，服务器都拥有了 client_random 和 server_random 两个随机数。

Session ID 为 null 表示服务器没有可复用的 TCP 连接。因为我模拟的第一次建立 TCP 连接的完整的 HTTPS 通信流程，所以必然是没有复用的。如果 Session ID 不为空的话，其实走的是一个连接的恢复流程，这样就抓不到完整的 HTTPS 流程了。后面可以简单演示一下。

Cipher Suite 表示服务端选定的密码套件是 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 。简单画个图分析一下。

后续的整个加密流程都会遵循该密码套件。

密钥协商算法 选定了 ECDHE (椭圆曲线迪菲-赫尔曼密钥交换) 。大多数资料中介绍的都是使用 RSA ，密钥协商算法的不同会导致后续通信流程的不同，后面会详细介绍。

身份验证算法 其实就是验证服务器证书签名的，这里是 RSA 。

对称加密算法 是用来加密通信数据的。

摘要算法 用于随机数生成以及 HMAC 算法。

Certificate

服务器在发送 Server Hello 之后，会立马发送服务器的证书链信息。其实 Certificate 和 Server Hello 是在同一个数据包里面的，以降低延迟。

下图是知乎服务器返回的证书链，可以看到有两张，zhihu.com 的服务器证书和中间证书。注意，根证书通常不包含在其中。因为根证书就在计算机中，没有必要再去传输。

两张证书的签名算法都是 sha256WithRSA ，公钥也返回给了客户端，客户端可以进行证书验证。验证不通过，就没有办法进行下面的交互了。

暂停一下 …

下面的通信流程会因为密钥交换算法的不同，产生一些区别。所以这里先暂停一下，画张图总结一下上面的流程。

到目前为止，浏览器，服务器都持有了 client_random 和 server_random 。浏览器也拿到了服务器的证书，可以对服务器进行身份认证。

接下来要做的就是协商密钥了。但这里协商的并不是会话密钥，而是一个叫做 pre_master 的预备主密钥。还记得服务端选定的密码套件吗？TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 ，该密码套件指定的密钥协商算法是 ECDHE ，这是目前比较常用的算法，另外还可以使用 RSA 进行密钥协商，现在已经不是很常用了，TLS 1.3 已经废弃了 RSA 密钥协商。但大多数文章中说的还都是 RSA 算法。

RSA 密钥协商很简单。浏览器生成一个随机数，使用服务器公钥加密之后发送给服务器，服务器接收之后使用自己的私钥解密拿到随机数。这个随机数就是 pre_master。但是这个方案不具备 前向安全性 。

在 TLS 握手阶段，中间人可以拿到 client_random, server_random 以及加密的 pre_master 。由于没有服务器私钥，中间人没有办法进行解密，只能将加密的历史通信数据保存下来。也正是因为服务器私钥是不会变化的，一旦通过社会工程学或者其他因素导致的私钥泄露，所有历史通信数据都会被破解。所以，最好的方案是一次一密。准确的说是，每个 TCP 连接都使用不同的密钥。这正是 ECDHE 密钥交换所能提供的特性。

知乎目前也是采用的 ECDHE 来协商密钥，继续分析下去。

Server Key Exchange

这是一条服务器发送给浏览器的消息。注意如果使用 RSA 生成 pre_master 的话，是没有这条消息的，因为不需要服务器再提供任何参数了。

我并不了解 ECDHE 的具体数学原理，只能大概阐述一下。服务端返回了 EC Diffie-Hellman Server Params ，可以理解为密钥交换服务器需要准备的参数，包括命名曲线，DH 公钥，签名信息等等。同样，浏览器也会准备需要的参数，一般就是一个 DH 公钥。双方利用这些公开的信息就可以协商出 pre_master。

这些参数中间人都可以拿到，但中间人是算不出 pre_master 的。关于具体的数学原理，你可以在网络上搜索一下。

Server Hello Done

一条固定格式的消息，用来通知浏览器我该提供的都提供完了，你可以干你的事情了。

这里，我想问一个问题：Server Hello Done 消息发送完成之前，浏览器进行服务器证书校验了吗？ 你可以思考一下。

答案是没有。因为 Server Hello 、Certificate、Server Key Exchange、Server Hello Done 这几条消息其实都是在同一个 TCP 数据包中的。拆分为多个包，只会徒增网络延迟。

Client Key Exchange

浏览器收到 Server Hello Done 之后会立马校验服务器证书。校验通过之后开始协商 pre_master 。

如果密钥协商算法是 RSA ，浏览器直接生成一个随机数，用服务器公钥加密发送过去即可。

知乎使用的是 ECDHE 来协商密钥，向服务器发送了 EC Diffie-Hellman Client Params ，如下图所示。这时候服务器、浏览器都拥有了 Server Params 和 Client Params ，双方利用同样的信息计算出 pre_master 。

如何计算会话密钥？

目前为止，双方共同拥有的信息是 client_random、server_random、pre_master 。那么，如何计算出会话密钥呢？

首先，根据客户端随机数，服务器随机数，预备主密钥通过特定算法计算出 48 位的 主密钥（master_secret）。这个特定算法称为 密钥衍生算法，TLS 使用的密钥衍生算法叫做 PRF ，可以列一个简单的表达式：

master_secret = PRF(pre_master_secret , “master_secret” , client_random + server_random)[0…47] ;

PRF 函数有三个参数，**secret，label 和 seed **。client_random 和 server_random 合成了最后一个参数 seed 。由于计算机无法生成真正的随机数，client_random 和 server_random 的作用就是尽量提高随机性，保证不可预测。

客户端和服务器在计算出主密钥之后，应该立即从内存中删除预备主密钥，防止泄露，它已经完成了使命。

主密钥就是会话密钥吗？ 或者说用主密钥作为会话密钥有什么问题？

首先会话双方使用同一个会话密钥本身就具有一定风险，双方应该各自使用不同的对称加密密钥。另外，会话过程中需要的远不止一个会话密钥，还有用于完整性校验 HMAC 算法的 MAC Key 。如果是特定的对称加密分组模式，还可能需要 初始化向量 IV 。这三个密钥，双方各自持有一份，就是 6 个密钥。

事实上根据密码套件的不同，会通过 PRF 函数生成个数不等的密钥块，用于通信过程中的消息加密和完整性校验。

key_block = PRF(master_secret, “key expansion”, server_random + client_random);

第一个参数是主密钥。最多可能需要生产 6 个密钥块。client_write_key 和 server_write_key 是必需的。

client_write_MAC_key

server_write_MAC_key

client_write_key

server_write_key

client_write_IV

server_writ_IV

Change Cipher Spec

现在已经完事具备，只欠 通知对方我已经准备好加密通信了 。

Change Cipher Spec 就是干这个事情的，一般由客户端首先发送。以此为界，后面的消息就都要加密通信了。同样，后面服务器也会给客户端发送该消息。

要注意一点，Change Cipher Spec 虽然是在握手过程中发送的，但并不是 TLS 握手协议中的一部分。

如何自学黑客&网络安全

黑客零基础入门学习路线&规划

初级黑客
1、网络安全理论知识（2天）
①了解行业相关背景，前景，确定发展方向。
②学习网络安全相关法律法规。
③网络安全运营的概念。
④等保简介、等保规定、流程和规范。（非常重要）

2、渗透测试基础（一周）
①渗透测试的流程、分类、标准
②信息收集技术：主动/被动信息搜集、Nmap工具、Google Hacking
③漏洞扫描、漏洞利用、原理，利用方法、工具（MSF）、绕过IDS和反病毒侦察
④主机攻防演练：MS17-010、MS08-067、MS10-046、MS12-20等

3、操作系统基础（一周）
①Windows系统常见功能和命令
②Kali Linux系统常见功能和命令
③操作系统安全（系统入侵排查/系统加固基础）

4、计算机网络基础（一周）
①计算机网络基础、协议和架构
②网络通信原理、OSI模型、数据转发流程
③常见协议解析（HTTP、TCP/IP、ARP等）
④网络攻击技术与网络安全防御技术
⑤Web漏洞原理与防御：主动/被动攻击、DDOS攻击、CVE漏洞复现

5、数据库基础操作（2天）
①数据库基础
②SQL语言基础
③数据库安全加固

6、Web渗透（1周）
①HTML、CSS和JavaScript简介
②OWASP Top10
③Web漏洞扫描工具
④Web渗透工具：Nmap、BurpSuite、SQLMap、其他（菜刀、漏扫等）
恭喜你，如果学到这里，你基本可以从事一份网络安全相关的工作，比如渗透测试、Web 渗透、安全服务、安全分析等岗位；如果等保模块学的好，还可以从事等保工程师。薪资区间6k-15k

到此为止，大概1个月的时间。你已经成为了一名“脚本小子”。那么你还想往下探索吗？

如果你想要入坑黑客&网络安全，笔者给大家准备了一份：282G全网最全的网络安全资料包评论区留言即可领取！

7、脚本编程（初级/中级/高级）
在网络安全领域。是否具备编程能力是“脚本小子”和真正黑客的本质区别。在实际的渗透测试过程中，面对复杂多变的网络环境，当常用工具不能满足实际需求的时候，往往需要对现有工具进行扩展，或者编写符合我们要求的工具、自动化脚本，这个时候就需要具备一定的编程能力。在分秒必争的CTF竞赛中，想要高效地使用自制的脚本工具来实现各种目的，更是需要拥有编程能力.

如果你零基础入门，笔者建议选择脚本语言Python/PHP/Go/Java中的一种，对常用库进行编程学习；搭建开发环境和选择IDE,PHP环境推荐Wamp和XAMPP， IDE强烈推荐Sublime；·Python编程学习，学习内容包含：语法、正则、文件、网络、多线程等常用库，推荐《Python核心编程》，不要看完；·用Python编写漏洞的exp,然后写一个简单的网络爬虫；·PHP基本语法学习并书写一个简单的博客系统；熟悉MVC架构，并试着学习一个PHP框架或者Python框架 (可选)；·了解Bootstrap的布局或者CSS。

8、超级黑客
这部分内容对零基础的同学来说还比较遥远，就不展开细说了，附上学习路线。