我们经常被告知 https 是安全的而 http 是不安全的。那么 https 相比于 http 到底安全在哪里？https 是如何保证安全性的？
这篇文章将尝试回答这两个问题。

预备

首先对 http 协议做个简单的介绍，http 是应用层协议，它是在 TCP 协议之上构建的协议（当然也可以在其他运输层协议上构建）。
从协议栈上来看是这个样子的：

为了后续的说明简单一点，协议栈只画到 TCP 就结束了，其实在 TCP 之下还有几层协议但是在理解 http 和 https 的过程中并不重要。
需要知道的是在两台主机的 TCP 协议之间是会出现中间设备的，这些中间设备可能是不可信的甚至是恶意的。

通讯安全需要考虑的问题

为什么 http 是不安全的

接下来我们结合上面的三点来分析 http 安全性。
由于 http 是完全由明文传输的，所以在网络中间设备上所有人都可以拿到通讯双方的信息，所以机密性是不能保证的。
既然中间网络设备可以看到通讯双方的数据，那么必然也是可以修改这些数据的。例如某个路由器接受到了服务器端的一个数据包 A，但是它出于别的目的把数据包改成了 B，然后把 B 送给了客户端。这种情况经常在一些小的网络运营商运营的网络环境中会出现，被修改的 B 数据会包含一段不显示的 js 代码，这段 js 代码会模拟点击某宝的一个商品，这段代码会被客户端浏览器执行，这样就可以达到刷点击的目的。此处可以看到数据完整性是被破坏了的。
经过上一条的分析，可认证性就更不用谈了，因为在客户端的浏览器上根本没有办法确认数据是否是由服务器发送过来的。

实现网络通讯安全的技术手段

根据上面的描述我们知道了通讯安全核心要考虑的就是机密性、完整性和可认证性。
下面我们分别从这三个方面看都有哪些技术用来实现这三个特性。

机密性

实现机密性的一个最简单的方式就是对数据进行加密。加密又可以分为对称加密和非对称加密。
在对称加密的过程中通讯双方使用相同的密钥对数据进行加解密。那么通讯的机密性完全由密钥的安全性所决定，一旦密钥被第三方截获那么通讯就有可能被窃听或篡改。这种通讯方式存在一个问题，就是通讯的两端如何安全的协商出同一个密钥？比如通过邮件、U盘、手抄寄送的方式，这些方式本身就有可能是不安全的。所以我们还需要另外一种加密方式。
非对称加密，这种加密方式将密钥分成两个部分公钥和私钥。公钥是可以随意公开出去的没有任何机密性可言，而私钥是要保证机密的。
这种非对称加密的通讯方式是这样的：发送方用接受方的公钥对数据进行加密形成密文，然后将密文通过网络发送给接受方，接受方用自己的私钥对密文进行解密得到明文。这种方式就不会存在对称加密过程中如何保证密钥交换的安全性问题了。在这种加密通讯方式中通讯双方都需要有自己的公钥和私钥密钥对，因此会有四个密钥。

完整性

为了保证数据的完整性在计算机中最常用的技术就是数字摘要算法了，对一段数据进行摘要计算然后将摘要结果和原始数据一起发送给对方，对方收到数据后再执行相同的摘要计算如果得到的摘要结果和收到的摘要结果一致，那么基本可以确定数据就是一致的。
针对于上面提到的两种加密通讯方式，在对称加密过程中只要密钥没有泄漏其实并不需要摘要就可以保证一致，因为数据一旦被修改了解密动作会失败的。但是在非对称加密过程中通过简单的摘要算法是无法保证完整性的。
举个例子：发送方使用接收方公钥加密了一段数据并发送网络中。中间有个恶意的路由器截获了数据，虽然路由器不能知道数据是什么，但是它可以用接收方的公钥加密发送一段自己想要发送给接受方的数据，然后把截获的数据丢弃掉。这样其实就欺骗了接受方，因为在这种情况下接收方是无法识别发送方的身份的。基于这个情况需要为非对称加密引入一个新的概念叫数字签名，数据传输过程如下：

在上图第 6 步之后就可以拿到发送方的摘要数据和接受方自己计算的摘要数据，此时比较两个摘要数据就可以确定数据是不是指定发送方发送的。（此处的安全性依赖拿到的发送方的公钥是否是真实的发送方的公钥而不是被篡改的，这个安全性是通过证书和CA来保证的，下面会详细说明）上图中1，2两个步骤就是生成数字签名的过程，此处对非对称加密算法的应用和通讯时是的应用是相反的，此处使用自己的私钥对摘要数据进行了加密，而在第 6 步的时候用的是对应的公钥进行解密。第 2 步叫做签名，第 6 步和后续的进行摘要数据比较叫做验签。

