纯https干货，看懂了就吃透了

上一篇，把一些基本概念在https里理清楚了，基础框架都有了。所以本篇是针对有一些https基础，但又没有特别深的理解的人看，属于进阶篇。

首先，https是http+TSL，TSL实现通讯的本质是：在客户端和服务器端之间用非对称加密方式协商出一套对称密钥，并用对称密钥对数据进行加密传输。在后面的介绍里，会把这个本质讲清楚。大家看完以后，在回头看这句话，会有深刻的理解。

客户端和服务器端建立通讯要经历五大步：

1. 建立TCP连接：就是大家耳熟能详的三次握手，以达到通讯双方都知晓且做好准备；
2. 协商通讯加密的一些细节：包括TSL版本，加密套件（密钥交换算法，批量加密算法，消息验证码，伪随机数啊）等。关于加密套件里面的一些细节，我会后面单独开一篇。
3. 客户端对于服务器端证书校验。这里对于证书签名，我也会再单独讲。
4. 证书校验成功后，生成会话密钥。这个点会结合到之前提到了三次随机数，非常核心！
5. 可以正式通讯啦！ 

后面重点讲2/3/4这三大步，因为涉及内容比较多，也比较难理解。

2. 协商通讯加密的细节

客户端第一次会向服务器端自报家门：它能兼容的TSL的版本，它可用的密钥交换算法，加密算法，消息验证码，并生成第一个随机数（称它为A）；密钥交换算就是一些非对称算法：Diffie-Hellman/RSA/EDCDH等。加密算法就是对称的：AES；消息验证码：MD5/SHA1/SHA2等。

服务器端收到客户端的消息后，会确认以上的信息返回给客户端，并且生成一个随机数（称B）。

至此双方已经约定好了加密的一些基本信息，但是，为了确认服务器端的身份，服务器端必须发送自己的证书给到客户端。于是，下面就开始校验证书。

3.客户端对服务器端的证书进行验证

带有电子签名的证书里面包含公钥，当客户端拿到了证书也就拿到了公钥，注意这个公钥是服务器端的非对称密钥里的公钥，私钥还是服务器端。那客户端如何验签名呢？这里有个很绕的点是，这个证书的颁发的电子签是证书认证机构用自己的私钥签的，必须要用证书机构的公钥验。恰恰这个公钥是配置在了客户端。所以，这个时候客户就可以拿存在他那里的证书机构的公钥去验证签名。能验过就证明服务器端的合法合规性。

拿到这个证书的关键点在于，客户端就拿到了服务器端的公钥。这个公钥可以用来加密需要传输的随机数，这个随机数是为了以后生成最终的会话密钥。

4.会话密钥生成

在第三步的时候，客户端拿到了服务器端的公钥。它会计算一个预主密钥，用这个公钥加密后发给服务器端。服务器端用自己的私钥解开后，得到这个预主密钥。注意，至此双方都有三串数字，A+B+预主密钥。这个密钥会派生出相同的hash密钥和会话密钥，这都是对称密钥，意味着双方都持有相同的密钥。这样后续，大家可以对报文进行加解密，从而进行安全通讯。

大家会想为啥如此繁琐的进行通讯？这个事情可以逆向去看，就能很好理解。我会在别的文章里，带着大家逆向的梳理一下。这样你就可以把https彻底吃透。

还有一些问题我是在写这篇文章时候想到的：

1. OSI模型和https通讯的整个逻辑关系。

2.如果中间人也去申请一个同样的证书，然后整体掉包，是否能成功呢？

希望大家读完有所收获，有问题欢迎留言，互相讨论，共同学习和进步！