【HTTPS】运营商劫持、中间人攻击 与 加密

一. HTTPS 是什么

HTTPS 也是一个应用层协议. 是在 HTTP 协议的基础上引入了一个加密层.
HTTP 协议内容都是按照文本的方式明文传输的. 这就导致在传输过程中出现一些被篡改的情况.

二. 臭名昭著的 “运营商劫持”

比如下载一个 天天动听,

• 未被劫持的效果, 点击下载按钮, 就会弹出天天动听的下载链接.

• 已被劫持的效果, 点击下载按钮, 就会弹出 QQ 浏览器的下载链接.

由于我们通过网络传输的任何的数据包都会经过运营商的网络设备(路由器, 交换机等), 那么运营商的网络设备就可以解析出你传输的数据内容, 并进行篡改.
不止运营商可以劫持, 其他的 黑客 也可以用类似的手段进行劫持, 来窃取用户隐私信息, 或者篡改内容.

所以在互联网上, 明文传输是比较危险的事情!!!

HTTPS 就是在 HTTP 的基础上进行了加密, 进一步的来保证用户的信息安全~

三. 加密

1. “加密” 是什么

• 加密就是把 明文 (要传输的信息)进行一系列变换, 生成 密文 .
• 解密就是把 密文 再进行一系列变换, 还原成 明文 .

在这个加密和解密的过程中, 往往需要一个或者多个中间的数据, 辅助进行这个过程, 这样的数据称为 密钥 .

2. HTTPS 的工作过程

既然要保证数据安全, 就需要进行 “加密”.
网络传输中不再直接传输明文了, 而是加密之后的 “密文”.
加密的方式有很多, 但是整体可以分成两大类: 对称加密 和 非对称加密

3. 对称加密

对称加密其实就是通过同一个 “密钥” , 把明文加密成密文, 并且也能把密文解密成明文.

• a(明文) + key -> b (密文)
• b (密文) + key -> a(明文)

一个简单的对称加密, 按位异或

• 明文 a = 1234, 密钥 key = 8888
• 加密: a ^ key -> 密文 b 为 9834.
• 解密: 密文b 9834 ^ key, -> 明文 1234.

(a^a = 0, a^0 = a)
当然, 按位异或只是最简单的对称加密. HTTPS 中并不是使用按位异或.

引入对称加密之后, 即使数据被截获, 由于黑客不知道密钥是啥, 因此就无法进行解密, 也就不知道请求的真实内容是啥了.

但服务器同一时刻其实是给很多客户端提供服务的. 这么多客户端, 每个人用的密钥都必须是不同的(如果是相同那密钥就太容易扩散了, 黑客就也能拿到了). 因此服务器就需要维护每个客户端和每个密钥之间的关联关系, 这也是个很麻烦的事情~

比较理想的做法, 就是能在客户端和服务器建立连接的时候, 双方协商确定这次的密钥是啥~

但是如果直接把密钥明文传输, 那么黑客也就能获得密钥了~~ 此时后续的加密操作就形同虚设了.

因此密钥的传输也必须加密传输!
但是要想对密钥进行对称加密, 就仍然需要先协商确定一个 “密钥的密钥”. 这就成了 “先有鸡还是先有蛋” 的问题了. 此时密钥的传输再用对称加密就行不通了.
就需要引入非对称加密.

4. 非对称加密

非对称加密要用到两个密钥, 一个叫做 “公钥”, 一个叫做 “私钥”. 公钥和私钥是配对的.

• 公钥: 人人都能获取.
• 私钥: 只有自己知道.

所以说虽然黑客能够拿到公钥, 但是没有私钥, 不能进行解密.

可以公钥加密, 私钥解密, 也可以反着用私钥加密, 公钥解密.

能否根据公钥计算出私钥?
理论可以, 但是计算量非常大, 不值当.

• 客户端在本地生成对称密钥, 通过公钥加密, 发送给服务器.
• 由于中间的网络设备没有私钥, 即使截获了数据, 也无法还原出内部的原文, 也就无法获取到对称密钥
• 服务器通过私钥解密, 还原出客户端发送的对称密钥. 并且使用这个对称密钥加密给客户端返回的响应数据.
• 后续客户端和服务器的通信都只用对称加密即可. 由于该密钥只有客户端和服务器两个主机知道, 其他主机/设备不知道密钥即使截获数据也没有意义.

非对称加密这么好使, 还要对称加密干啥 ?
非对称加密最大的缺点就是运算速度非常慢，比对称加密要慢很多.
所以对称加密的效率比非对称加密高很多, 因此只是在开始阶段协商密钥的时候使用非对称加密, 后续的传输仍然使用对称加密.

四. 中间人攻击

上述过程仍然存在巨大漏洞, 可能会涉及 “中间人攻击”.

• 客户端向服务器询问公钥是啥, 但是中间人(黑客) 拦截服务器返回给客户的公钥 555555, 替换为自己产生的公钥 666666.
• 客户端信以为真, 直接用 666666 加密自己的 对称密码 888888, 原本是想告诉服务器之后我们通信就用 888888.
• 但因为用 黑客的公钥 666666 加密的, 黑客当然有私钥, 进行解密, 知道了 客户端与服务器通信用的是 888888 加密.
• 非对称密钥只是为了加密对称密钥, 后续的通信全部使用对称密钥.
• 既然黑客知道它们通信的对称密钥了, 那么就能随便查看两者之间的通信信息, 加密形同虚设.

