图解HTTPS非/对称加密，CA证书流程

1.HTTPS是什么

HTTPS也是一个应用层协议，是在HTTP协议的基础上引入了加密【S代表的是：security】是为了解决HTTP按照文本方式的明文传输被篡改的痛点。

臭名昭著的运营商劫持案件
下载一个 天天动听
未被劫持的效果, 点击下载按钮, 就会弹出天天动听的下载链接；如果被劫持就会是点击下载按钮，就会弹出QQ浏览器的下载链接。

为什么会劫持呢？
因为我们通过网络发送的个数据请求和反馈都会经过运营商的网络设备（路由器，交换机等）。通过抓包后就可以解析出你发出的请求数据并对其进行篡改。
用户发送下载天天动听的HTTP网络请求后，运营商解析出你要下载天天动听，然后给天天动听服务器发送网络请求，天天动听服务器响应给运营商设备，发送一个天天动听的下载链接。运营商就可以私底下对这个HTTP进行篡改，然后发送一个QQ浏览器的下载链接给用户。

为什么这样做？

不止运营商可以劫持，其他的黑客也可以用类似的手段进行劫持，来窃取用户隐私信息，或者篡改内容。

试想一下，如果黑客在用户登陆支付宝的时候获取到用户账户余额，甚
至获取到用户的支付密码…

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

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

2.“加密”是什么

加密：就是把明文[一系列要传输的信息]经过一系列转换变为密文
解密：经过一系列转换还原成加密前的明文
密钥(yue：)在加密解密过程中需要一个或多个中间数据进行辅助这个过程，这样的数据就是密钥

如果这样明文发送，那么肯定会被运营商服务器给截获到你的短信信息。
古人们通过藏头诗的形式来抒情，这样就会只有意中人知道了。

如今密码学已经发展为一门独立的学科：密码学。而密码学的奠基人, 也正是计算机科学的祖师爷之一，艾伦·麦席森·图灵

对比计算机另外一位祖师爷冯诺依曼，头发好像有点多而且还年轻。

3.HTTPS工作过程

既然明文传输不安全，网络上的数据传输都依靠密文了。常用的加密方式有两种：对称加密和非对称加密

1.引入对称加密

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

一个简单的对称加密，按位异或
加密过程：明文 a = 1234, 密钥 key = 8888则加密 a ^ key 得到的密文 b 为 9834。
解密过程：针对密文 9834 再次进行运算 b ^ key, 得到的就是原来的明文 1234. (对于字符串的对称加密也是同理, 每一个字符都可以表示成一个数字)


实际应用：按位异或只是最简单的对称加密. HTTPS 中并不是使用按位异或.

引入对称加密后，黑客虽然截获了数据，但是没有密钥，因此也就无法对其解密。
但事情并没有那么简单，一台服务器要和很多客户端进行交互，如果每个客户端公用同一个密钥，那么对于互联网而言，显得太扩散，很容易被破解；但反过来如果服务器给每一个客户端一个密钥，那么服务器需要给每个客户端进行密钥关联关系维护，这是个麻烦的事情

比较理想的方法就是客户端和服务器建立连接的时候双方约定好密钥用什么

但是如果密钥也明文传输，那么后续的加密就形同虚设。
因此密钥也需要进行加密

问题又来了：
如果需要对密钥进行加密，那么就需要密钥的密钥，那么因此就引入了是先有鸡还是先有蛋的问题。因此在使用对称加密就不合适了
就需要引入非对称加密

2.引入非对称加密

非对称密钥用到两个密钥，一个是公钥一个是私钥。
公钥和私钥是进行配对的，最大的缺点就是运行速度慢，比对称加密慢许多

• 通过公钥对明文加密形成密文
• 通过私钥对明文解密形成明文

也可以反着用

• 通过私钥对明文加密形成密文
• 通过公钥对明文解密形成明文

举个栗子：

A 要给 B 一些重要的文件，但是 B 可能不在。于是 A 和 B 提前做出约定：
B 说：我桌子上有个盒子, 然后我给你一把锁, 你把文件放盒子里用锁锁上, 然后我回头拿着钥匙来 开锁取文件.

