11：https详解

转自：https://www.jianshu.com/p/0a7b028e2465

 

1:甲乙双发发送数据，直接用对称秘钥加解密数据，缺点：对称秘钥再交换的过程中可能被窃听；

2：甲用公钥加密数据，乙用私钥解密数据，缺点：非对称秘钥加解密过程数据耗时比较久；

3：用公钥加密对称秘钥，乙用私钥解密得到对称秘钥，然后双发用该对称秘钥加解密数据；缺点：甲发送的内容会被截获，然后黑客用

　　自己的数据，用公钥进行加密，转发给乙，而乙无法知道数据已经被改动；

4：甲发送的时候，末尾附上数字签名，用MD5等不可逆算法计算文件得到摘要，并用自己的私钥加密，乙得到数据后，用公钥解密得到摘要，并对原文进行MD5计算，得到

　　摘要，互相比对，认证发送者身份以及文件是否被改动；缺点：乙解密得到摘要的公钥，并不能确定是甲的；

5：用数字证书来绑定公钥和公钥所属人；甲发送给乙数据对的时候连同证书一起发送；

6：客户端如何验证服务端发过来的证书的有效性：客户端会有一个有效证书串，一般的浏览器都会内置很多常见服务器的这个证书，特殊的服务器就需要前期通过手工将证书

     添加到客户端。客户端通过比对来确认证书的有效性；

 单向认证双向认证参考：

https://blog.youkuaiyun.com/superviser3000/article/details/80812263

一般web应用都是采用单向认证的，原因很简单，用户数目广泛，且无需做在通讯层做用户身份验证，一般都在应用逻辑层来保证用户的合法登入。

     但如果是企业应用对接，情况就不一样，可能会要求对client（相对而言）做身份验证。这时需要做双向认证。

1：单向认证流程：

1.客户端say hello 服务端
2.服务端将证书、公钥等发给客户端
3.客户端CA验证证书，成功继续、不成功弹出选择页面
4.客户端告知服务端所支持的加密算法
5.服务端选择最高级别加密算法明文通知客户端
6.客户端生成随机对称密匙key，使用服务端公钥加密发送给服务端
7.服务端使用私钥解密，获取对称密匙key
8.后续客户端与服务端使用该密匙key进行加密通信

 

2：双向认证流程：

1.客户端say hello 服务端
2.服务端将证书、公钥等发给客户端
3.客户端CA验证证书，成功继续、不成功弹出选择页面
4.客户端将自己的证书和公钥发送给服务端
5.服务端验证客户端证书，如不通过直接断开连接
6.客户端告知服务端所支持的加密算法
7.服务端选择最高级别加密算法使用客户端公钥加密后发送给客户端
8.客户端收到后使用私钥解密并生成随机对称密匙key，使用服务端公钥加密发送给服务端
9.服务端使用私钥解密，获取对称密匙key
10.后续客户端与服务端使用该密匙key进行加密通信

转载于:https://www.cnblogs.com/wnpp/p/8092731.html