gpt4 book ai didi

https安全性带给im消息加密的启发

转载 作者:撒哈拉 更新时间:2024-04-01 16:50:21 56 4
gpt4 key购买 nike

大家好,我是蓝胖子,在之前# MYSQL 是如何保证binlog 和redo log同时提交的?这篇文章里,我们可以从mysql的设计中学会如何让两个服务的调用逻辑达到最终一致性,这也是分布式事务实现方式之一。今天来看看我们能够从httpsd设计中得到哪些启发可以用于业务系统开发中.

https原理分析

首先,我们来看下https 涉及到的握手流程,在http的三次握手基础上,https还要进行tls的握手协议。在经过tls握手后,后续客户端和服务端发送的消息也就都是加密的了。我们着重要看的就是tls握手过程。tls协议目前主要现存两个版本,我们都来看看.

tls1.2

首先,来看下tls1.2 协议下的握手流程.

在了解程序逻辑究竟为何如此设计之前,要搞懂我们这样做的目的。https之所以要用tls,无非就是为了两个目的, 。

  • 第一个目的: 让客户端能够认证服务端的身份信息,防止访问不安全的钓鱼网站。
  • 第二个目的: 对服务器和客户端之间的消息进行加密,不再明文传输。

对于第一个目的,可以通过数字证书解决,CA 向服务器颁发一个证书,在一次tls握手中,服务器会向客户端发放自己的证书,客户端在得到证书后向CA验证证书的合法性,如果合法,说明服务端是经过认证的,可以信任.

验证的原理则是通过公私钥加密算法和摘要算法,CA有自己的私钥,同时CA会将自己的公钥公布出去,然后CA对服务器的证书内容进行摘要计算,再对摘要进行私钥加密,私钥加密的内容只有公钥才能解密,私钥加密的内容称为签名信息,这段签名信息同样也会包含在证书中.

客户端在得到服务端证书的时候,通过对签名信息进行解密,得到证书的摘要信息,这个时候再对证书的内容进行摘要计算,看计算结果是否和解密得到的摘要信息一致,如果证书内容没被篡改的话,相同摘要算法得到的摘要信息应该是一致.

对于第二个目的,则是可以通过加密算法,为了性能,会话加密将会采用对称加密算法,这里的关键是得到一个会话密钥,但是为了安全性,会话密钥又不能直接采用明文进行传输.

所以tls是这样做的,客户端首先会生成一个随机数A,并已明文传递给服务端,服务端也会生成一个随机数B,并且把它传递给客户端,同时还会把数字证书传给客户端。数字证书中包含了服务端的公钥信息,客户端在收到证书取出其中公钥后,会再次生成一个随机数,随机数被称作pre master key ,这个随机数会通过证书中的公钥进行加密,传递给服务端,服务端会用自己的私钥对其进行解密,因为公钥加密的信息只能私钥才能解密,所以在服务端私钥不会泄露的情况下,黑客即使截获了报文,依然不能知道pre master key的值.

接着,便是服务端和客户端用相同的计算密钥的算法,以客户端和服务端的随机数A,B和pre master key生成相同的会话密钥,用于后续的通信进行对称加密。整个过程如下图所示,可以看到密钥的产生过程经历两次RTT,才会开始进行后续的请求发送.

请求一来一回称为一次RTT 。

image.png

关于tls1.2的完整握手过程,我也总结一个流程图,方便大家参考, 。