本文转载自微信公众号「码工是小希」，作者码工是小希。转载本文请联系码工是小希公众号。
"噔噔噔......"传来一阵敲门声，把我从睡梦中惊醒了。
朦胧间听到有人在说活"提莫，在家不?”
“来了来了”，推门一看，原来是“李青”。
「李青」:自称武术大师，所有因为他安静冥想的举动而掉以轻心敌人都将会品尝他燃烧的拳头和炽烈的回旋踢，人送外号“盲僧”。
瞧瞧HTTPS
「提莫」：HTTPS这并不是应用层的一种新协议。只是HTTP通信接口部分使用SSL(安全套阶层)和TLS(安全传输层协议)协议代替而已。
HTTP是直接和TCP通信的。如果你用SSL，就变成先和SSL通信，SSL再和TCP通信了。简单来说，与SSL组合使用的HTTP被称为HTTPS(超文本传输安全协议)或HTTP over SSL。
你用了SSL，HTTP就有了HTTPS的加密、证书和完整性保护这些功能了。SSL是独立于HTTP的协议，所以不光是HTTP协议，其它运行在应用层的SMTP和Telnet等协议也要配合SSL协议的使用。可以说SSL是世界上应用最为广泛的网络安全技术。
步骤1：客户端通过发Client Hello报文开始SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件列表(所使用的加密算法及密钥长度等)。
步骤2：服务器可进行SSL通信时，会以Server Hello报文作为应答。和客户端一样，在报文中包含SSL版本和加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛出来的。
步骤3：之后服务器发送Certificate报文。报文中包含公开密钥证书。
步骤4：最后服务器发Server Hello Done报文通知客户端，最初阶段的SSL握手协商就结束了。
步骤5：SSL第一次握手结束之后，客户端以Client Key Exchange报文最为回应。报文中包含通信加密中使用的一种被称作Pre-master secret的随机密码串。该报文已用步骤3中的公开密钥进行加密。
步骤6：接着客户端继续发送Change Cipher Spec报文。该报文会提示服务器，在此报文之后的通信会采用Pre-master secret密钥加密。
步骤7：客户端发送Finished报文。该报文包含连接至今全部报文的整体效验值。这次握手协商是否能够成功，是以服务器是否能够正确解密该报文作为判定标准。
步骤8：服务器同样发送Change Cipher Spec报文。
步骤9：服务器同样发送Finished报文。
步骤10：服务器和客户端的Finished报文交换完毕之后，SSL连接就算建立完成，当然，通信会受到SSL的保护。从此处开始进行应用层协议的通信，即发送HTTP请求。
步骤11：应用层协议通信，即发送HTTP响应。
步骤12：最后由客户端断开连接。断开连接时，发送close_notify报文。上图做了一些省略，这步之后再发送TCP FIN报文来关闭与TCP的通信。
在以上流程中，应用层发送数据时会附加一种叫做MAC(Message Authentication Code)的报文摘要。MAC能够知道报文是否遭到篡改，从而保护报文的完整性。
「提莫」：每次发送真实数据之前，服务器这边先生成一把密钥，接着把密钥传给客户端。后面服务器给客户端发送真实数据的时候，会拿这把密钥对数据加密，客户端收到加密数据之后，用刚才收到的密钥进行解密。当然，如果客户端要给服务器发数据，也是用这把密钥来加密，这里为了方便，我就用单方向传输的形式来表示。如图：
「盲僧」：你看哈服务器是用明文方式传密钥给客户端，然后密钥被中间人给偷了，那么在之后服务器和客户端的加密传输过程中，中间人也可以用他偷的密钥来解密啊。这样的话，加密的数据在中间人看来和明文那没啥两样了啊。
「提莫」：这种方法是让客户端和服务器都拥有两把钥匙，一把钥匙是公开的(全世界都知道都没关系)，我们称之为公钥;另一把钥匙则是保密的(只有自己本人才知道)，我们称之为私钥。当然，用公钥加密的数据，只有对应的私钥才能解密;用私钥加密的数据，只有对应的公钥才能解密。
这样，服务器在给客户端传数据的过程中，可以用客户端明文给他的公钥进行加密，然后客户端收到后，再用自己的私钥来解密。客户端给服务器发送数据的时候也可以采取这种方式。这样能保持数据的安全传输了。上图：
「提莫」：就是对称加密+非对称加密这两种方式，我们可以用非对称加密的方式来传输对称加密过程中的密钥，之后我们就可以采取对称加密的方式来传输数据了呀。具体是这样子：
服务器用明文的方式给客户端发送自己的公钥，客户端收到公钥之后，会生成一把密钥(对称加密用的)，然后用服务器的公钥对这把密钥进行加密，接着再把密钥传给服务器，服务器收到后进行解密，最后服务器就可以安全着得到这把密钥了，而客户端也有同样一把的密钥，他们就可以进行对称加密了，是不是很神奇呀，大师。
「盲僧」：服务器用明文的方式给客户端传输公钥的时候，中间人截取了这本属于服务器的公钥，并且把中间人自己的公钥冒充服务器的公钥传给了客户端。
之后客户端就会用中间人的公钥来加密自己生成的密钥。然后把被加密的密钥再传给服务器，这个时候中间人又把密钥给截取了，中间人用自己的私钥对这把被加密的密钥进行解密，解密后中间人就可以获得这把密钥了，这你没想到吧!
最后中间人再对这把密钥用刚才服务器的公钥进行加密，再发给服务器。如图：
数字证书上场
在刚才的讲解中，我们知道了，之所以非对称加密会不安全，是因为客户端不知道这把公钥是不是服务器的，因此，我们需要找到一种策略来证明这把公钥就是服务器的，而不是别人冒充的。
解决这个问题的方式就是使用数字证书，具体是这样的：
我们需要找到一个拥有公信力、大家都认可的认证中心(CA)。
服务器在给客户端传输公钥的过程中，会把公钥以及服务器的个人信息通过Hash算法生成信息摘要。如图:
为了防止信息摘要被人调换，服务器还会用CA提供的私钥对信息摘要进行加密来形成数字签名。如图:
并且，最后还会把原来没Hash算法之前的个人信息以及公钥和数字签名合并在一起，形成数字证书。如图：
当客户端拿到这份数字证书之后，就会用CA提供的公钥来对数字证书里面的数字签名进行解密来得到信息摘要，然后对数字证书里服务器的公钥以及个人信息进行Hash得到另外一份信息摘要。最后把两份信息摘要进行对比，如果一样，则证明这个人是服务器，否则那就不是。如图：
其实，某些服务器一开始就向认证中心申请了这些证书了(有没有看过没有证书的网站在地址栏会被标出警告?)，而客户端是，也会内置这些证书。如图：
当客户端收到服务器传输过来的数据数字证书时，就会在内置的证书列表里，查看是否有解开该数字证书的公钥，如果有则...，如果没有则....
