突然想到一个问题，在客户端与服务器数据传输的过程中，http 协议的明文传输是不安全的，但 https 协议的数据传输是安全的，也就是说 https 数据是经过加密的。
那在客户端与服务器这两个完全没有见过面的陌生人交流中，https 如何保证数据传输的安全性呢？
带着疑问一步步解析 https 加密过程。这里先把客户端称为客客，服务器称为服服。然后探索在客客与服服的交流中（就是一方请求一方响应）,https 是如何保证他们的交流不会被中间人窃听。
1.对称加密：
假如现在客客与服服要进行一次私密对话，他们不希望这次对话内容被其他外人知道。可是，我们平时的数据传输过程中又是明文传输的，万一被某个黑客把他们的对话内容给窃取，泄露隐私就难受了。
为了解决这个问题，服服这家伙想到了一个方法来加密数据，让黑客看不到具体内容。该方法是这样子的：
在每次数据传输之前，服服会先传输客客一把密钥，然后服服在之后给客客发消息的过程中，会用这把密钥对这些消息进行加密。客客在收到这些消息后，会用之前服服给的那把密钥对这些消息进行解密，这样，客客就能得到密文里面真正的数据了。如果客客要给服服发消息，也同样用这把密钥来对消息进行加密，服服收到后也用这把密钥进行解密。 这样，就保证了数据传输的安全性。如图所示:
这时，服服想着自己的策咯，还是挺得意的。
可是，这时候问题来了。这个策略安全的前提是，客客拥有服服的那把密钥。可问题是，服服是以明文的方式把这把密钥传输给客客的，这个时候，如果黑客截取了这把密钥，不就徒劳无功了嘛？服服与客客就算是加密了内容，在截取了密钥的神秘黑客面前，这和明文没啥区别。
2.非对称加密
服服还是挺聪明的，得意了一会之后，服服意识到了密钥会被截取这个问题。倔强的服服又想到了另外一种方法：用非对称加密的方法来加密数据。该方法是这样的：
服服和客客都拥有两把钥匙，一把钥匙的公开的（全世界都知道也没关系），称之为公钥，而另一把钥匙是保密（也就是只有自己才知道），称之为私钥。并且，用公钥加密的数据，只有对应的私钥才能解密，用私钥加密的数据，只有对应的公钥才能解密。
所以在传输数据的过程中，服服在给客客传输数据的过程中，会用客客给他的公钥进行加密，然后客客收到后，再用自己的私钥进行解密。客客给服服发消息的时候，也一样会用服服给他的公钥进行加密，然后服服再用自己的私钥进行解密。 这样，数据就能安全的到达双方。如图：
想着这么复杂的策略都能想出来，服服可是得意的不能在得意了…..
看着那么得意的服服，客客这时心有所思。还没等服服得意多久，客客就给它泼了一波冷水。
客客严肃着说：其实，你的这种方法也并非绝对安全，还是存在被黑客截取的危险啊。例如：
你在给我传输公钥的过程中，如果黑客截取了你的公钥，并且拿着自己的公钥来冒充你的公钥来发给我。我收到公钥之后，会用公钥进行加密传输（这时用的公钥实际上是黑客的公钥）。黑客截取了加密的消息之后，可以用他自己的私钥来进行解密来获取消息内容。然后在用你（服服）的公钥来对消息进行加密，之后再发给你（服服）。 这样子，我们的对话内容还是被黑客给截取了啊。（倒过来客客给服服传输公钥的时候也一样）。
我靠，这么精妙的想法居然也不行，服服这波，满脸无神,直呼离谱。
3.数字证书
回想一下，是什么原因导致非对称加密这种方法不安全性呢？它和对称加密方法的不安全性不同。非对称加密之所以不安全，是因为客客收到了公钥之后，无法确定这把公钥是否真的是服服。
也就是说，我们需要找到一种策略来证明这把公钥就是服服的，而不是别人冒充的。
为了解决这个问题，服服和客客通过绞尽脑汁想出了一种终极策略：数字证书：
我们需要找到一个拥有公信力、大家都认可的认证中心(CA)。
服服在给客客发公钥的过程中，会把公钥以及服服的个人信息通过Hash算法生成消息摘要。如图：
为了防止摘要被人调换，服服还会用CA提供的私钥对消息摘要进行加密来形成数字签名。如图：
并且，最后还会把原来没Hash算法之前的信息和数字签名合并在一起，形成数字证书。如图：
当客客拿到这份数字证书之后，就会用CA提供的公钥来对数字证书里面的数字签名进行解密得到消息摘要，然后对数字证书里面服服的公钥和个人信息进行Hash得到另一份消息摘要，然后把两份消息摘要进行对比，如果一样，则证明这些东西确实是服服的，否则就不是。如图：
这时可能有人会有疑问，CA的公钥是怎么拿给客客的呢？服服又怎么有CA的私钥呢？其实，(有些)服务器在一开始就向认证中心申请了这些证书，而客户端里，也会内置这些证书。如图:
当客户端收到服务器返回来的数据时，就会在内置的证书列表里，查看是否有有解开该数字证书的公钥，如果有则…..否则…..
至此，大概就结束了。
