HTTP 和 HTTPS

我们都知道 HTTP 是明文传输的，所以在传输过程中，很容易被中间人窃取、伪造和篡改

这种攻击方式，我们称为中间人攻击

因为 HTTP 明文传输没有安全性，制约了 HTTP 在一些应用场景的使用，比如网上购物，在线转账等，所以带有加密方案的 HTTPS 应运而生

从 HTTP 协议栈层面看，HTTPS 就是在 TCP 和 HTTP 之间插入了一个安全层

这个安全层主要做两件事情

• 对发起的 HTTP 请求的数据进行加密
• 对接收到的 HTTP 的内容进行解密

然后，我们利用这个安全层，一步一步实现一个由简单到复杂的 HTTPS 协议

第一版：使用对称加密

对称加密就是加密和解密都使用的是相同的密钥

密钥需要客户端和服务器端同时决定，步骤如下

• 浏览器发送它所支持的 加密套件列表 和一个随机数 client-random
  • 加密套件指的是浏览器支持的加密方法
• 服务器从 加密套件列表 中选取一个加密套件，然后生成一个随机数 service-random
• 然后将 加密套件 和 service-random 返回给浏览器
• 最后浏览器和服务器分别返回 确认消息

现在浏览器端和服务器端都有相同的 client-random 和 service-random

• 浏览器端和服务器端会用相同的方法将 client-random 和 service-random 混合起来生成一个密钥 master-secret
• 现在有了 master-secret 和 加密套件 双方就可以进行加密传输了

虽然这个方法实现了加密，但是其中传输 client-random 和 service-random 的过程中却是明文的，所以，黑客也能拿到 加密套件和双方的随机数

由于利用随机数合成密钥的算法是公开的，所以，黑客也可以合成密钥，数据依然可以破解

所以，我们需要改进下加密方法

第二版：使用非对称加密

非对称加密需要两把密钥，一个 公钥，一个 私钥
如果用 公钥 来加密，那么只能用 私钥 解密
如果用 私钥 来加密，那么只能用 公钥 解密

注意：公钥是每个人都能获取的，但是私钥只有服务器才能知道！不对任何人公开

非对称加密的流程如下：

• 浏览器发送 加密套件列表 给服务器
• 服务器选择一个 加密套件
• 服务器将 加密套件 和 公钥 发送给浏览器
• 最后浏览器和服务器返回确认消息

现在浏览器端有了服务器的公钥，浏览器在发送数据时，就可以用公钥来加密数据

由于 公钥加密的数据只能用私钥解密，所以即便黑客截取了数据和公钥，也无法来解密

但是这种方法仍然存在问题
在服务器端的私钥也可以加密，私钥加密的数据可以用公钥解密，所以，如果黑客截取了公钥，是可以解密服务器端加密的数据的

所以这种方法仍然不严谨

第三版 对称加密和非对称加密搭配使用

如何搭配呢，就是在传输数据阶段仍然使用对称加密，但是对称加密的密钥我们采用非对称加密来传输

步骤如下：

• 首先浏览器向服务器发送
  • 对称加密套件列表
  • 非对称加密套件列表
  • 随机数 client-random
• 服务器保存 client-random，选择 对称加密和非对称加密套件
• 生成随机数 service-random
• 服务器向浏览器发送
  • 两个加密套件
  • service-random
  • 公钥
• 浏览器保存公钥
• 利用 client-random 和 service-random 计算得出 pre-master
• 利用公钥对 pre-master 加密
• 向服务器发送加密后的数据
• 服务器拿到自己的私钥，解密出 pre-master 数据

现在，服务器端和浏览器端有了共同的 client-random、service-random、pre-master

然后服务器和浏览器使用这三种随机数生成 对称密钥

现在有了对称加密的密钥，双方就可以使用对称加密的方式传输数据了

todoooooooo

第四版：添加数字证书

通过混合加密的方式，我们实现了数据的加密传输，但是这种方式依然存在问题

比如我们想打开某个网站，但是黑客通过 DNS 劫持将这个网站的 IP 地址替换成黑客的 IP 地址，这样，我们访问的就是黑客的服务器，上述一系列加密算法，也是和黑客的服务器进行

所以，需要一种方法让服务器证明，“我就是我”

这个时候就需要 数字证书

如果想证明 A 的服务器就是 A 的，需要使用一个权威机构颁发的证书，这个权威机构就是 CA(Certificate Authority)，颁发的证书就称为 数字证书(Digital Certificate)

对于服务器来说，数字证书有两个作用

• 通过数字证书向浏览器证明服务器身份
• 从证书中获取公钥

相较于前一版的 HTTPS 协议，这里主要有两个改变

• 服务器没有直接返回公钥给浏览器，而是返回了数字证书
• 在浏览器端多了一个证书验证的操作，验证证书之后，才继续后续流程

通过引入数字证书，我们就实现了服务器的身份认证功能

如何申请数字证书呢？

流程如下

• 首先 A 需要准备一套私钥和公钥
• 然后 A 向 CA 机构提交公钥、公司、站点等信息并等待认证，这个过程可能是收费的
• CA 验证 A 所提供信息的真实性
• 审核通过后，CA 会向 A 签发认证的数字证书，包含以下内容
  • A 的公钥
  • 组织信息、CA 信息、有效时间、证书序列等
  • CA 生成的签名

其中关于数字签名的生成，需要以下几个步骤

• CA 使用 hash 函数 计算 A 提交的明文信息，并且得出 信息摘要
• CA 使用它的 私钥 对 信息摘要 进行加密
• 加密的密文就是 CA 颁发给 A 的 数字签名

证书有了，浏览器如何验证数字证书呢

• 浏览器会读取证书中的相关信息，采用 CA 签名时相同的 Hash 函数计算并得到 信息摘要A
• 利用对应的 CA 公钥解密签名数据，得到信息摘要B
• 对比 信息摘要A 和 信息摘要B 是否一致
• 如果一致，即证明了这个服务器是 A 的