667-数据明文传输的安全问题

数据明文传输的安全问题

在集群聊天服务器项目上，是明文的交互，采用的是Json做序列化和反序列化，从登录，注册的基本的业务开始，和后端的服务的交互，全都是明文的交互，相当于在浏览器上去访问web后端是用的https协议，数据确实是非常的不安全，所以我们可以通过加密，传输之前要进行加密，对端接收之后要进行解密。
真真正正的项目，客户端和服务器通信：加密算法。用的是对称和非对称的混合加密。

数据的加密解密

1、对称加密算法

客户端client要给服务器server发送消息，client有一个密钥key（由客户端的某些信息随机生成的），把这个发送消息（比如说是登录的消息login zhangsan 123456）加密一下，加密成密文（用密钥把这个消息加密成密文），然后在网络上进行传输，在网络的节点上，有人抓窥，它就看不懂了，但是所有的加密算法都是可以被破解的（包括md5），但是加密算法安不安全，是要看破解要花费的时间（比如说，破解这个算法需要100年才可以破解，以现在的最好的计算机去算，需要100年才破解，我们就认为这个加密算法就是安全的），服务端server收到这个密文之后，要解密，也需要密钥啊，对称加密就是加密方和解密方用的都是同一个密钥。

服务端是怎么知道这个密钥的呢？
不管怎么样，都不能把密钥在网络上传输啊！（和把你家的钥匙放在大马路上没什么区别啊，谁捡到，都可以开你家的门啊）
用对称加密在C/S上进行数据加密的话，密钥是个大问题。
对称加密的加密和解密比较简单，所以加解密效率比较高，有：AES加解密算法。

2、非对称加密算法

顾名思义，加密和解密用的就不是同一把钥匙了。
有这么一个特点：
一个公钥的加密，只能有一个对应的私钥才可以解出来

一个私钥的加密，只有一个对应的公钥才可以解出来。

公钥和私钥是一一配对的。
GitHub或者Gitee：远程代码仓库，我们要推代码上去，要先去配置一个公钥，在我们本地机器上生成一对公私钥，然后把公钥配置到我们的个人GitHub代码仓库上，所以整个通信的加密采用的是非对称加密
一个公钥的加密只能由一个对应的私钥解密。
一个私钥的加密只能由一个对应的公钥解密。

用私钥加密的东西，一般可以以数字证书的方式提供， 大家就可以下载这个证书，相当于是一个身份认证，和学历一样。银行一般会用私钥加密一个信息摘要，得到一个数字证书，我们个人需要登录一些银行的一些关键性的网站，需要下载这个数字证书，数字证书就可以验证你在银行的身份，私钥一般不提供给外界，给外界提供的都是公钥public（谁都能看到），如果公钥可以解出来这个证书的内容，私钥加密的只有公钥才可以解密，证明这个公私钥是一对的，这个公钥是银行给你的。
比如说，有欺诈网站给你提供一个公钥，如果你把这个公钥当做银行的公钥去加密的东西直接发出去，别人在网络上截取这个信息，因为你是用他们提供的公钥加密的，他们用他们的私钥就可以解密了，然后得到你的账户密码信息，就可以对你的账户进行操作了。
非对称加密复杂，效率慢，但是非常安全：有RSA加解密算法
把这个引入到聊天服务器的客户端和服务端的通信上
服务端有RSA的私钥，然后在客户端代码中集成了RSA的公钥，这样安装完客户端，就有RSA的公钥了。
然后客户端在进行通信的时候：
1、connect连接服务器
2、连接上服务端之后，就要进行交换（如果是客户端直接用RSA的公钥加密，发送到服务端后服务端进行RSA解密，在实现上是没有问题的，但是RSA的加解密是非常复杂的，导致效率低，如果用纯RSA的公钥私钥进行加解密，会造成整个通信效率的降低），
所以我们一般使用的是非对称加密和对称加密进行混合使用，把它们各自的优点结合起来：
connect先连接成功，然后客户端和服务器交换密钥：
客户端的RSA的公钥先把AES对称加密算法的密钥key加密成密文，通过网络发送出去，谁要是在网络上把这条信息截获了，是看不出来的，因为这是用RSA公钥加密的密文，只有它的服务端的对应的RSA私钥才可以进行解密，RSA私钥是在服务端，不会在网络上传输的，所以，截获者要把这个被128位RSA非对称加密的信息截获，是需要好几十年才可以破解的（以现在的计算机的计算能力来说），所以，我们说这是非常安全的。
密文传输到服务端后，服务端用私钥RSA从这个密文里面得到客户端想给服务端的这个AES密钥key，现在服务端就可以拿它的RSA私钥既做解密又可以做验证了，如果解密失败，证明客户端给服务端发送的消息并不是用服务端的公钥加密得到的，肯定是有人随意攻击，有人模拟发包给服务端发送消息，服务端此时就可以直接拒绝掉了。
只有客户端拥有了服务端RSA对应的私钥的公钥，才能加密成服务端才可以解密的密文。服务端如果解密成功，就给客户端回复：OK。表示两个人交换了AES的加解密的密钥key交换成功了。然后后续在进行通信的时候：客户端就可以使用简单的AES的密钥key把原始的明文加密一下，得到密文，通过网络发送到服务端，服务端找见这个用户对应的刚开始连接时交换过来的AES密钥key，把密文解密就得到明文了，这样通信的效率就高了，而且又非常的安全。

每个客户端都生成不同的密钥key，我们可以在数据库里面记录下来，每一个账户id对应的通信的密钥key是什么，当有客户端发送数据来，就可以在数据库中找到这个客户端对应的一个密钥key。
如果全部是用密文，服务端就找不到这个客户端通信对应的密钥key了，所以我们在实际上传输的时候，userid（用户的id号，或者是客户端设备的唯一标识，mac地址，可以唯一标识客户端的信息都可以）可以设置成明文，然后把messagebody（信息，电话，密码等重要的信息）打包设置成密文，然后一起发过去。服务端就根据userid得到和客户端专门通信的AES密钥key了。