这里简单总结一下非对称加密的两个核心用途：

1. 定向消息发送，即使用公钥加密私钥机密。这种做法可以保证只有指定的人能解密数据。
2. 身份验证，即使用私钥加密公钥解密。这种方法可以确认信息肯定是由确定的人发送出来的，即身份不会被冒充。
   其实如果将上述两个过程结合起来使用可以同时具有这两个特性。即发送方用自己的私钥和接收方的公钥进行二次加密，然后接受方反向应用二次解密。这种方式就可以保证定向发送消息也可以保证身份验证。

可认证性

在使用对称加密和由数字签名加持的非对称加密过程中可认证性已经得到了保证了，这里不再做过多说明。

经过上面的说明在不安全的网络环境中进行安全通讯的技术都已经具备了，下面就是要解决一些工程上的问题了：

1. 在对称加密的方式中，通讯双方如何才能进行安全的密钥交换？
2. 非对称加密是一个非常消耗资源的处理过程，如何优化这个过程？
3. 在非对称加密的过程中如何保证自己拿到的公钥是我期望的？例如我想和百度通讯，现在我手里有一个百度的公钥，我如何确定这个公钥就是百度的而不是其他人的？

关于证书和CA

我们先来解决第三个问题，如何保证我们拿到的公钥是指定实体的。我们常说的证书就是用来解决这个问题，那证书到底是什么？我们将域名、域名对应的公钥、域名对应组织或个人的基本信息如名称、地址等等这些数据作为一个整体叫 D，然后我们用另一个组织（我们可以叫这个组织为颁证机构）的私钥对数据 D 进行数字签名，计算出的签名叫 F，那么证书就是 D + F 的数据结合。当客户端拿到一个证书后就可以用颁证机构的公钥去验证该证书是不是合法的，这过程就是验签。那么下面我们就会面临下一个问题，如何验证我们用来验签的公钥是颁证机构的？此时我们好像陷入了一个困境，为了验证一个公钥的合法性我们引入了另一个公钥，问题就这样递归下去了。到底是先有鸡还是先有蛋呢？此时就需要 CA 出场了，CA 是 Certificate Authority(证书颁发机构) 的简写。在我们的计算机里面有个根证书的东西，根证书就是不需要验证的证书我们认为它们是可信的，我们可以自己手动安装到计算机上。各大 CA 的证书会被安装到根证书中，在验证证书的过程中，我们会不断向上验证签证机构，一直验证到当某个证书出现在了根证书中就停止验证，或者提示验证失败。由此可见 CA 可以给其他实体签发证书，因为他们的证书在我们的根证书中，一旦某个公钥被 CA 签发了证书那么这个公钥对应的私钥也是可以签发证书的。

下面一段代码是通过 openssl 创建一个自签发的根证书。

# 生成私钥
openssl genrsa -out private.key 4096
# 生成公钥
openssl rsa -in private.key -pubout -out public.key -in private.key
# 签发证书
openssl req -new -x509 -outform pem -key private.key -days 180 -out self.pem

其他两个问题

对称密钥的交换和非对称加密性能的问题可以用同一个方案一起解决。解决方案就是：我们可以先用非对称加密的方式协商一个对称加密的密钥，随后使用这个对称加密的密钥来进行通讯。

回到 https

上图就是 https 的通讯方式，它只是在 http 协议和 TCP 协议之间加了一层 SSL/TSL 层，至于为什么有两个名字，那就是一个历史遗留问题了，这里不做过多说明。SSL/TSL 层做的事情就是我上面提到的事：

1. 通过证书链和根证书去验证服务器证书的安全性。
2. 使用证书中提供的公钥协商一个对称加密的密钥

SSL/TSL 握手过程

下图就是 SSL/TSL 在建立连接时的握手过程，图中只展示了必要的步骤，有些可选的步骤并没有画出来。

到这里我们基本上谈论了关于 https 所有相关的问题，那么 https 真的安全么？
我只能说在网络节点上想监听或篡改在 https 上传输的数据基本是不可能的。但是如果我们能攻陷某个通许端的系统，我们还是有办法进行攻击的。例如：我把我的证书安装到目标机器上后，我们就能够实施攻击了。Charles 能抓 https 包就是通过这个原理来实现的。