「这是我参与2022首次更文挑战的第1天，活动详情查看：2022首次更文挑战」
这次公司需要进行Socket TLS认证，发现之前对于传输安全理解还是不够深入，这里梳理一下SSL/TLS的传输原理。
回顾之前的安全传输理解：
准备：服务器非对称加密公钥 对称加密密钥
- 使用到的技术：hash（散列函数）摘要算法、非对称加密、对称加密
- 客户端将明文数据通过Hash获取摘要信息
- 将摘要信息通过非对称加密（RSA、DH（迪菲））得出密文
- 将摘要加密后的密文发送到服务器
- 将明文进行对称加密（AES等）发送给服务器
- 服务器先将明文进行约定的hash 算法得出摘要
- 将客户端发送到加密后到摘要密文使用服务器私钥解密得到未加密的摘要信息
- 对比服务器将明文进行摘要算法的摘要信息和解密后获得的摘要信息对比
- 对比信息相等表明信息未被串改，开始使用客户端传输的明文信息
至此，一次传输完成
反思，这样传输是否足够安全？如果不安全有哪些安全隐患？怎么排除隐患？
这样的传输的前提是得到的公钥确保正确可信，像一般的传输加密都会将公钥放在APP内，更进一步的进行多次加密或者分拆保存加密，这样确实能在一定程度上保证传输的信息安全，但是仍有漏洞，比如反编译、工程逆向，还是可以获取到公钥信息，只是代价稍大，一般公司APP都不考虑这些，体量和成本不成正比。于是有了下面我介绍我所理解的SSL/TLS协议（TLS是SSL的升级版）
SSL/TLS协议：是一种被业界广泛使用的安全传输协议。
下面以单向认证为例：
准备工作：获取CA证书（一种本大众信任的签名机构签发的证书）
获取CA证书流程：
- 服务器生成一对非对称加密公私钥 server.key、server.pub、域名信息、其他公司/个人信息
- CA机构将服务器提供的一些明文信息进行hash摘要处理
- CA机构使用CA.key(CA机构的私钥)将摘要信息加密生成签名信息S
- CA机构将服务器提供信息、签名信息S、服务器公钥做成CA证书server.crt
- 还有一个证书ca.crt这个证书一般是已经内嵌到设备上了，如果没有需要给到客户端
上面的server.crt即为常用的CA证书
开始TLS通讯
借网友的图：
- 客户端发送随机数CR、支持的加密协议（一个列表，按优先级排序）、TLS版本信息发送给服务器
- 服务器接收消息后，产生随机数SR外加server.crt、选择的加密协议(从客户端发送的列表中选择)发送给客户端
- 客户端使用本地的CA.crt去解密服务器的server.crt，如果证书没问题，则可将签名信息S解密获取到摘要信息，在将server.crt中的明文信息使用相同的摘要处理，对比两次摘要信息，如果信息相等，说明证书可信，信息无误，获取server.crt证书中的服务器公钥server.pub
- 客户端再次产生随机字符串CR2+SR+CR=M1使用server.pub进行加密，发送给服务器（开始协商通讯密钥）
- 发送消息给服务器，开始使用这个密钥M1通讯
- 在这时客户端还会将之前的明文信息使用刚才产生的密钥M1进行加密,获得加密信息V1,发送给服务器进行加密验证
- 服务器收到密钥M1的密文，使用server.key进行解密获取通讯密钥M1
- 收到开始使用密钥通讯指令，收到验证信息V1，使用密钥M1验证V1，如果能正常解密则该密钥正常
- 发送确认使用该密钥信息给客户端
- 将之前的明文使用M1加密，获得密文V2，发送给客户端
- 客户端收到确认使用该密钥信息，再收到验证密文信息V2，使用密钥M1解密，解密正常。
- 开始使用M1开始安全通讯
至此一个完成的TLS通讯握手就结束了，可以开始正常放心通讯了
当然，如果有兴趣的朋友还可以继续深入，比如加密算法选择、协商密钥产生机制、TLS是否足够安全？
