网络：相比于HTTP，HTTPS协议到底安全在哪？

网络：相比于HTTP，HTTPS协议到底安全在哪？

我们知道HTTPS也是一种应用层协议，它在HTTP的基础上有一层加密，因为HTTP的数据传输都是以明文方式传输的，所以加密主要是为了防止数据在传输的时候被篡改

今天我们要探讨的就是什么是加密、为什么要加密（显而易见）、如何加密

OK第一个什么是加密？

加密就是把你要发送的明文信息进行一系列变换生成密文，解密就是把密文经过一系列变换生成明文，在加密或者解密的过程中需要一些中间数据进行辅助，这个东西就叫做密钥

为什么要加密

我们的所有流量都是要经过运营商的网络设备（路由器，交换机），那么运营商的网络设备就可以很轻松的获取我们没加密的明文数据，之后再将数据篡改，将篡改后的数据再发送给我们，这样我们得到的就是被运营商篡改后的数据了

当我们想下载一个软件，点击下载链接，恰好这条下载请求被运营商劫持并篡改返回了一个另外软件的下载地址，我们就不能下载我们想下载的软件了

并且在这个过程中，我们并不知道是谁劫持了信息，可能是运营商，也可能黑客通过某个路由器节点，或者代理服务器发起劫持，这就是中间人攻击，这些黑客可以通过售卖个人私有数据等赚取不法钱财，在互联网中使用明文传输是一件很危险的事，所以我们需要对数据加密

如何加密

常见加密方式

对称加密

采用单钥密码系统加密，同一个密钥可以同时用作信息的加密和解密，这种方法叫做对称加密，也叫但密钥加密。特点是：算法公开、计算量小、加密速度快、加密效率高

一个简单的对称加密算法就可以用按位异或来实现

明文：1030 密钥：8888

则密文：1030 ^ 8888 = 9918

之后对密文再异或上 8888 就可以得到明文

非对称加密

需要两个密钥来进行加密和解密，这两个密钥是公开密钥（public key，简称公钥）和私有密钥（private key，简称私钥）特点是：算法强度复杂、安全性依赖于算法与密钥，但是由于其算法复杂，而使得加密解密的速度没有对称加密的速度快（这是它最大的缺点）

非对称加密要用到的两个密钥：公钥和私钥是配对的

可以通过公钥对明文加密变成密文，通过私钥对密文解密变成明文；同时也可以反着来用

A 要给 B 一个重要的文件，它们使用这样的方式， B 先给了 A 一个锁（ B 有这个锁的钥匙）， A 把文件放一个盒子里面用锁锁住，之后放在 B 的办公桌上。等 B 回来了再拿手上的钥匙打开盒子拿到文件

这就是一个类似于非对称加密的例子，锁就是公钥，钥匙就是私钥

数据摘要&&数据指纹

以上两种称呼都是一个东西，以下都称呼为数据指纹

数字指纹的原理就是将数据通过hash算法生成一段固定长度的数字摘要。它本身并不是一种加密手段，但是可以用来判断数据有没有被篡改。特征是：因为不解密所以不算严格意义上的加密算法，只是进行数据对比

HTTPS的加密原理探究

方案一：使用对称加密

理想情况下，服务器和客户端双方都持有一个相同密钥，彼此间以密文传输数据，双方都可以将密文通过密钥转换成明文。但是如何让双方持有一个相同的密钥呢？是要事先商量好的吧，那么两台主机就要提前把密钥发给对方咯，那如果中间人拿到了密钥怎么办？那又该怎么保证密钥的安全呢？再套一层密钥？那就成了鸡生蛋，蛋生鸡的问题了。所以使用对称加密不是一个很好的方法

方案二：使用非对称加密

如果服务器将公钥以明文的方式发给客户端，客户端收到后，用公钥加密数据后发给服务器，服务器就可以用自己手里的私钥解开得到明文。就算中间人拿到了公钥，那也解不开客户端用也公钥加密的密文。所以这样从客户端到服务器之间的通信算是安全的（实际也不安全）

我们暂且先不讨论实际也不安全的问题

那么服务器到客户端的通信怎么解决呢？也用非对称加密一遍就可以啦

方案三：双方都使用非对称加密

