这是我参与「第五届青训营」伴学笔记创作活动的第13天

加密传输

加密类型

以AES加密算法为代表

传输双方拥有共同的密钥, 使用同一密钥对文件内容进行加密即可, 优点是加解密速度快, 效率高, 缺点是安全性不高, 很难保证消息来源的可靠性以及消息的准确性.

以RSA加密算法为代表

即传输双方设置公钥和私钥, 公钥用于对信息的加密, 私钥用于解密. 公钥对外暴露, 而私钥只有自己可见.

非对称加密降低了私有密钥泄露的风险, 解决了保密性的问题, 并且较大程度上保证了消息来源的可靠性以及消息的准确性

但是非对称加密存在中间人攻击的风险, 即第三方中间人可以截取发送端发出的信息, 对其进行篡改后使用公钥加密, 继而发送给接受端. 或者在发送端和接收端交换公钥时, 替换公钥.

并且非对称加密的性能相较于对称加密差了很多.

数字证书和数字签名可以解决非对称加密中, 公钥被替换的风险.

现实中存在发放数字证书的机构CA, 服务端可以带着公钥以及其他信息向CA申请数字证书, CA拿到信息后, 会使用单向加密算法(例如MD5)将其加密为摘要, 并使用CA的私钥对摘要进行加密, 生成数字签名. 最后CA将申请信息和数字签名整合为数字证书.

服务器在拿到数字证书后, 会将其发送给客户端, 客户端使用CA的公钥对其解密, 检验证书的合法性, 证书合法后, 客户端会对服务端发来的公钥以及其他信息, 按照CA的加密方式重新生成一份摘要, 并和对证书解密得到的摘要进行对比, 内容一致说明内容违背篡改.

至此, 客户端便安全地拿到了服务端的公钥, 即可以与服务端进行非对称加密通信.

首先客户端通过发送Client Hello报文开始SSL通信, 包含客户端支持的SSL版本, 加密组件列表(使用的加密算法以及密钥长度等), 服务器端若是可以进行SSL通信, 会以Server Hello报文回应, 同样在报文中包含与客户端一致的加密组件(服务端和客户端共同拥有的加密组件)
服务器发送数字证书, 接着发送server hello Done报文通知客户端SSL握手协商结束.
SSL第一次握手结束后, 客户端以Client Key Exchange报文作为回应, 包含一种Pre-master secret的随机密码串, 并使用上一步协商中, 从服务端证书中获得的公钥进行加密, 接着客户端发送Change Cipher Spec报文, 提示服务器, 后续将采用Pre-master secret密钥加密. 最后客户端发送Finished报文, 包含至今全部报文的整体校验值, 服务端根据该报文的解密结果判定是否握手协商成功
服务器端同样发送Change Cipher Spec和Finished报文.
客户端和服务端的Finished报文交换完毕之后, SSL连接建立完成, 从此处开始进行应用层协议的通信, 即发送HTTP请求.
最后由客户端断开连接, 断开连接时, 发送cloes_notify报文, 之后发送TCP FIN报文来关闭TCP通信.

另外, 应用层在发送数据时, 会额外附加MAC报文摘要, 探知报文是否遭到篡改, 保证报文的完整性