HTTPS通信的过程的三个随机数的作用

您所在的位置:网站首页 随机数生成网站 HTTPS通信的过程的三个随机数的作用

HTTPS通信的过程的三个随机数的作用

2023-06-30 10:15| 来源: 网络整理| 查看: 265

Https通信的过程:

在这里插入图片描述 现在我们来理清一下SSL建立的过程:

客户端通过发送Client Hello报文开始SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件(Cipher Suite)列表(所使用的加密算法及密钥长度等)。 注意:客户端还会附加一个随机数,这里记为A。

服务器可进行SSL通信时,会以Server Hello报文作为应答。和客户端一样,在报文中包含SSL版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。 注意:这里服务器同样会附加一个随机数,发给客户端,这里记为B。

之后服务器发送Certificate报文。报文中包含公开密钥证书。(具体的数字签名请看证书一节)

最后服务器发送Server Hello Done报文通知客户端,最初阶段的SSL握手协商部分结束。

SSL第一次握手结束后,客户端会对服务器发过来的证书进行验证,如果验证成功,解密取出证书中的公钥。(具体查看证书一节) 接着,客户端以Client Key Exchange报文作为回应。报文中包含通信加密中使用的一种被称为Pre-master secret的随机密码串。该报文使用从证书中解密获得的公钥进行加密(其实就是服务器的公钥)。

客户端继续发送Change Cipher Spec报文。用于告知服务端,客户端已经切换到之前协商好的加密套件(Cipher Suite)的状态,准备使用之前协商好的加密套件加密数据并传输了。

客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值(也就是HASH值),用来供服务器校验。

服务器接收到客户端的请求之后,使用私钥解密报文,把Pre-master secret取出来。接着,服务器同样发送Change Cipher Spec报文。

服务器同样发送Finished报文,用来供客户端校验。

服务器和客户端的Finished报文交换完毕之后,SSL连接就算建立完成。当然,通信会受到SSL的保护。从此处开始进行应用层协议的通信,即发送HTTP请求。

应用层协议通信,即发送HTTP响应。

最后由客户端断开连接。断开连接时,发送close_notify报文。上图做了一些省略,这步之后再发送TCP FIN报文来关闭与TCP的通信。

读到这里,你可能会对上面的一些细节产生很多疑惑,现在我们一个个来理清楚?

问题一

为什么最后客户端和服务端都要发送一个Finish报文?

上面已经提及,Finish报文是对至今全部报文的整体校验值(也就是HASH值)。当客户端把这个值通过得到的公钥进行加密的时候,服务器得到之后对其进行解密,然后再对全部报文进行一个HASH求值。如果这个值跟解密得到的值相等的话,那么说明客户端是可信赖的。 同样的,服务器发送这样的一个整体校验值,用来客户端验证服务器是否是真正要进行通信的那一个。 综上,这个Finish报文就是用来校验双方的身份的。

问题二 整个过程中产生的三个随机数有什么用呢? 还有,后面进行HTTP通信的时候,是用哪一个密钥进行加密,还有怎么保证报文的完整性。 对于客户端: 当其生成了Pre-master secret之后,会结合原来的A、B随机数,用DH算法计算出一个master secret,紧接着根据这个master secret推导出hash secret和session secret。

对于服务端: 当其解密获得了Pre-master secret之后,会结合原来的A、B随机数,用DH算法计算出一个master secret,紧接着根据这个master secret推导出hash secret和session secret。

在客户端和服务端的master secret是依据三个随机数推导出来的,它是不会在网络上传输的,只有双方知道,不会有第三者知道。同时,客户端推导出来的session secret和hash secret与服务端也是完全一样的。

那么现在双方如果开始使用对称算法加密来进行通讯,使用哪个作为共享的密钥呢?过程是这样子的:

双方使用对称加密算法进行加密,用hash secret对HTTP报文做一次运算生成一个MAC,附在HTTP报文的后面,然后用session-secret加密所有数据(HTTP+MAC),然后发送。

接收方则先用session-secret解密数据,然后得到HTTP+MAC,再用相同的算法计算出自己的MAC,如果两个MAC相等,证明数据没有被篡改。

MAC(Message Authentication Code)称为报文摘要,能够查知报文是否遭到篡改,从而保护报文的完整性。

问题三 为什么要使用三个随机数呢?

网友dog250是这么解释的:

"不管是客户端还是服务器,都需要随机数,这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的,因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。对于RSA密钥交换算法来说,pre-master secret本身就是一个随机数,再加上hello消息中的随机,三个随机数通过一个密钥导出器最终导出一个对称密钥。pre-master secret的存在在于SSL协议不信任每个主机都能产生完全随机的随机数,如果随机数不随机,那么pre-mastersecret就有可能被猜出来,那么仅适用pre-master secret作为密钥就不合适了,因此必须引入新的随机因素,那么客户端和服务器加上pre-master secret三个随机数一同生成的密钥就不容易被猜出了,一个伪随机可能完全不随机,可是是三个伪随机就十分接近随机了,每增加一个自由度,随机性增加的可不是一。"

注:我们在计算机所使用的随机数都是伪随机,而不是物理上所说的真正随机。

另外,黑客可能拦截了这样的一个加密的报文,他不对报文进行修改,而是不停的向报文的接受者发送重复的报文,以扰乱通信的建立。于是,就可以加这么一个随机数。只要任何一个通信方,接收到的报文中的随机数出现重复的情况,就可以知道有中间者对通信的过程进行了扰乱,可以立即中断通信。

问题四 如果黑客拦截了服务器把证书发送给客户端,并对证书进行恶意修改,会出现什么情况?

第一种情况,假如黑客只是单纯的修改数字证书中的内容,那么由于数字签名的存在,客户端会很容易的判断出报文是否被篡改。

第二种情况,黑客不仅修改了数字证书的内容,并且把数字签名替换掉了,由于黑客不可能知道CA的私钥,于是在客户端用CA的公钥进行解密的时候,解密之后得不到正确的信息,也很容易判断出报文是否被修改。

第三种情况,黑客恶意的从相同的第三方CA申请了一个数字证书。由于这个CA是真实存在的,所以客户端是可以用CA的公钥进行解密,得到了黑客提供的数字证书中的公钥。但是,由于数字证书在申请的时候,会绑定一个域名,当客户端比如说浏览器,检测到这个数字证书中的域名和我们现在网页访问的域名不一致,便会发出警告,此时我们也能得知数字证书被替换了。发出的警告如下: 在这里插入图片描述



【本文地址】


今日新闻


推荐新闻


CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3