服务器手上有公钥 S’ 和私钥 S ；客户端手上有公钥 C’ 和 私钥 C

1. 开始先互相以明文方式交换公钥
2. 服务端给客户端发信息，先用客户端给的公钥 C’ 加密之后发送，客户端收到后用自己手里的私钥 C 解密
3. 客户端给服务端发信息，先用服务端给的公钥 S’ 加密之后发送，服务端收到后用自己手里的私钥 S 解密

两个问题：1、效率太低 2、依旧有安全问题

方案四：使用非对称加密 + 对称加密

前面的效率问题主要是因为双方相对方发送数据都要经过非对称加密解密的过程（前面提到这是它的缺点）

这次我们用下面的方法：

1. 服务器手里有公钥 S’ 和私钥 S ；客户端手上有一个对称加密的密钥 C
2. 服务器将公钥 S’ 发送给客户端，客户端用公钥 S’ 将自己准备好的密钥 C 加密后发给服务器
3. 服务器收到后用私钥 S 解密信息，得到对称加密的密钥 C
4. 之后双方就使用这个密钥 C 进行通信

相当于用非对称加密的方式保证了对称加密密钥传输的安全性

因为如果有中间人他只能拿到公钥 S‘ ，所以解不开客户端向服务器发送的密文，也就无法得到密钥 C 那么这种方式看起来似乎是天衣无缝了，实际上还是不安全的。

中间人攻击

以上情况都有一个假设：中间人不会篡改信息。那如果中间人将服务器的公钥换成了自己的公钥呢？

有以下情况：

• 服务器手里有公钥 S’ 和私钥 S ；中间人手上有公钥 M’ 和私钥 M；客户端有对称密钥 C
• 服务器将公钥 S’ 发给服务器，但是这时中间人收到了公钥 S’ 并将 S’ 改成了自己的公钥 M’ 发给了客户端
• 客户端收到了公钥 M’ （客户端不知道公钥有没有被替换）之后客户端将自己的密钥 C 通过公钥 M’ 加密并发给了服务器
• 这时中间人又从中作梗了：中间人将密文通过自己的私钥 M 解密得到了密钥 C ，之后再将密钥 C 重新用公钥 S’ 加密后发给服务器
• OK，服务器最终虽然也收到了密钥 C ，但是中间人也有密钥 C 呀，它们之间的通信完全暴露在了中间人眼睛下（中间人此时可以劫持，监听甚至修改数据）

中间人在最开始就攻击，并且篡改数据，所以方案 二 三 四 都是有这个问题的，本质在于客户端无法确定自己收到的信息是否来自目标服务器！！！

证书

这个时候就需要有一个"第三方见证人"了：CA认证（Man-in-the-MiddleAttack）

所有服务器在使用HTTPS协议之前都要向CA机构申请一份数字证书，证书里面包含公钥，服务器将证书发给浏览器，浏览器直接从证书里面获取公钥即可，证书就像身份证，证明服务器公钥的权威

证书里面包含了以下信息：

• 证书发布机构
• 证书有效期
• 公钥
• 证书所有者
• 签名
• …

证书在申请的时候需要在特定平台审查，并且会同时生成一个密钥对 即公钥和私钥，这个密钥对就是来进行明文加密以及数字签名的。其中公钥会随着CSR文件一起发送给CA进行权威认证，私钥服务端自己保留，用来进行后续通信（得到对称密钥）

数据签名

为了防止有人篡改CA证书，CA机构还需要对证书进行签名，也就是将CA证书的明文数据进行数据摘要（hash）然后用CA机构拥有的私钥进行加密得到数字签名（数字签名是可以被公钥解密的），在将数字签名和证书明文一起颁发给服务端

方案五：非对称加密 + 对称加密 + 证书认证

1. 如上图，服务端向机构申请证书，将自己的公钥 S’ 和私钥 S 给给CA机构，CA机构审查之后将域名，公钥 S’ ，签发机构等信息先用hash形成散列之后再用CA机构自己的私钥加密形成签名，之后附带上明文信息签发给服务端
2. 服务端收到证书后，与客户端通信，先将证书给客户端审查（明文），客户端收到证书后会先判定证书有效期，证书发布机构是否信任，然后验证证书是否被篡改：从系统中拿到该证书发布机构的公钥，对签名解密得到hash散列，之后将明文用hash散列后对比，如果两个散列相等，证明证书没有被篡改
3. 这时客户端就拿到了服务端的公钥 S’ （是包含在证书里面的！）之后客户端用这个密钥和服务端协商对称密钥（对称加密效率高一点）
4. 协商好对称密钥后，双方后续就用这个对称密钥进行加密通信

