HTTPS加密原理：安全传输全解析-优快云博客

HTTP：全称 HyperText Transfer Protocol（超文本传输协议），是明文传输的应用层协议。数据在客户端和服务器之间直接以文本形式传输，任何人只要拦截到数据包，就能直接读取内容（比如账号密码、请求参数）。

HTTPS：全称 HyperText Transfer Protocol Secure（安全超文本传输协议），是 HTTP + TLS/SSL 协议的组合。数据在传输前会被加密，拦截者只能拿到乱码，只有服务器和客户端能解密，从根本上解决了明文传输的安全隐患。

总结：由于http是按照文本的方式进行明文传输，传输过程当中可能被截取获取篡改，https就是在http的基础上加了一个加密层，并且使用的端口不一样，http80端口，https443端口，但这并不意味着引入https不用http

什么是加密

加密：就是把要传输的明文数据经过一系列变换变成密文后在进行传输

解密：就是把密文经过一系列变换还原明文

密钥：在加解密的过程当中，往往需要一个或者多个中间数据，辅助进行这个过程，这样的数据就叫密钥

加密：图中就是把a经过变换变成b

解密：把b还原成a

密钥：key=200

一般来说很多人喜欢占用便宜，比如公共场合的免费WiFi，人家就是故意让你连接的，你一连所有的数据包都要经过这个路由进行转发

攻击者搭建一个 **“伪装的免费 WiFi”**（比如商场里的 “不知名免费网络”），并在自己的设备上部署 “抓包 / 流量转发工具”（相当于图里的 “中间设备”）。

用户手机 / 电脑连接了这个免费 WiFi，并用它访问目标地址（比如 XX 服务器）、下载 APP（图里的 “y APP”）。

所有的报文都要经过攻击者，那它一旦窃取，那你的信息啥的都会沦陷，甚至服务器返回来的数据都给你篡改

以前的万能WiFi钥匙就类似这种情况，一旦你用这个app，他就会问你一些权限，你必须同意才能用，它就窃取你连接过的WiFi密码，为什么你能够破解，是因为别人连过，然后密码被上传到后台，然后你连的时候，这个app就会去后台看看有没有密码，别人连过被窃取存到后台了，所以你能够破解，一旦别人没连过它就不知道这个wifi的密码，所以就会破解失败

常见的加密方式

对称加密和非对称加密

对称加密：

采用单钥密码系统的加密方式，同一个密钥可以同时用作信息的加密和解密，这种方式叫对称加密或者单密钥加密

特征：加密和解密的密钥是相同的

常见的对称加密算法：DES、3DES，AES、TDEA、Blowfish、RC2等

特点：算法公开，计算量小，加密速度快，加密效率高

就比如之前提到的，按位异或加密，密钥是同一个key

非对称加密：

需要用两个密钥来进行加密和解密，这两个密钥分别是公开密钥（简称公钥，public key）和私有密钥（简称私钥，private key）

特征：公钥和私钥，公钥和私钥是配对着的，用一个加就用另一个解

常见的非对称加密算法：RSA、DSA、ECDSA

特点：算法强度复杂、安全性依赖算法与密钥，但是由于其算法复杂而使得加密解密速度没有对称加密解密的速度快

缺点：运算速度非常慢，比对称加密慢的多

加密之后的安全性：加密只要时间足够长就一定可以解密，一般来说都是以算力成本角度分析，比如获取这一份数据，由于对方使用了非对称加密，此时你需要耗费比得到这份数据更大的时间和人力成本，所以就没必要获取

破解的时间/人力/算力成本远高于数据本身的价值

数据摘要&&数据指纹

数据指纹（数据摘要），其基本原理是利用单向散列函数（Hash函数）对信息进行运算，生成一串固定长度的数字摘要。数字指纹并不是一种加密机制，但可以用来判断数据有没有被窜改

摘要常见的算法：MD5、SHA1、SHA256、SHA512等，算法把无限的映射成有限（比如SHA256，一共256位，2^256个不同），因此可能会有碰撞（两个不同的信息，算出的摘要相同，但是概率非常低）

摘要特征：和加密算法的区别是，摘要严格意义不是加密，因为没有解密，只不过从摘要很难反推原信息，通常用来进行数据对比

比如百度网盘的妙传：一开始服务器没有这个电影，一开始传电影会形成摘要，摘要和电影一致存入后台，后面别人来上传电影，发现这个形成的摘要后台有，那就可以建立一个软连接，没必要再下载一部相同的电影，只需要建立一个软连接指向原来的即可，客户以为它上传了实际没有

比如数据库存储时，如果存储明文密码，别人盗取了就可以直接获取，但是如果我存储一个数据摘要呢？别人获取就会看到一堆乱七八糟的数据，它无法还原，因为没有解密

