HTTP 与 HTTPS

HTTPS 在 TCP 三次握手后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。HTTP 默认端口号是 80，HTTPS 默认端口号是 443。同时，HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

HTTPS通过混合加密、摘要算法以及身份证书，来完成对 HTTP 传递明文的内容完成加密。

混合加密
HTTPS 采用的是对称加密和非对称加密结合的「混合加密」方式：

在通信建立前采用非对称加密的方式交换「会话秘钥」，后续就不再使用非对称加密。 在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。

摘要算法 + 数字签名
在计算机里会用摘要算法（哈希函数）来计算出内容的哈希值，也就是内容的「指纹」，这个哈希值是唯一的，且无法通过哈希值推导出内容。如果哈希值相同则可证明内容未被篡改。但是该算法并不能保证「内容 + 哈希值」不会被中间人替换，因为这里缺少对客户端收到的消息是否来源于服务端的证明。

为了判断消息是否来自于服务端，会用非对称加密算法来解决，共有两个密钥： - 一个是公钥，这个是可以公开给所有人的； - 一个是私钥，这个必须由本人管理，不可泄露。

这两个密钥可以双向加解密：公钥加密私钥解密则可保证内容传输的安全；私钥加密公钥解密则保证消息不会被冒充。非对称加密的用途主要在于通过「私钥加密，公钥解密」的方式，来确认消息的身份，我们常说的数字签名算法，就是用的是这种方式，不过私钥加密内容不是内容本身，而是对内容的哈希值加密。

加密算法流程

私钥是由服务端保管，然后服务端会向客户端颁发对应的公钥。如果客户端收到的信息，能被公钥解密，就说明该消息是由服务器发送的。

数字证书
CA 通过自己的私钥把服务端的公钥做了数字签名，把「个人信息 + 公钥 + 数字签名」打包成一个数字证书；客户端使用时会通过 CA 验证数字证书是否合法，CA 验证成功后就可以证明服务端的公钥合法，完成身份验证。

HTTPS 的加密流程

SSL/TLS 协议基本流程：

• 客户端向服务器索要并验证服务器的公钥。
• 双方协商生产「会话秘钥」。
• 双方采用「会话秘钥」进行加密通信。

前两步就是 TLS 握手阶段，涉及四次通信，使用不同的密钥交换算法，TLS 握手流程也会不一样的，现在常用的密钥交换算法有两种：RSA 算法和 ECDHE 算法。其中 RSA 算法相对容易。

RSA 完成 TLS 握手

以下会进行具体分析：

ClientHello
首先客户端向服务器发起加密通信请求，这里需要发送客户端的 TLS 版本，产生的随机数（Client Random，用于生成「会话秘钥」条件之一），以及支持的密码套件列表（如 RSA 算法）。

ServerHello
服务器收到客户端请求后，向客户端发出响应，包含确认 TLS 版本，服务器生成的随机数（Server Random，用于生产「会话秘钥」条件之一），确认的密码套件列表以及服务器的数字证书。这里就是三个确认+ CA。

客户端回应
客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：一个随机数（pre-master key，会被服务器公钥加密）；加密通信算法改变通知，表示之后信息用「会话秘钥」加密通信；客户端握手结束通知，会把之前的数据做摘要供服务端校验。

服务器和客户端有了这三个随机数（Client Random、Server Random、pre-master key），接着就用双方协商的加密算法，各自生成本次通信的「会话秘钥」。

服务器最后回应
计算得到「会话秘钥」，发送最后的信息：加密通信算法改变通知，表示之后都用「会话秘钥」加密通信；服务器握手结束通知，会把之前数据做摘要供客户端校验。

TLS 至此全部结束，接下来证实进入加密通信，就是完全的 HTTP 协议，只不过用「会话秘钥」加密内容。

这里在学一下 CA 具体的签发和验证流程。

CA 流程

签发证书：

• CA 会把持有者的公钥、用途、颁发者、有效时间等信息打成一个包，然后对这些信息进行 Hash 计算，得到一个 Hash 值；
• 通过自己的私钥将 Hash 值加密，生成 Certificate Signature，也就是签名；
• 将 Certificate Signature 添加在文件证书上，形成数字证书。

校验证书：

• 使用同样 Hash 算法获取该证书 Hash 值 H1；
• 通过浏览器和操作系统中集成的 CA 公钥，解密 Certificate Signature 内容，得到 Hash 值 H2；
• 比较 H1 和 H2，相同则为可信赖证书。

证书的验证过程中还存在一个证书信任链的问题，操作系统会内置一些根证书，通过根证书的信任一层层到中间证书再到服务器证书。搞证书链是为了确保根证书的绝对安全性，将根证书隔离地越严格越好，不然根证书如果失守了，那么整个信任链都会有问题。

TLS 在实现上分为握手协议和记录协议两层： - TLS 握手协议就是我们前面说的 TLS 四次握手的过程，负责协商加密算法和生成对称密钥，后续用此密钥来保护应用程序数据（即 HTTP 数据）； - TLS 记录协议负责保护应用程序数据并验证其完整性和来源，所以对 HTTP 数据加密是使用记录协议。

记录协议，及时现将消息分割切片并压缩后，在压缩片段后加上消息认证码（MAC 值，这个是通过哈希算法生成的），这是为了保证完整性，并进行数据的认证。之后会将加上消息认证码的报文一起通过对称密码加密，并在加密数据前加上数据类型、版本号以及压缩后长度完成最终的报文数据。

HTTPS 协议本身到目前为止还是没有任何漏洞的，即使你成功进行中间人攻击，本质上是利用了客户端的漏洞（用户点击继续访问或者被恶意导入伪造的根证书），并不是 HTTPS 不够安全。为了解决这种问题，可以通过 HTTPS 双向认证来避免。