有了http，为啥还需要https？（过程推演）

http是一种超文本协议，客户端和服务端通过http可以进行信息交换，但客户端和服务端数据交互必然是通过互联网，这中间经过许多的网络中间节点（路由、代理、网络提供商ISP等），这些节点可以获得经过的数据，从而可以对数据进行窥窃，篡改，存在安全问题。

要解决这个问题，客户端和服务端必然需要做数据加密，再传输。这样即使数据被中间节点截胡了，拿到的也是加密后数据，没有用处。这里传输数据用对称加密，双端使用同一个密钥。

对称加密：加密和解密使用相同一个密钥。比如AES。

那么问题来了，客户端和服务如何使用同一个密钥，这就需要客户端或服务端生成，然后发送给另一端，此时密钥经过中间节点，必然会被窃取（密钥也是明文），中间节点拿到密钥，那后续传输的加密数据也可以轻易解开了。

那我们是不是可以不经过网络传输密钥？是可以，像以前一些银行，给用户办理账号时会发一个U盾，把密钥写在U盾上，转账时，用户插入U盾就可以了；还有一些企业应用后台，修改重要数据时，也是需要插入一个加密狗。这些都是通过线下传输密钥的例子。

但这种方式不具备通用性，一个互联网应用，面对的可能是上亿的用户，不可能给每个用户去线下发一个硬件密钥。

无法避开网络传输密钥，那我们是不是可以对密钥加密后再传输？一种方法是对密钥做对称加密后传给对端，显然不行，因为对密钥加密的密钥，也是面临同样的问题，怎么告诉对端，而且不让中间节点截胡？这样就套娃了，始终存在一个需要明文传输的密钥。另一种方法是用非对称解密，对密钥进行加密。这个看起来似乎可以。

非对称加密：密钥是一对，私钥和公钥，私钥加密可以被公钥解密，公钥加密可以被私钥解密，但公钥加密不能被公钥解密。比如RSA。

服务端生成私钥（假如是private_key_01）和公钥（假如是public_key_02），私钥保存在服务端，公钥通过网络传输给客户端。客户端拿到公钥后，本地随机生成一个对称加密的密钥（假如是key_03），用服务端传来的public_key_02对key_03加密，把加密后的key_03传输给服务端。服务端拿到加密后的key_03，用private_key_01去解密，得到key_03明文。此时客户端和服务端同时拥有明文key_03了，后续双端就用key_03加解密数据后传输。

这个过程似乎已经非常完美了，但还是存在漏洞。服务端传输publIc_key02给客户端是经过中间节点的，此时中间节点拿到publIc_key02后保存起来，把自己伪装成客户端，同时生成自己的私钥（假如是private_key_04）和公钥（假如是public_key_05），把public_key_05传输给原客户端，自己伪装成服务端。客户端用public_key_05加密key_03后，伪服务端用private_key_04可以解密，得到key_03明文。然后伪服务端（同时是伪客户端）用public_key_02加密key_03后传输给真服务端。这样数据还是能被中间节点窃取和篡改。

问题出现在服务端传输publIc_key02给客户端这一个步骤，客户端无法判断收到的公钥是否是服务端真实的公钥，客户端无法辩伪。要解决这个问题，就要引入第三方认证。我们假设第三方CA机构是权威且公正的（事实上靠法规约束）。

服务端去CA机构申请证书，把域名（假如是www.abc.com）、公钥publIc_key_02给到CA机构，CA机构又是通过非对称加密（假如CA机构私钥是private_key_06, 公钥是publIc_key_07）把域名、publIc_key_02加密起来，形成一个证书给到服务端，那么服务端传输给客户端的就不是公钥了，而是这个证书，里面包含了域名abc、公钥publIc_key_02。客户端用CA机构的公钥publIc_key_07去解密证书，得到公钥publIc_key_02和域名abc，通过域名可以判断证书是否真实。

而这里又面临着另一个问题，客户端是如何得到publIc_key_07的？一般在安装系统时，这些CA机构都预先把公钥publIc_key_07内置在操作系统里了，是以证书的形式保存在操作系统的。客户端（浏览器）做https请求时用这些内置证书做验证。

至此，https的整个过程推演完毕。