查看浏览器的受信任证书颁发机构

chrome浏览器：设置 -> 隐私与安全 -> 管理证书

中间人可能篡改证书吗？

如果中间人直接篡改证书明文（把服务器的公钥换成自己的），由于他没有CA机构的私钥，所以无法hash之后用私钥加密形成签名，就算强行篡改，客户端收到证书后会发现签名和解密后的值不一致，客户端是知道证书被篡改过的，“有内鬼，终止交易”

• 如果中间人直接掉包整个证书？

中间人没有CA私钥，无法制作证书（用其他私钥制作的证书客户端也解不开，因为客户端只认受信任的机构也只存储了受信任机构的公钥）

所以中间人只能向CA申请真证书，然后用自己申请的真证书进行调包，但是证书中包含了域名，申请者等服务端信息，整体调包后，客户端发现这不是我想要进行通信的域名也能够识别出来

中间人没有CA私钥，对任何证书都无法合法修改，包括自己申请的证书

为什么要对证书的明文形成hash后还要加密形成签名？

常见摘要算法：MD5，SHA

**特性：**定长，分散（源字符改变一点得到的hash会有很大变化），不可逆（将hash还原成源字符串几乎不可能）

所以判断两个字符串的hash相等就认为字符串相等

如果不加密用明文传输，中间人可以将源字符串篡改后，用同样的摘要算法再次生成一个摘要覆盖即可达到欺骗的作用，所以关键还是在受信任的机构手中的那一把私钥上

另外要先形成hash摘要而不直接数据加密的原因是因为可以缩小签名加密后密文的长度，加快验证签名的运算速度

如何成为中间人？

• ARP欺骗

在局域网中，hacker经过收到ARP Request广播包，能够偷听到其它节点的 (IP, MAC)地址。例， 黑客收到两个主机A, B的地址，告诉B (受害者) ，⾃⼰是A，使得B在发送给A 的数据包都被黑客截取

• ICMP攻击

由于ICMP协议中有重定向的报文类型，那么我们就可以伪造⼀个ICMP信息然后发送给局域网中的客户端，并伪装自己是⼀个更好的路由通路。从而导致目标所有的上网流量都会发送到我们指定的接口上，达到和ARP欺骗同样的效果

• 假WiFi 假网站

总结

HTTPS工作中涉及到的密钥有三组：

1. 非对称加密：用于校验证书是否被篡改，服务器持有私钥（私钥在形成CSR文件与申请证书时获得），客户端持有公钥（操作系统包含了可信任的 CA 认证机构有哪些，同时持有对应的公钥）服务器在客户端请求时，返回携带签名的证书，客户端通过这个公钥进行证书验证, 保证证书的合法性，进⼀步保证证书中携带的服务端公钥权威性
2. 非对称加密：用于协商生成对称加密的密钥，客户端用收到的CA证书中的公钥（是可被信任的）给随机生成的对称加密的密钥加密，传输给服务器，服务器通过私钥解密获取到对称加密密钥
3. 对称加密：客户端和服务器后续传输的数据都通过这个对称密钥加密解密（⼀切的关键都是围绕这个对称加密的密钥，其他的机制都是辅助这个密钥工作的。第二组非对称加密的密钥是为了让客户端把这个对称密钥传给服务器；第⼀组非对称加密的密钥是为了让客户端拿到第二组非对称加密的公钥）

附录：（AI生成）

HTTPS（Hypertext Transfer Protocol Secure）是在 HTTP 基础上通过 SSL/TLS 协议进行加密的安全传输协议，它显著提升了网络通信的安全性，但并非绝对安全。其安全性依赖于加密算法、证书管理、协议实现等多个环节，任何一个环节出现漏洞或配置不当，都可能导致安全风险。

一、HTTPS 的核心安全保障

HTTPS 通过以下机制提供安全防护，这也是它被广泛采用的原因：