之前讲的http章节中的sessionid就是这样形成的

总结：

摘要经过加密之后形成的叫数字签名

数字摘要（哈希值）的核心作用是 **“验证信息的完整性、标识唯一性”**，是现代网络安全、数据存储的基础工具之一

重回https理解链

对于http，我们是明文传输，那在网络传输中，我们要解决数据被监听和数据被篡改的问题

因为对称加密和非对称加密都是有密钥的，那如何让对方安全的收到密钥呢？？？

1. 只是用对称加密肯定不行，你把密钥经过网络传给对方都泄漏了密钥，后面别人获取直接解

那密钥的传输肯定需要加密，那此时就需要密钥的密钥，这就是先有鸡还是先有蛋的问题了

2. 只使用非对称加密

一：

只有服务器有公钥和私钥，三次握手之后客户端申请公钥，服务端发送公钥，此时服务端有公钥和私钥，客户端有公钥，中间人有公钥，此时客户端发送数据经过加密，中间人无法破解（因为没有私钥），服务端能够解密，客户端到服务器是安全的，但是服务端发送数据的时候，由于客户端和中间人都有公钥，所以都能破解，不安全

二：

服务端生成s公钥和s私钥，客户端生成c公钥和c私钥

各自推送公钥给对方，然后各自发信息前用对方公钥加密，收到信息再拿自己私钥进行解密

慢而且存在安全问题（稍后讲解）

3.使用对称加密+非对称加密

服务端有公钥和私钥，客户端发起https请求，申请公钥，客户端生成对称密钥，使用公钥加密，然后发送给服务端，此时服务端使用私钥进行解密得到对称密钥，往后通信的时候使用对称密钥，由于使用了非对称，所以会比对称的快点，这里就是比上面那个方法还快一点

非对称加密传对称密钥 + 对称加密传数据

以上的所有方案都还存在安全问题

MITM 是 “中间人攻击（Man-in-the-Middle Attack）” 的缩写，是网络安全中最常见的攻击方式之一

无论是2还是3，中间人只需要再传递公钥的时候，截取下来，然后再伪造一个公钥发给对方，比如3，伪造之后客户端都不知道这个是伪造的公钥，后面客户端生成对称密钥，使用伪造的公钥进行传输，被中间人截取，后面中间人使用伪造私钥进行解密，解密之后就可以得到对称密钥，再用曾经保持的服务器的公钥加密将报文推送给服务器，从此中间人就得到了对称密钥，往后客户端和服务器的通信中间人截获之后都能使用对称密钥解密

总结：我们需要保证密钥的唯一性（只有客户端和服务器拥有），需要保证传递过程中公钥的合法性（防止被中间人篡改）

4.证书认证+非对称加密传对称密钥+对称加密传数据

补充知识：

CA认证

服务端在使用HTTPS前，需要向CA机构申领一份数字证书，数字证书里含有证书申请者信息、公钥信息等。服务器把证书传给浏览器，浏览器从证书中获取公钥就行了，证书就如身份证，证明服务端公钥的权威性

申请证书一般是公司的开发人员

那证书是如何说明公钥没有被篡改呢？？？

数字签名：

数据经过单向散列函数（hash函数）生成数据摘要，数据摘要经过非对称加密变成数字签名

注意此时和https无关，不要和https中的公钥私钥搞混了

首先：服务器向CA机构提交信息（包括公钥信息，私钥自己保存好）

CA机构使用自己内部的私钥进行加密，形成数字签名，再加上公钥等数据，生成数字证书

客户端验证时：先使用数据，数据经过散列函数得到一个散列值，数字签名中使用公钥进行解密，解密得到一个散列值，对比这两个散列值是否一致

数字签名中的公钥是客户端的操作系统 / 浏览器会预装 CA 根证书（包含 CA 机构的公钥，是客户端信任的 “根”）。

注意：CA的私钥是CA机构内部的，是不公开的，CA的公钥是公开的是在os或浏览器中预有

流程：

1.服务端生成公钥和私钥，使用公钥向CA机构去申请CA证书

2.CA机构去审核服务端交过来的信息

3.CA机构使用内部的私钥对散列值生成一个数字签名，然后整合信息形成数字证书

4.服务器得到数字证书之后，客户端发起https请求获取公钥时，服务器直接返回证书

5.客户端通过得到的证书，去验证公钥是否合法，计算公钥的散列值，然后数字签名使用公开的CA的公钥进行解密，看一下两个散列值是否相等，相等说明公钥合法，后面发送对称密钥的时候，使用公钥加密后再进行发送

6.服务端得到对称密钥，后面两边通过对称密钥进行通信，中间人没有得到过对称密钥

中间人无法更改公钥信息，一旦你更改

