HTTPS 协议

什么是 HTTPS 协议呢？如果大家还没有深刻理解 HTTP 协议，请查找一下我的 HTTP 协议的文章。

HTTP 协议是一个明文传输的协议，也就是说在整个链路中传输的话，可以理解问数据在“裸奔”，在任意一个节点上数据都有可能被人截取，串改。最明显的表现就是访问一个网页的时候，明明网页没有广告，但是在浏览器打开后却又很多广告，这就是串改了响应报文，如果是请求报文被串改那就更严重了，如果操作是银行转账请求，你们的钱可能就会被转到别人的钱包了。

所以 HTTPS 协议就是在 HTTP 协议上加了个安全层。

HTTPS 协议

由于 HTTP 天生“明文”的特点，整个传输过程完全透明，任何人都能在链路中截取、修改或者伪造请求/响应报文，数据不具有可信性。因此就诞生了为安全而生的 HTTPS 协议。

以前使用 HTTP 协议的时候，应用程序往往直接通过内核提供的一些 API 去完成数据的传输，和 TCP 进行交互。

HTTPS 并没有对 HTTP 协议进行任何的修改，而是应用程序不直接和 TCP 进行交互了，变为和 SSL/TSL 安全套接层进行交互，然后安全层在和 TCP 进行交互。

SSL/TSL

SSL 即安全套接层（Secure Sockets Layer），由网景公司于 1994 年发明，IEIF 在 1999 年把它改名为 TLS（传输层安全，Transport Layer Security），正式标准化，到今天 TLS 已经发展出了主流的三个版本，分别是 2006 年的 1.1、2008 年的 1.2 ，2018 的 1.3，每个新版本都紧跟密码学的发展和互联网的现状，持续强化安全和性能，已经成为了信息安全领域中的权威标准。

HTTPS 是利用了几个算法来完成加密通道的一个建设的，下面来看一下都有哪些算法

摘要算法

摘要算法能够把任意长度的数据“压缩”成固定长度，而且独一无二的“摘要”字符串，就好像是给这段数据生成了一个数字“指纹”。任意微小的数据差异，都可以生成完全不同的摘要。所以可以通过把明文信息的摘要和明文一起加密进行传输，数据传输到对方之后再解密，重新对数据进行摘要，在对比就能发现数据有没有被篡改。这样就保证了数据的完整性。

加密算法

对称密钥加密算法：

编、解码使用相同密钥的算法，如（AES，RC4，ChaCha20）。

非对称加密算法：

它有两个密钥，一个叫“公钥”，一个叫“私钥”。两个密钥是不同的，公钥可以公开给任何人使用，而私钥必须严格保密。非对称加密可以解决“密钥交换”问题。网站秘密保管私钥，在网上任意分发公钥，你想要登录网站只要用公钥加密就行了，密文只能由私钥持有者才能解密。而黑客因为没有私钥，所以无法破解密文。非对称密钥加密系统通常需要大量的数学运算，比较慢。如（DH，DSA，RSA，ECC）。

私钥和公钥都部署在服务器上，但是私钥不参与网络传输，公钥加密的数据只能用私钥解密，私钥加密的数据只能用公钥解密，所以浏览器给服务器发送用公钥加密的数据是安全的，但服务器给浏览器发送用私钥加密的数据是不安全的，因为公钥是可以被人窃取到的。

TLS 里使用的混合加密方式，即把对称加密和非对称加密结合起来，两者互相取长补短，既能高效的加密解密，又能安全的密钥交换。大致流程如下：

1. 通信开始的时候使用非对称加密算法如 RSA，ECDHE 先解决密钥交换的问题

1. 用随机数产生对称算法使用的“会话密钥”，再用公钥加密。会话密钥很短，所以即便使用非对称加密算法也可以很快完成加解密

1. 对方拿到密文后用私钥解密，取出会话密钥。完成对称密钥的安全交换，后续就使用对称算法完成数据传输

身份验证

数字证书组成：

CA 信息，公钥用户信息，公钥，权威机构签名，有效期

数字证书作用：

1. 通过数字证书向浏览器证明身份

2. 数字证书里面包含了公钥

数字证书的申请和验证：

如何申请：

1. 生成自己的公钥和私钥，服务器自己保留私钥

2. 向 CA 机构提交公钥，公司，域名信息等待验证

3. CA 机构通过线上，线下多种途径验证你提交信息的真实性，合法性

4. 信息审核通过，CA 机构则会向你签发认证的数字证书，包含了公钥，组织信息，CA 信息，有效时间，证书序列号，同时生成一个签名

签名步骤：

hash（你用于申请证书所提交的明文信息）= 信息摘要，CA 再使用私钥对信息摘要进行加密，密文就是证书的数字签名

浏览器如何验证呢？

有了 CA 签名过的数字证书，当浏览器访问服务器时，服务器会返回数字证书给浏览器，浏览器收到证书后会对数字证书进行验证。

首先浏览器读取证书中相关的明文信息，采用 CA 签名时相同的 hash 函数计算得到信息摘要 A，再利用对应的 CA 公钥解密数字签名数据得到信息摘要 B，如果摘要 A 和摘要 B 一致，则可以确认证书是合法的。

下面我们来解析一下这张图：

首先服务器上面会部署公钥和私钥，浏览器和服务器进行数据交互的时候，会先进行三次握手，三次握手完成之后，会进行安全层的握手也就是 HTTPS 的握手。

那么什么是 HTTPS 的握手呢？

客户端会发送请求给服务器，会发送客户端支持的加密套件列表，也就是客户端支持哪些加密算法，服务端同样的，在进行加密通道构建的时候，一定是双方都要支持才能进行加解密，所以服务器端会看一下本地的实现，看客户端提供的加密算法服务器都支不支持，支持的话会从中选择最安全的一个算法，然后告诉客户端选择了哪个加密套件，并且会把公钥数字证书发送给客户端，客户端验证证书合法性，生成一个随机密钥（用于对称加密密钥），并用传过来的公钥进行加密，发送给服务器端，服务器端就可以用私钥进行解密，这样就安全的拿到了对称加密的密钥，这时就可以使用对称加密算法完成数据的双向传输。

到这大家是不是有这样一个疑问，为什么要使用数字证书呢，直接传公钥不行吗？

现在我来解释一下，在之前 TCP 三次握手的时候我说过，客户端要去拿到服务器端的 ip，那如果在拿服务器端 ip 的时候被人截获了我们的 DNS 信息，修改了 DNS 中的 ip 地址，指向了一个黑客自己的服务器，这时候请求和数据就都到达了黑客的服务器，因此要去验证访问的服务器是真的我们要访问的那台服务器，这时候数字证书就派上了用场。