中间人攻击的关键就是: 拦截服务器返回给客户端的公钥, 替换为自己生成的公钥, 从而骗出通信双方的对称密钥.

客户端如何确定这个公钥不是黑客伪造的?
证书随之而来~~

五. 证书

在客户端和服务器刚一建立连接的时候, 服务器给客户端返回一个 证书. 这个证书包含了刚才的公钥, 也包含了网站的身份信息.

这个证书就好比人的身份证, 作为这个网站的身份标识. 搭建一个 HTTPS 网站要在CA机构先申请一个证书. (类似于去公安局办个身份证).

证书校验

这个 证书 可以理解成是一个结构化的字符串, 里面包含了以下信息:

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

当客户端获取到这个证书之后, 会对证书进行校验(防止证书是伪造的).

• 判定证书的有效期是否过期
• 判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构).
• 验证证书是否被篡改:
  从系统中拿到该证书发布机构的公钥, 对签名解密, 得到一个 hash 值(称为数据摘要), 设为 hash1. 然后计算整个证书的 hash 值, 设为 hash2. 对比 hash1 和 hash2 是否相等.
  如果相等, 则说明证书是没有被篡改过的, 那么就信任该公钥.

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

Chrome 浏览器, 点击右上角的 竖着的三个点, 选择 “设置” -> “隐私和安全” -> “安全” -> “管理设备证书”, 即可看到以下界面.

理解数据摘要 / 签名
类似于我们找财务报销需要领导的签名才能报销.不同的人, “签名” 的差别会很大. 使用签名就可以一定程度的区分某个特定的人.

类似的, 针对一段数据(比如一个字符串), 也可以通过一些特定的算法, 对这个字符串生成一个 “签名”.
并保证不同数据, 生成的 “签名” 差别很大. 这样使用这样的签名就可以一定程度的区分不同的数据.

常见的生成签名的算法有: MD5 和 SHA 系列
以 MD5 为例, 我们不需要研究具体的计算签名的过程, 只需要了解 MD5 的特点:

• 定长: 无论多长的字符串, 计算出来的 MD5 值都是固定长度 (16字节版本或者32字节版本)
• 分散: 源字符串只要改变一点点, 最终得到的 MD5 值都会差别很大.
• 不可逆: 通过源字符串生成 MD5 很容易, 但是通过 MD5 还原成原串理论上是不可能的.

正因为 MD5 有这样的特性, 我们可以认为如果两个字符串的 MD5 值相同, 则认为这两个字符串相同.

理解判定证书是否被篡改的过程: (这个过程就好比判定这个身份证是不是伪造的身份证)

• 假设我们的证书只是一个简单的字符串 hello, 对这个字符串计算 hash 值(比如md5), 结果为 BC4B2A76B9719D91
• 如果 hello 中有任意的字符被篡改了, 比如变成了 hella, 那么计算的 md5 值就会变化很大: BDBD6F9CF51F2FD8

客户端就只要计算 hello 的哈希值, 看看是不是 BC4B2A76B9719D91 即可.

证书篡改

但是还有个问题, 如果黑客把 hello 篡改了, 同时也把哈希值重新计算下, 客户端就分辨不出来了呀.

所以被传输的哈希值不能被篡改, 不要传输明文, 需要传输密文, 这样中间人虽然能解密, 但是它不能加密, 如果他用自己的加密算法进行加密的话, 到时候客户端使用的解密的密钥与中间人的密钥一定不是一对, 那么最终计算出来的哈希值也就一定不对.

• 这个哈希值在服务器端通过另外一个私钥加密(这个私钥是申请证书的时候, 证书发布机构给服务器的, 不是客户端和服务器传输对称密钥的私钥).
• 并且客户端的操作系统里已内置了对应证书的公钥, 使用公钥进行解密, 还原出原始的哈希值, 再进行校验.

六. 完整流程

总结:

HTTPS 工作过程中涉及到的密钥有三组.

• 第一组(非对称加密): 用于校验证书是否被篡改.
  服务器持有私钥(私钥在注册证书时获得), 客户端持有公钥(操作系统包含了可信任的 CA 认证机构有哪些, 同时持有对应的公钥). 服务器使用这个私钥对证书的签名进行加密. 客户端通过这个公钥解密获取到证书的签名, 从而校验证书内容是否是篡改过.
• 第二组(非对称加密): 用于协商生成对称加密的密钥.
  服务器生成这组 私钥-公钥 对, 然后通过证书把公钥传递给客户端. 客户端用这个公钥给生成的对称加密的密钥加密, 传输给服务器, 服务器通过私钥解密获取到对称加密密钥.
• 第三组(对称加密): 客户端和服务器后续传输的数据都通过这个对称密钥加密解密.

其实一切的关键都是围绕这个对称加密的密钥. 其他的机制都是辅助这个密钥工作的.

• 第二组非对称加密的密钥是为了让客户端把这个对称密钥传给服务器.
• 第一组非对称加密的密钥是为了让客户端拿到第二组非对称加密的公钥.

好啦！ 以上就是对 运营商劫持、中间人攻击 与 加密问题的讲解，希望能帮到你 ！
评论区欢迎指正 !