在上述故事中：
盒子=公钥
B的钥匙=私钥
我们从此知道，公钥给谁都不怕信息泄漏；但是私钥只能B持有，持有私钥的人才能解密

• 客户端在本地生成对称密钥，通过密钥加密，发送给服务器
• 由于中间网络设备没有服务器的私钥，即使获取到数据也无法查看信息，因此也就无法得到对称密钥
• 服务器通过私钥解密，还原出客户端发送的对称密钥，并使用这个对称密钥加密后返回给客户端
• 后续客户端和服务器只需要使用对称加密进行沟通，由于该密钥只有服务器和客户端知道，其他设备截获后无法解密因此也就截获不到有意义的信息

难道引入对称加密就真的万无一失吗？
细心的小伙伴可能会想到：我得不到的，你门也别想得到；我得得到的你们更得不到
然后就开始了 骚操作，黑客截获信息后利用自己的共约对客户端发送来的数据进行额外一层的加密，收到服务器的反馈后就，就比对之前黑客自己公钥加密后和服务器加密后的数据，进行破解出服务器是如何加密的就拿到了公钥，进而可以继续为非作歹

因此就引入了更安全的证书机制

3.引入证书

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

这个证书好比每个居民的身份证，作为这个网站的身份表示。要搭建一个HTTPS的网站需要先去公证机构申请一个证书(类似于去公安局办理身份证)

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

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

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

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

查看浏览器中的受信任证书发布机构
chrome右上角三个点，点击后找到设置，输入“证书管理”即可查看

理解数据摘要/签名

举个生活中的例子：以后我们参加工作会涉及到一些“报销的场景”。拿着发票想报销，但需要经过领导的批准。可领导不会跟着你一起去找财务，因此需要领导的一个带有签字的批条。财务看到批条后就知道了“见字如见人”
因为不同的人，签名区别很大。使用签名就可以特定的区分某个特定的人。类似的针对字符串，我们可以针对一些特殊的算法，对这个字符串生成一个“签名”切当字符串改动的时候，签名的改动也很大。


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

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

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

有了上述背景知识后理解判定证书篡改的过程就很简单了
MD5在线计算网站

假设我们的证书只是一个简单的字符串 hello, 对这个字符串计算hash值 > (比如md5)，结果为5D41402ABC4B2A76B9719D911017C592


如果 hello 中有任意的字符被篡改了, 比如变成了 hella, 那么计算的 md5 > 值就会变化很大。结果为6E4A858CBDBD6F9CF51F2FD89D8C7558

然后我们可以把这个字符串 hello 和 哈希值5D41402ABC4B2A76B9719D911017C592 从服务器返回给客户端，此时 客户端如何验证 hello 是否是被篡改过?

那么就只要计算 hello 的哈希值, 看看是不是 5D41402ABC4B2A76B9719D911017C592 即可

问题又来了：黑客把 MD5 值修改了咋办呢

所以传输的 MD5 不能明文传输，需要加密传输
这个哈希值在服务器端通过另外一个私钥加密(这个私钥是申请证书的时候, 证书发布机构给服务器的，不是客户端和服务器传输对称密钥的私钥)。然后客户端通过操作系统里已经存的了的证书发布机构的公钥进行解密，还原出原始的哈希值，再进行校验。

4.完整流程

4.总结

HTTPS工作中的涉及到的密钥主要有3种

1. 对称加密：客户端和服务器都依靠这个对称密钥进行加密传输数据
2. 非对称加密
   1.用于校验证书是否被篡改。服务器持有CA证书的私钥（私钥在注册证书时候获得），客户端系统内置了可信任的CA机构有哪些并且持有对应的公钥。服务器对这个证书进行私钥加密传输给客户端，客户端通过自己的公钥进行解密从而获得证书签名，验证证书是否被篡改
   2.用于协商对称加密的密钥。服务器生成一对公钥和密钥，其中公钥通过证书发送到客户端，客户端通过这个公钥对数据进行加密然后发给服务器，服务器通过生成的密钥在进行解密

这一切都是围绕着这个对称加密的密钥，其它的机制都是围绕着这个机制辅助进行的
2.1是为了让客户端拿到2.2的对称加密密钥
2.2是为了让客户端把这个对称密钥加密后发送给服务器