第一数据信息通过散列函数计算散列值1

第二使用公钥去解密数字签名得到散列值2

因为你篡改你就必须重新生成一个散列值然后使用私钥去加密，那你私钥和CA都不一样，客户端公钥解出来是乱码，那两个值都不一样

核心就是数字签名解密出来的保证了公钥的合法性

浏览器右上角

设置----->搜索证书------->证书管理

可以看到证书使用了SHA-374hash进行生成数据摘要的

然后使用ECDSA进行生成数字签名

为什么要先形成数据摘要，然后再进行非对称加密呢？？？

数据摘要能够缩短数据的大小，使得后面加密解密的时间大大减小

总结：

客户端（浏览器）发起 HTTPS 请求，告诉服务器 “我支持的 TLS 版本、加密算法”；
服务器返回「CA 签发的证书」（包含服务器公钥、CA 签名）、自己支持的加密算法；
客户端验证证书（用 CA 公钥解密签名、对比摘要）—— 这就是我们聊的 CA 认证流程；
客户端生成随机的对称密钥（AES 密钥），用服务器的公钥加密后发给服务器 —— 这就是我们聊的 “用非对称加密安全传对称密钥”；
服务器用自己的私钥解密，拿到对称密钥；
双方约定 “用这个对称密钥加密后续所有数据”，握手结束；
后续 HTTP 数据（比如你登录账号、浏览网页），都用对称密钥加密传输 —— 这就是我们聊的 “对称加密传数据，保证效率”。

注意：这里的是在tcp三次握手之后再次发起的通信握手

TLS本质就是规定了tcp三次握手之后的流程，定义了一套 “安全握手 + 加密传输” 的标准流程，保证了数据的安全性

证书里的 “ECDSA 签名 + SHA-384”，就是 TLS 协议里「身份验证 + 摘要验证」的具体算法 ——CA 用 ECDSA 私钥签名、客户端用 ECDSA 公钥验签，用 SHA-384 计算证书摘要，全都是 TLS 规定的流程。

你浏览网站时，浏览器地址栏显示的 “小锁”，就是 TLS 协议成功建立加密通道的标志；如果显示 “不安全”，就是没启用 TLS（用了 HTTP），或者 TLS 证书验证失败。

那为什么不淘汰HTTP呢

目前 HTTP 并没有被完全淘汰，主要是因为历史遗留、特定场景需求、成本等原因，但现在 HTTP 的使用场景已经越来越少了：

1. 历史遗留问题

早期互联网的网站都是基于 HTTP 开发的，部分老旧系统、小众网站还没完成 HTTPS 的迁移（尤其是一些个人站点、非商业服务）；
一些设备（比如老款物联网设备、嵌入式设备）的硬件 / 软件不支持 HTTPS（性能不足、缺乏加密组件），只能用 HTTP 通信。

2. 特定场景的 “无敏感数据” 需求

对于完全公开、无任何敏感信息的静态资源（比如纯静态的公开文档、图片），部分开发者认为 “加密的必要性低”，会选择用 HTTP（但现在主流也会强制跳转到 HTTPS）；
本地网络内的服务（比如局域网内的打印机、路由器管理页面），早期设计时可能默认用 HTTP（不过现在新设备也逐渐切换到 HTTPS 了）。

3. 成本与技术门槛

部署 HTTPS 需要申请 CA 证书（虽然免费证书很多，但部分企业 / 个人不熟悉流程）；
部分老旧服务器软件对 HTTPS 的支持不友好，升级 / 配置需要额外成本。

4. 实际趋势：HTTP 正在被淘汰

现在主流浏览器（Chrome、Edge）会对 HTTP 网站标记 “不安全”，搜索引擎也会降低 HTTP 网站的排名，HTTPS 已经成为互联网的默认标准——HTTP 的使用场景会越来越少，最终会被完全替代。

所以不是 “要保留 HTTP”，而是过渡阶段的历史遗留 + 少数场景的临时需求，长期来看 HTTP 会逐渐退出主流使用。

如何形成中间人？？？

ARP 欺骗：在局域网中，hacker 经过收到 ARP Request 广播包，能够偷听到其它节点的 (IP,MAC) 地址。例，黑客收到两个主机 A,B 的地址，告诉 B (受害者)，自己是 A，使得 B 在发送给 A 的数据包都被黑客截取
ICMP 攻击：由于 ICMP 协议中有重定向的报文类型，那么我们就可以伪造一个 ICMP 信息然后发送给局域网中的客户端，并伪装自己是一个更好的路由通路。从而导致目标所有的上网流量都会发送到我们指定的接口上，达到和 ARP 欺骗同样的效果
假 wifi&& 假网站等

这里就不详细讲解了，可以自行查略资料