我们用https的目的是什么？
为了 A端与B端互发的消息 就算被拦截获取到也是加密了无法查看的，通用的加密/解密过程如下：
以上的过程分析如下：
1 A端传入加密串"xx"进A端的加密方法中，加密处理后假设生成了“fwe^%^&Y*H^”。
2 然后A端将“fwe^%^&Y*H^”发送到B端。
3 B端接收到“fwe^%^&Y*H^”后，用其B端上的解密方法进行解密获得"xx"，根据"xx"查到了对应的字符串"YY",然后用自己的对应的加密方法将"YY"加密成”**&6jnj^^&“。
4 B端将”**&6jnj^^&“发送给A端，然后A端同样用其解密方法进行解密拿到返回结果"YY"。
注：以上是一般加密算法的通用过程，常用的加密算法类型一般有对称加密和非对称加密。但是！！需要确保双方都清楚对方的加密算法，才能正确加解密。
如何确保双方都清楚对方的加密算法？
具体的方案是：假设A端是服务器，B端是客户端，C端是客户端，则可以B、C端请求A端，然后A端返回对应的加密算法如下：
通过上面的过程B、C。。。等的客户端就能拿到A端提供的加密算法。
确保清楚加密算法会有什么安全隐患？
但是！！上一步是客户端生成一些加密申请信息然后像服务端请求，这样客户端向服务端请求的过程中，加密申请信息就可能会被拦截并篡改掉然后发给A端，其可能的篡改过程如下：
以下举一个例子作为解析：这里通过客户端向服务端发送加密方式，然后服务端用客户端提供的加密方式对带公钥的数据穿进行加密，最后将当前数据串发给客户端，客户端用它最早提供的加密参数进行解密，然后拿到了服务端提供的公钥pub_key，然后服务端和客户都安各自保存当前pub_key用非堆成加密确保数据传输安全。
1 假设客户端向服务端发送了如下数据，当前数据用data表示(即B端发下面的数据给A端)：
----
{
"alg": "RSA", //客户端需要的加密算法
"rnd": "ab#1j2*" //加密的随机串
}
----
2 这时，中间人窃取到了上面"1"中的数据data，然后将其篡改为如下(此次篡改后的数据表记为data1)：
----
{
"alg": "DSA", //篡改了加密算法，并记录了原先的数据
"rnd": "ab#1j2*" //加密的随机串
}
----
3 中间人将"2"中篡改过的data1发给A端。
4 这是A端接收到的数据是篡改后的，所以是不对的，服务端即A端就会根据篡改后的请求数据去找到自己的加密算法，也有可能根据其他参数返回不同的数据，然后假设服务端使用客户端提供的加密参数进行加密，返回的数据如下(此次返回的数据标记为data2)：
----
{
"pub_key":U2FsdGVkX181dCXplLLz", //篡改了加密算法，并记录了原先的数据
"extend": "{'a': 1, 'b': 2}" //其余的扩展参数
}
--加密后的数据串(这个返回的数据标记为data3) 假设为：
U2FsdGVkX1+ySGBsYEZmq0fL4/v/vG9GB+b9W
----
5 这时，中间人窃取到了"4"中的data2(即由服务端发过来的)，然后中间人获取到加密串data3之后用在"2"中篡过改的data1的加密参数进行解密，拿到了服务端的返回数据data2，然后修改data2为如下数据(标记为data4)：
----
{
"pub_key": "U2FsdGVkX181dCXplLLz", //篡改了加密算法，并记录了原先的数据
"extend": "{'a': 1111, 'b': 2222}" //其余的扩展参数！！！这里将a、b值都篡改了
}
--然后用在"1"步中拿到的原真实加密数据data对上面的data4加密(标记为data5)：A9WLH549w3zIqZ/PbQJ05ggfU=
----
6 中间人将data5 发给客户端，客户端即B端接收到了data5后，使用data的加密参数对data5解密，解密后得到中间人篡改后的data4数据。
注：中间人在服务端返回给客户端的过程中，用了篡改的加密参数对服务端的数据进行解密，然后用客户端原来发给他的加密参数进行加密，这是为了让客户端那边能够正常解密。
如何为客户端/服务端确认加密算法这个过程加上一个保障?
上一步我们通过客户端-服务端的交互确认的加密算法，但是因为都是明文的，所以造成传输的过程中被中间人窃取、伪造、冒充。这样导致服务端和客户端都被中间人欺骗了，均接收到了假数据。
上面可知加密的过程是通过客户端服务端先确认了一个公有的加密算法然后服务端加密出一个公钥返回给客户端，客户端和服务端就能同时持有这个公钥，然后使用非对称加密来传输数据。这里的关键点是客户端与服务端先用大家的知道的进行加密，然后最后在服务端决定出了一个公钥，然后使用大家都知道的对这个公钥进行加密，因为这个公钥是随机的，这样就确保加密的算法是随机的。然而客户端发给服务端确认大家都知道加密算法时会被中间人窃取，这个就是我们需要优化的点，优化了之后才能确保加密的公钥不被其他人所知。
但是！！怎么保障了？可通过HTTPS的SSL/TLS协议保证安全如下：
1 。为什么要用SSL/TLS？
从上面分析得到当前确保权的方法最终是拿到加密的公钥来进行数据传输的加密，然后服务端用对应的私钥解密，比如上面举的例子就是用另一个加密算法对这个生成的公钥进行加密然后返回，但是又涉及到了这个"另一个加密算法"的安全问题。但是如何确保传输的过程中加密公钥不被窃取，这时候HTTPS就采用了SSL/TLS协议中的数字证书来替代这个简单的"另一个加密算法"，确保身份验证的安全，避免数据被窃取。
2。数字证书的作用？
数字证书能确保"另一个加密算法"的公钥安全可信。即会将"另一个加密算法"的公钥放在数字证书里面，只要数字证书是可信的，那么这个公钥就可信。
3。公钥是安全了，但是如何又确保数字证书安全？
因为数字证书不是一个人私有的(数字证书给多家公司提供)，所以单纯使用数字证书的话。如果数字证书里面的公钥被调包了，我们就无法分辨是否正确。这时候需要身份验证即"数字签名"。
可通过数字签名来确保身份的安全，什么是数字签名？
服务器通过第三方机构提供的私钥采用非对称加密算法对证书编号进行加密，然后在返回数字证书给客户端。
客户端通过第三方机构的公钥对其数字签名(证书编号)进行解密，然后使用证书上的其他参数对这些参数进行加密等到客户端生成的证书编号。最后比较两个是否相等，如果相等就身份验证通过。
但是！客户端是怎么辨别数字证书是真的？
浏览器维护了所有合法机构的证书，可以直接在浏览器找到(当然浏览器被黑了话那也没办法了)。
说完上面的，说说SSL/TLS的请求响应过程？
SSL/TLS分为三步如下：
（1） 客户端向服务器端索要并验证公钥。
（2） 双方协商生成"对话密钥"。
-------------------------------------------
（3） 双方采用"对话密钥"进行加密通信。
其中前两步属于握手阶段，其握手阶段如下：
其中上图是使用数字证书包含会话密钥即信息互发的公钥安全，会话密钥是上图随机数A+B+C组成的，这样可确保当前伪随机数的随机性更大。
更多待续。。。。。。。。。。。。。。