简述HTTPS工作原理

首先，在正式讲解https之前，先对对称加密和非对称加密简单介绍一下。

• 对称加密：对称加密指的是客户端和服务器共用一个密钥对数据进行加密，同时也可用此密钥对数据进行解密，其加密的效率高。
• 非对称加密：非对称加密将密钥分为公钥和私钥，公钥通常在客户端，私钥在服务端，公钥加密的数据只能由私钥来解密，反过来，私钥加密的数据也只能由对应的公钥来解密。

其次，为什么要出现https呢？https解决了http的什么问题？https用的是对称加密还是非对称加密？

我们看一下http的一个简单传输过程：

http采用的是明文传输，很明显我们可以看到在传输的过程中可能会被有心人窃取到相关信息，有可能监听者还会对信息进行篡改，造成无法估量的损失，这对用户以及服务提供商都有极大的危害。

对这一问题的解决方案就是https，问题显而易见，http明文传输数据不安全，那如何才能使数据传输安全？我们可以想到用加密，对数据进行加密后，若没有相应的解密工具，即使被监听者截取也没有什么价值，因为很有可能在他看来就像是乱码串一样。

有了解决方案后，那么如何加密，如何使数据安全的在链路上传输又是一个亟待解决的问题。上面我们提到了两种加密方式，对称加密相对简单，效率高，我们首先肯定选它，如下图：

我们可以看到加密之后数据已经不是原始模样，在没有密钥情况下，监听者抓取的数据并不明白其含义，这个数据对其没有价值。对称加密好像可以解决数据的安全传输问题，但我们忽略了密钥如何确定这个问题，如何才能让客户端和服务端有共同的密钥呢？因此，客户端和服务端的首次通信总少不了一次明文传输（传输密钥）。但明文传输密钥又有可能被有心者抓取到，若是让监听者获取到了密钥，那加密算法也就没有用了。

紧接着我们就要解决如何在第一次明文传输的问题，解决方案就是我们上面提到的非对称加密算法，如下图：

非对称加密算法将密钥分为公钥和私钥，私钥在服务端保留，公钥，顾名思义，公开的密钥。客户端随机生成用于数据传输的密钥（即对称加密所要用到的密钥），在由公钥加密发送给服务端，因为私钥只有服务端有，也只有服务端能解密，所以即使监听者获取到了客户端发送给服务端的带着加密文的密钥，他也是解不开的。在服务端收到密钥后，客户端和服务端之间的密钥就确定下来，对于接下来的数据传输只用借助对称加密算法就可以安全进行。

这样看下来，似乎保障数据传输安全的问题似乎得到了解决。其实若我们仔细走一遍流程还是发现了问题，即客户端如何获取服务端的公钥，服务端总要将公钥明文传输给客户端，但既然明文传输那就存在风险。有人会说密钥是公开的就算让监听者窃取又如何，是的让监听者获取到公钥是没什么问题，我们可以设想一下，万一这位“有心人将公钥篡改了呢”，我们拿到的却是篡改后的公钥，当我们将密钥传输过去时，那么监听者就可以用假的私钥进行解密。

对于此问题，我们的解决方案是找第三方解决密钥问题，这个第三方就是CA认证，它是一个可以为网站签发数字证书的机构。这时网站的管理者可以将公钥提交给CA认证，它在用自己的私钥将网站提交的公钥和一些附加信息（比如域名）一起加密，然后将加密后的数据返还给网站，此时管理者只需将其放在自己的服务器上，当有客户端访问时，将此加密数据发送过去，客户端再用CA的公钥进行验证，若解密成功，我们便可得到CA给网站颁发的证书以及公钥。再用得到的公钥按照上面提到的步骤进行。

到此，可能又有人问CA的公钥如何获取呢？会不会被篡改呢？答案是并不会，因为CA认证机构是有限的，我们完全可以把所有CA认证机构的公钥内置在操作系统中，每当拿到网站发过来的加密数据，遍历我们内置在操作系统中的公钥，只要有一个能解密成功，说明此次数据正确以及发送数据的网站是经过CA机构认证过的，也是我们所请求的网站。

到此，数据在网络中的传输已经做到了足够的安全了，至于https中更为细节的内容，笔者水平有限，待以后深入研究后会考虑在起一片新的博客继续介绍。