草莓熊Lotso个人主页❄️个人专栏:《C知识分享》 《Linux 入门到实践零基础也能懂》✨生活是默默的坚持毅力是永久的享受 博主简介文章目录前言一. HTTPS 与密码学基础1.1 HTTPS 是什么1.2 为什么必须加密—— 明文传输的痛点1.3 两种核心加密方式1.4 数据摘要数字指纹1.5 数字签名二. HTTPS 加密方案的演进2.1 方案一只使用对称加密2.2 方案二只使用非对称加密2.3 方案三双方都使用非对称加密2.4 方案四非对称加密 对称加密三. 中间人攻击MITM方案四的致命漏洞3.1 中间人攻击的完整流程3.2 问题的本质四. CA 证书与数字签名身份信任的基石4.1 数字签名的原理与验证4.2 什么是 CA 证书4.3 证书的申请与签发流程4.4 客户端如何验证证书4.5 为什么证书无法被篡改或掉包4.6 常见问题为什么签名要先做 Hash不直接加密原文五. HTTPS 完整工作流程最终方案非对称加密 对称加密 CA 证书认证5.1 完整通信流程5.2 三组密钥的分工结尾前言在日常上网的过程中我们早已习惯了浏览器地址栏前的小锁图标它代表着当前网站使用了 HTTPS 协议通信过程是安全的。但如果回到纯 HTTP 时代所有数据都是明文在网络链路中 “裸奔”—— 你点击一个下载链接数据经过运营商的路由器、交换机运营商可以轻松解析出内容甚至偷偷把你要下载的软件替换成另一个这就是臭名昭著的 “运营商劫持”。本文顺着 “发现问题→提出方案→暴露缺陷→优化升级” 的思路一步步拆解 HTTPS 的底层原理。从最基础的加密概念讲起历经四种加密方案的演进再到中间人攻击的漏洞分析最终落到 CA 证书与完整握手流程带你彻底搞懂 HTTPS 到底是如何保障数据安全的。一. HTTPS 与密码学基础1.1 HTTPS 是什么很多人知道 HTTPS 是 HTTP 的安全版本但它在网络分层中的位置很多人并不清楚。 HTTPS 本质上仍属于应用层协议它是在 HTTP 协议和传输层 TCP 之间增加了一层 TLS/SSL套接字安全层这一层专门负责加密、解密与身份认证工作。简单概括HTTPS HTTP TLS/SSL 加密层。HTTP 是明文传输而 HTTPS 会把传输的内容先加密成密文再发出接收方收到后解密还原成明文。全程即使数据被截获劫持者也无法读取真实内容更难以无痕篡改。1.2 为什么必须加密—— 明文传输的痛点最典型的例子就是运营商劫持。比如用户想下载 “天天动听” APP点击下载按钮后浏览器向服务器发送 HTTP 请求服务器返回包含下载链接的响应。这个响应会经过运营商的网络设备运营商解析出内容是天天动听的下载链接就可以偷偷把链接替换成 QQ 浏览器的下载地址用户最终下载到的根本不是原本想要的软件。不止运营商局域网黑客、公共 WiFi 提供者都可以作为中间人截获、篡改明文数据甚至窃取账号密码这就是中间人攻击MITM。HTTP 明文传输的特性让数据在网络中毫无隐私可言这也是 HTTPS 出现的根本原因。1.3 两种核心加密方式加密和解密的过程离不开 “密钥” 的参与。根据密钥使用方式的不同加密算法主要分为两大类对称加密和非对称加密。对称加密对称加密的核心特征是加密和解密使用同一个密钥因此也叫单密钥加密。 常见的对称加密算法有 DES、3DES、AES、Blowfish、RC2 等。它的优势是算法公开、计算量小、加解密速度快、加密效率高非常适合大量数据的传输加密。我们可以用最简单的按位异或运算来理解对称加密的原理 假设明文 a 1234密钥 key 8888加密时明文异或密钥得到密文解密时密文再次异或同一个密钥就能还原出明文。对应的 C 语言示例代码如下#includestdio.hintmain(void){intplain_text1234;// 原始明文intkey8888;// 对称密钥// 加密过程明文异或密钥生成密文intcipher_textplain_text^key;printf(加密后密文: %d\n,cipher_text);// 解密过程密文再次异或密钥还原明文intdecryptedcipher_text^key;printf(解密后明文: %d\n,decrypted);return0;}运行结果加密后密文: 9834 解密后明文: 1234当然按位异或只是最基础的演示HTTPS 实际使用的是更复杂的对称加密算法但核心逻辑一致同一个密钥同时负责加密与解密。非对称加密和对称加密不同非对称加密需要一对配对的密钥公钥public key和私钥private key。 公钥可以公开给任何人私钥必须由持有者严格保密。用公钥加密的数据只有对应的私钥能解密反过来用私钥加密的数据只有对应的公钥能解密。常见的非对称加密算法有 RSA、DSA、ECDSA 等。它的特点是安全性高但算法复杂度高加解密速度远慢于对称加密。打个生活化的比方B 要和 A 传递机密文件B 先给 A 一把锁公钥这把锁谁都可以拿到A 把文件放进盒子里用锁锁上只有 B 手里的钥匙私钥能打开盒子。公钥不怕泄露只有持有私钥的人才能解密数据。1.4 数据摘要数字指纹除了加密还有一个重要概念叫数据摘要也叫数字指纹。 它的原理是利用单向散列函数Hash 函数对任意长度的数据做运算生成一串固定长度的散列值。常见的摘要算法有 MD5、SHA1、SHA256、SHA512 等。摘要有几个关键特征不可逆只能从原文计算摘要几乎无法从摘要反推原文因此它严格来说不算加密。高离散性原文哪怕只修改一个字符生成的摘要都会天差地别。定长输出无论原文多长同一种算法生成的摘要长度固定。正因为这些特性摘要最核心的作用是验证数据是否被篡改。比如百度云的 “秒传” 功能本质就是客户端先计算文件摘要发给服务器服务器如果已有相同摘要的文件就无需重复上传直接关联一份给用户即可。我们日常数据库存储密码也不会存明文而是存储密码的摘要验证时对比摘要即可大幅降低数据库泄露后的风险。1.5 数字签名把数据摘要用私钥加密之后得到的结果就是数字签名。 数字签名可以同时解决两个问题一是数据有没有被篡改二是数据是不是预期的发送方发出的。这个概念是理解 CA 证书的核心基础我们后面讲证书机制时会详细展开。二. HTTPS 加密方案的演进了解了基础加密概念后我们一步步推导要让 HTTP 通信安全到底该如何设计加密方案2.1 方案一只使用对称加密最容易想到的思路就是客户端和服务器约定同一个对称密钥所有数据都用这个密钥加密传输。 这样一来即使数据被截获黑客不知道密钥也解不开密文看起来好像解决了明文泄露的问题。但这个方案有两个致命缺陷密钥无法安全传输第一次建立连接时密钥总得同步给对方。如果明文传输密钥黑客直接就能拿到后续加密形同虚设如果加密传输密钥那又需要一个 “加密密钥的密钥”陷入 “先有鸡还是先有蛋” 的死循环。多客户端管理成本极高服务器同时服务成千上万客户端每个客户端必须使用不同密钥否则一个密钥泄露所有用户都不安全服务器要维护大量客户端 - 密钥映射关系运维成本极高。结论仅靠对称加密行不通。2.2 方案二只使用非对称加密既然对称加密的密钥传输是痛点那用非对称加密呢 服务器把自己的公钥明文发给客户端客户端发数据前先用公钥加密服务器收到后用私钥解密。因为私钥只有服务器持有所以从客户端到服务器的链路看起来是安全的。但问题同样明显反向传输毫无安全可言服务器给客户端发数据如果用私钥加密客户端用公钥解密 —— 但公钥是公开的中间人也持有公钥也能解密服务器发出的数据服务器到客户端的链路完全暴露。传输效率极低非对称加密的计算复杂度远高于对称加密全程使用非对称加密通信延迟会非常高完全不适合网页这种大数据量的传输场景。结论只用非对称加密也不行。2.3 方案三双方都使用非对称加密单向不安全那双方都生成公私钥对、互相交换公钥呢 客户端持有公钥 C 和私钥 C’服务器持有公钥 S 和私钥 S’。客户端发数据用服务器公钥 S 加密只有服务器能解服务器发数据用客户端公钥 C 加密只有客户端能解。看起来双向都安全了但本质问题依旧存在仍然没有解决 “公钥身份认证” 的问题中间人依然可以在公钥传输阶段替换公钥实施攻击。效率问题更加严重双向都使用非对称加密通信速度只会更慢。2.4 方案四非对称加密 对称加密既然非对称加密安全但慢对称加密快但密钥传输难那把两者结合起来行不行 核心思路用非对称加密来协商对称密钥后续真正的业务数据传输全程使用对称加密。具体流程服务器预先持有非对称公钥 S 和私钥 S’客户端发起 HTTPS 请求获取服务器的公钥 S客户端在本地随机生成一个对称密钥 X用公钥 S 加密 X发送给服务器服务器用自己的私钥 S’ 解密得到对称密钥 X之后双方所有 HTTP 数据都使用这个对称密钥 X 进行加解密传输。这个方案完美解决了效率问题只有初始密钥协商阶段使用非对称加密后续大量数据传输都使用速度更快的对称加密。但是 —— 这个方案就真的绝对安全了吗如果中间人在最开始公钥传输的阶段就已经介入了呢三. 中间人攻击MITM方案四的致命漏洞方案四看起来很完善但它有一个最核心的前提假设客户端拿到的公钥确实是目标服务器的公钥。 如果有一个中间人在客户端和服务器之间偷偷替换了公钥整个加密体系就会彻底失效。3.1 中间人攻击的完整流程假设中间人拥有自己的公钥 M 和私钥 M’完整攻击步骤如下客户端向服务器发起请求服务器返回自己的公钥 S中间人劫持这个响应提取并保存公钥 S然后把报文中的公钥 S 替换成自己的公钥 M转发给客户端客户端拿到公钥 M误以为是服务器的公钥于是生成对称密钥 X用公钥 M 加密后发往服务器中间人再次劫持报文用自己的私钥 M’ 解密轻松拿到对称密钥 X再用之前保存的服务器公钥 S 加密 X转发给服务器服务器用私钥 S’ 解密也得到了对称密钥 X。到这一步客户端和服务器都以为密钥协商成功开始用 X 加密传输数据。但实际上中间人也持有完整的对称密钥 X所有通信内容中间人都能解密窃听甚至随意篡改而通信双方完全无法察觉。这就是经典的中间人攻击方案二、三、四都逃不开这个问题。3.2 问题的本质根源非常直白客户端没有任何手段验证自己收到的公钥到底是不是目标服务器发出的。 公钥本质只是一串数据任何人都可以生成。中间人把自己的公钥塞给客户端客户端根本分辨不出真伪。要解决这个问题就需要一个全网都信任的第三方机构来给服务器的公钥做 “身份担保”—— 这就是 CA 证书。四. CA 证书与数字签名身份信任的基石在讲证书机制之前我们先把 “数字签名” 的原理讲透它是证书能够防伪的核心。4.1 数字签名的原理与验证数字签名的生成和验证基于非对称加密和摘要算法完整流程如下签名生成发送方先对原始数据做 Hash 运算得到固定长度的数据摘要用发送方自己的私钥加密这个摘要得到的结果就是数字签名将原始数据 数字签名一同发给接收方。签名验证接收方对接收到的原始数据用相同的 Hash 算法计算摘要记为 hash1用发送方的公钥解密数字签名得到 hash2对比 hash1 和 hash2如果相等说明数据未被篡改且确实由持有对应私钥的发送方发出。为什么签名能防伪因为私钥只有签名者自己持有其他人既无法伪造签名也无法篡改数据后重新生成匹配的签名 —— 只要修改一个字节摘要就会完全对不上。4.2 什么是 CA 证书CACertificate Authority证书颁发机构是全网公认信任的第三方权威机构。 服务器要启用 HTTPS需要先向 CA 机构申领一份数字证书。这份证书里包含了服务器域名、申请者信息、服务器公钥、有效期、签发机构以及 CA 机构用自身私钥生成的数字签名。你可以把证书理解成服务器的 “身份证”身份证由公安局CA 机构签发上面有你的身份信息和照片服务器公钥、域名还有公安局的公章CA 的数字签名。因为大家都信任公安局的权威性所以就认可这张身份证的有效性。4.3 证书的申请与签发流程服务器先生成自己的公私钥对公钥 S 和私钥 S’将域名、申请者信息、公钥 S 等整理成 CSR证书请求文件整个过程不会包含私钥把 CSR 提交给 CA 机构CA 机构审核信息的真实性CA 机构对证书的明文信息做 Hash 摘要再用自己的私钥加密这个摘要生成数字签名将明文信息 数字签名组合成完整的数字证书颁发给申请的服务器。4.4 客户端如何验证证书我们的操作系统和浏览器中会内置所有权威 CA 机构的公钥。当客户端收到服务器发来的证书时会执行以下几步验证解签名验摘要找到签发该证书的 CA 机构用系统内置的 CA 公钥解密证书中的签名得到摘要 hash1再对证书明文内容做同样的 Hash 运算得到 hash2。如果两者相等说明证书内容没有被篡改。校验身份与时效检查证书中的域名与当前访问的网站域名是否一致检查证书有效期确认没有过期或尚未生效。校验信任链检查签发证书的 CA 机构是否属于系统信任列表证书是否已被吊销。只有所有验证全部通过浏览器才会认为证书合法服务器的公钥是可信的。4.5 为什么证书无法被篡改或掉包很多人会有疑问中间人就不能修改证书内容或者直接换成自己的证书吗我们分两种情况分析情况 1篡改证书明文内容中间人可以修改证书里的公钥或域名但他没有 CA 机构的私钥无法为修改后的内容重新生成正确的数字签名。客户端一验证摘要就会对不上立刻就能发现证书被篡改终止连接并提示安全风险。情况 2整体掉包成自己的证书中间人确实可以自己向 CA 申请一张合法证书但申请证书必须绑定独立域名。他把自己的证书发给客户端客户端一对比证书中的域名和当前访问的网站域名不匹配立刻就能识别异常。且正规 CA 机构审核严格中间人不可能申请到他人域名的证书。因此只要 CA 机构的私钥不泄露证书就是安全的中间人既改不了内容也无法整体掉包。4.6 常见问题为什么签名要先做 Hash不直接加密原文核心原因是提升效率缩小签名长度。 非对称加密本身速度较慢如果直接加密整篇证书原文计算量会非常大。而 Hash 摘要长度很短比如 SHA256 仅 32 字节加密摘要的速度快得多同时又能完整保证原文不可篡改兼顾了安全与性能。五. HTTPS 完整工作流程最终方案非对称加密 对称加密 CA 证书认证有了 CA 证书机制之后我们就得到了 HTTPS 的最终方案非对称加密 对称加密 CA 证书认证。5.1 完整通信流程我们把整个 HTTPS 握手 通信的过程从头到尾梳理一遍客户端发起 HTTPS 请求连接服务器的 443 端口服务器将自己的数字证书返回给客户端客户端验证证书合法性校验签名、域名、有效期、信任链若证书不合法浏览器弹出安全警告终止连接若证书合法提取出证书中的服务器公钥客户端随机生成一个对称密钥 R用服务器公钥加密 R发送给服务器服务器用自己的私钥解密得到对称密钥 R至此双方都持有相同的对称密钥 R后续所有 HTTP 请求和响应数据都使用该对称密钥进行加解密传输。5.2 三组密钥的分工整个 HTTPS 流程中一共涉及三组不同的密钥各司其职第一组CA 的公私钥用于验证证书合法性。CA 持有私钥用于给证书签名客户端内置 CA 公钥用于验证签名。这一组的核心作用是保证服务器公钥是可信的。第二组服务器的公私钥用于协商对称密钥。服务器持有私钥客户端用证书里的公钥加密对称密钥后传输。这一组的作用是安全地将对称密钥从客户端传递到服务器。第三组协商生成的对称密钥用于后续所有业务数据的加解密。这一组是真正负责 HTTP 数据加密的核心前两组密钥机制都是为了安全交付这组密钥服务的。简单总结HTTPS 的一切机制都围绕 “安全地让双方拿到同一个对称密钥” 展开这是整个协议的核心逻辑。总结与核心考点梳理HTTP 与 HTTPS 的核心区别HTTP 明文传输HTTPS 加密传输HTTP 默认使用 80 端口HTTPS 默认使用 443 端口HTTPS 需要申请 CA 证书HTTP 不需要HTTPS 多了 TLS/SSL 加密层会消耗更多服务器资源握手阶段耗时更长。对称加密与非对称加密的区别对称加密使用单个密钥非对称加密使用公私钥对对称加密速度快适合大数据量传输非对称加密速度慢适合小数据、密钥协商场景对称加密无法解决密钥安全传输问题非对称加密可以解决身份认证问题。HTTPS 为什么要混合使用对称与非对称加密兼顾安全性与效率用非对称加密安全协商出对称密钥用对称加密高效传输业务数据。中间人攻击的原理是什么HTTPS 如何防范原理中间人在握手阶段替换公钥获取对称密钥后即可监听、篡改全程通信。 防范引入 CA 数字证书客户端通过验证证书合法性确保拿到的公钥确实属于目标服务器。数字证书的验证流程是什么用 CA 公钥解密签名得到摘要再计算证书明文的摘要两者一致则证书未被篡改再校验域名匹配性、有效期、证书信任链。HTTPS 流程中共几组密钥分别有什么作用共三组CA 公私钥验证证书合法性、服务器公私钥协商对称密钥、对称密钥加密业务数据。结尾 我是草莓熊 Lotso若这篇技术干货帮你打通了学习中的卡点 【关注】跟我一起深耕技术领域从基础到进阶见证每一次成长 ❤️ 【点赞】让优质内容被更多人看见让知识传递更有力量 ⭐ 【收藏】把核心知识点、实战技巧存好需要时直接查、随时用 【评论】分享你的经验或疑问比如曾踩过的技术坑一起交流避坑 ️ 【投票】用你的选择助力社区内容方向告诉大家哪个技术点最该重点拆解 技术之路难免有困惑但同行的人会让前进更有方向愿我们都能在自己专注的领域里一步步靠近心中的技术目标结语从明文 HTTP 到加密 HTTPS本质是互联网发展到一定阶段后对数据安全和身份可信的必然要求。它没有使用什么颠覆性的 “黑科技”而是把对称加密、非对称加密、摘要算法、数字签名、第三方信任机构这些技术巧妙组合逐层解决了 “数据泄露”、“数据篡改”、“身份伪造” 三大核心问题。理解 HTTPS不止是记住一个流程更要理解每一层设计背后的权衡与考量。安全和效率永远是架构设计的两大主题HTTPS 正是在两者之间找到极佳平衡的经典范例。✨把这些内容吃透超牛的放松下吧✨ʕ˘ᴥ˘ʔづきらど