引言

HTTPS：Hyper Text Transfer Protocol over SecureSocket Layer

HTTPS => HTTP + SSL / TLS

SSL：Secure Socket Layer（安全套接层）

HTTPS 中的 S 表示 SSL，是一种握手协议，这种握手协议也就是本篇博客着重介绍的加密过程。HTTPS 也是一个应用层协议，只是在 HTTP 协议的基础上引入了一个加密层。

为什么要加密呢？

HTTP 协议在网络传输中，非常广泛！然而，HTTP 协议内容都是按照文本的方式，进行明文传输的，这就导致在传输过程中，数据可能被 第三方 / 黑客 篡改。所以，通过一系列的加密过程，在传输数据时，将明文以一些规则变成密文，即使黑客或第三方中间人获取到文件，那么也看不懂的数据。结合日常生活的场景，这并不难理解。

理解加密解密

加密：把明文( 要传输的信息 ) 进行一系列变换规则，生成密文。

解密：把密文 ( 收到的信息 ) 进行一系列变换规则，生成明文。

加密解密主要采取两种形式：

① 对称加密

加密：明文 -> 密文，使用密钥1

解密：密文 -> 明文，使用密钥1

② 非对称加密

加密：明文 -> 密文，使用密钥1

解密：密文 -> 明文，使用密钥2

非对称加密实际上是这样的思想：

服务器既拥有密钥1、又拥有密钥2。服务器通常将密钥1 公开出去，那么任何客户端都能够获取到这个密钥1，客户端通过密钥1 对明文进行加密，最终服务器再通过密钥2 来对密文解密。密钥1 被称为公钥，密钥2 被称为私钥。

举个例子：A 给 B 送信，信中有钱、银行卡…A 与 B 在送信的前一天晚上进行了沟通。B 对 A 说：“ 如果明天你去办公室找我的时候，我人不在，你就把信放到桌子旁的柜子里，然后用锁锁起来，锁在我的办公桌上，我已经把锁打开了，你到时候扣上就行，到时候我忙完回办公室的时候，拿钥匙一开就行了。”

在上面的例子中，锁就相当于是公钥，钥匙就是私钥。同一把锁对应同一把钥匙才能相互配合。在信件放入柜子的时候，也就能保证钱和银行卡的安全了。

结论：

对称加密，至始至终，只使用一个密钥。

非对称加密，需要两个不同的密钥进行紧密配合。

SSL 的握手过程

场景一

在场景一中，客户端通过对称密钥进行加密，服务器通过相同的对称密钥进行解密，而就算黑客拦截信息后，如果不知道密钥，就无法破译密文。

场景一很简单，很实用，也很好理解。在日常生活中，面对一些信息的加密，普通用户或许就是这么做的。

但是！网络环境是非常复杂的，服务器不可能只为一个客户端服务。这并不像电影中的两个接头，对上暗号那么简单！

如下图所示，服务器在同一时刻，可能是给很多客户端提供服务的，数量或许是几千，或许是几万，或许是几百万…这么多客户端，如果每个人用的密钥都是相同的，那么，可想而知，密钥就不可能安全，由于一传十，十传百，黑客就也能拿到了密钥了，这样一来，就不谈传输安全了。因此，服务器就需要维护每个客户端和每个密钥之间的关联关系，这也是个很麻烦的事情。请继续往下看，场景二。

场景二

比较理想的做法，就是能在客户端和服务器建立连接的时候，双方协商确定这次的密钥是什么，确定好了，再进行信息交互，就免了所有的后患了。在场景二中，客户端和服务器每次传输数据的时候，通过特定的密钥加密解密，而这个特定的密钥，在第一次两者建立连接的时候，就需要确立好。

在场景二 中，或许已经理想了，客户端和服务器今后就能通过独立的对称密钥进行信息交互了。但是！上图中的密钥却也是以明文传输的，这就造成了黑客依旧能够拦截到密钥数据，从而造成了不安全的情况。

因此，我们就应该将密钥也要进行加密，也就是【密钥的密钥】，然而，难道我们应该再给【密钥的密钥】进行再加密吗？如此循环下去，终究解决不了第一次对称密钥的传输安全性。

鉴于此，我们就引入了非对称加密这个机制。

场景三

在场景三中，客户端持有公钥，服务器持有私钥，在第一次请求之后，服务器通过私钥解开了公钥加密的密文，从而拿到了对称密钥，之后就能够正常传输了，然而，之后的正常传输依然要加密，并且常采取对称密钥，不再使用非对称密钥了。

为什么？

可以看到，公钥密钥在配合使用的时候相当麻烦。还是之前说的，一个服务器在同一个时刻，可能与多个客户端进行交互。试想，每一次的请求与响应都需要这样配合，那么机器消耗资源极高，速度也慢。如果说，公钥密钥之间的配合只是用来保证第一次传输的对称密钥无误，那么后续使用对称密钥的机制来传输业务数据，也就没有什么太大问题，并且，采取对称密钥，效率高，速度快很多。

此外，在场景三中，客户端持有公钥，服务器持有私钥。在服务器第一次解密之前，黑客拿不到公钥对应的密钥，在服务器第一次解密后，黑客依旧拿不到对称密钥。所以，从过程和结果看，这都是安全的。但这有一个前提，那就是黑客没有伪造公钥，请继续往下看。

中间人攻击

但是，在场景三中，服务器刚开始应该是有公钥和私钥的，而客户端是通过某些方式来获取公钥的。

假设，在这过程中，黑客从服务器第一次返回响应给客户端的时候，黑客伪造了公钥给客户端，如果客户端拿到了假的公钥，结局就很难预料了。

如下图：整个过程中，黑客充当了中间人，从客户端和服务器两者交互的过程中，横插了一脚，这被称为中间人攻击。

那么，客户端是如何获取到公钥的呢？客户端是如何确定这个公钥不是黑客伪造的呢?

请看场景四。

场景四

怎么解决中间人攻击呢？

在客户端和服务器刚一建立连接的时候，服务器给客户端返回一个 证书。这个证书包含了即将给客户端使用的公钥，也包含了网站的身份信息。这个证书就好比人的身份证，作为这个网站的身份标识。搭建一个 HTTPS 网站要在 CA机构 先申请一个证书，这个过程就类似于去公安局办个身份证。

证书是第三方介入的，当然，证书需要有权威性，合法性…在客户端和服务器连接之前，两者与证书并无关系。所以，客户端需要以一些规则，对服务器响应时返回的证书进行校验，来保证证书的所有者正确，保证证书的有效期符合期限，保证证书的发布机构的权威性等等…

场景四如图：

总结

• 客户端先从服务器获取到证书，证书中包含了公钥
• 客户端对证书进行校验
• 客户端生成一个对称密钥，使用公钥对对称密钥进行加密，发送给服务器
• 服务器得到这个请求之后，使用私钥解密，得到对称密钥
• 客户端发出后续的请求，后续的请求都是使用这个对称密钥加密的
• 服务器后续收到的数据，自然也是使用同样的对称密钥解密的

综上所述，整个 HTTPS 加密过程的难点就在于，不仅要保证【传输内容】是安全的。还要保证为传输内容设置的【密钥】也是安全的。

所以，这需要对称加密和非对称加密的一起使用，对称加密保证了【传输内容】的安全性，非对称加密保证了【密钥】安全性。