1. 传输加密：通过 SSL/TLS 协议对传输的数据进行加密（对称加密），防止数据在传输过程中被窃听（如公共 WiFi 中的监听）。
2. 身份认证：通过数字证书验证服务器身份，确保用户访问的是真实的目标服务器（而非钓鱼网站）。
3. 数据完整性：通过哈希算法校验数据，防止传输过程中被篡改（如插入恶意代码）。

二、HTTPS 的安全局限性（为何不是绝对安全）

尽管 HTTPS 大幅提升了安全性，但以下场景可能导致其防护失效：

1. 证书相关问题

• 伪造或恶意证书：如果攻击者获取了可信证书机构（CA）的私钥，或通过钓鱼诱导用户信任自签名证书（如在企业内网中强制安装恶意根证书），可能伪造 HTTPS 网站，实施中间人攻击。
• 证书配置错误：例如证书过期、域名不匹配（如证书为example.com，但实际访问test.example.com）、未正确配置证书链等，可能导致浏览器提示风险，甚至被攻击者利用。
• 弱 CA 信任链：部分国家或地区的 CA 管理不严格，可能为恶意网站颁发证书，破坏 HTTPS 的身份认证机制。

2. 加密算法与协议漏洞

• 过时的加密算法：如果服务器使用已被破解的加密算法（如 RC4）、弱哈希算法（如 SHA1）或短密钥（如 RSA 1024 位以下），攻击者可能通过计算破解加密数据。
• 协议漏洞：历史上 SSL/TLS 协议曾出现多个高危漏洞，如 Heartbleed（2014 年，利用 TLS 心跳机制泄露内存数据）、POODLE（2014 年，针对 SSLv3 的降级攻击）、Logjam（2015 年，针对 Diffie-Hellman 密钥交换的攻击）等。尽管这些漏洞已通过协议更新修复，但未及时升级的服务器仍可能受影响。

3. 传输之外的安全风险

• 服务器端漏洞：HTTPS 仅保护传输过程，若服务器本身被入侵（如数据库泄露、服务器被植入后门），即使传输加密，存储在服务器中的数据（如用户密码、个人信息）仍可能被窃取。
• 客户端漏洞：若用户设备被植入恶意软件（如键盘记录器、木马），攻击者可直接在数据加密前（客户端）或解密后（服务器端）获取信息，绕过 HTTPS 的加密防护。
• 钓鱼与社会工程学：攻击者可能搭建域名相似的 HTTPS 网站（如faceb00k.com模仿facebook.com），利用用户的疏忽骗取信息。此时 HTTPS 的加密和认证机制虽 “正常工作”，但目标本身是恶意的。

4. 中间人攻击（MITM）的特殊场景

在某些可控网络环境中（如企业内网、公共 WiFi 被劫持），攻击者可通过以下方式实施中间人攻击：

• 强制用户设备信任其伪造的根证书，从而解密并篡改 HTTPS 流量（如部分企业的 “上网行为管理” 设备会这样操作）。
• 利用协议降级攻击（如诱使客户端使用不安全的 SSLv3 协议），绕过强加密机制。

三、如何增强 HTTPS 的安全性？

虽然 HTTPS 不是绝对安全，但通过以下措施可大幅降低风险：

• 使用强加密算法（如 AES-256、ECDHE 密钥交换）和现代 TLS 版本（TLS 1.2 及以上，禁用 SSLv3、TLS 1.0/1.1）。
• 选择可信的证书机构（CA），定期检查证书有效性，启用证书透明度（CT）机制（防止 CA 滥用签发权限）。
• 服务器端及时更新系统和软件，修复协议漏洞；客户端保持操作系统和浏览器更新。
• 结合其他安全措施，如网站启用 HSTS（防止降级到 HTTP）、使用 HTTP Public Key Pinning（HPKP，限制可信证书）等。

总结

HTTPS 是目前网络传输中最可靠的安全协议之一，但其安全性并非 “绝对”，而是依赖于加密算法、证书管理、协议实现等多个环节的有效性。只要存在人为配置失误、算法漏洞或社会工程学攻击的可能，HTTPS 的防护就可能被突破。因此，在使用 HTTPS 的同时，还需结合整体安全策略（如服务器加固、用户安全教育），才能最大限度降低风险。