SSL/TLS学习-ECDHE

1、RSA算法缺陷

  上篇总结了TLS使用RSA握手,但是RSA秘钥协商算法的最大问题是不支持向前保密。因为客户端传递随机数(用于生成对称加密密钥的条件之一)给服务端时使用的是公钥加密的,服务端收到后,会使用私钥解密得到随机数。所以一旦服务端的私钥泄露了,过去被第三方截获的所有TLS通讯密文都会被破解。
  为了解决这一问题,于是就有了DH秘钥协商算法。
在这里插入图片描述

2、DH算法

DH算法的核心数学思想是离散对数离散+对数两个数学概念的组合。
指数运算
y = 2
对数运算
在这里插入图片描述
  其中x参数为对数,y参数是真数,函数曲线图这里就详细画出了。例如以2为底数 ,32的对数是5;64的对数是6。
  对数的取值是可以连续的,而离散的对数取值是不能连续的。离散对数是在对数运输的基础上加了 模运算就是取余操作C语言中取余符号位 % ,用mod表示。
  如果对于一个证书b和质数p的一个原根a可以找到一个唯一的指数i使得:
在这里插入图片描述
成立。那么指数 i 称为 b 的以 a 为底数的模 p 的离散对数。

可以看到,整个密钥协商过程中,小红和小明公开了 4 个信息:p、g、A、B,其中p、g 是算法的参数,A 和 B是公钥,⽽ a、b 是双⽅各⾃保管的私钥,⿊客⽆法获取这 2 个私钥,因此⿊客只能从公开的 p、g、A、B ⼊⼿,计算出离散对数(私钥)。
根据离散对数的原理,如果 p 是⼀个⼤数,在现有的计算机的计算能⼒是很难破解出 私钥 a、b的,破解不出私钥,也就⽆法计算出会话密钥,因此 DH 密钥交换是安全的。

根据离散对数的幂运算的交换律,可以推导出K1 = K2
在这里插入图片描述

3、ECDHE

  因为DH算法的计算效率问题,后面出现了ECDHE秘钥协商算法,目前大多数网站使用的正是ECDHE密钥协商算法。
  DHE算法,是DH算法的升级,即每次协商通信过程中,客户端和服务器双方私钥在每次秘钥交换通信时,都是随机生成的、临时的。这个方式也是DHE算法,E全称(ephemeral:临时性的)。
  ECDHE算法是在HDE算法的基础上利用ECC椭圆曲线特性,可以用更少的计算量计算出公钥,以及最终的会话秘钥。具体算法过程比复杂(后续有机会补充)这里就不细说了。

4、ECDHE握手过程

  ECDHE握手只是秘钥协商过改变了,握手过程还是4次握手:
在这里插入图片描述
  区别在于使用ECDHE,在TLS第4次握手钱,客户端就已经发送了加密的HTTP数据了,而RSA握手过程,必须完成TLS四次握手才能传输应用数据。

4.1、TLS第一次握手

  客户端⾸先会发⼀个「Client Hello」消息,消息⾥⾯有客户端使⽤的 TLS 版本号、⽀持的密码套件列表,以及⽣成的随机数(Client Random)。
在这里插入图片描述

4.2、TLS第二次握手

  服务端收到客户端的「打招呼」,同样也要回礼,会返回「Server Hello」消息,消息⾯有服务器确认的 TLS 版本号,也给出了⼀个随机数(Server Random),然后从客户端的密码套件列表选择了⼀个合适的密码套件。
在这里插入图片描述
密码套件含义与RSA密码套件解读一致

「 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384」
密钥协商算法使⽤ ECDHE;
签名算法使⽤ RSA;
握⼿后的通信使⽤ AES 对称算法,密钥⻓度 256 位,分组模式是 GCM;
摘要算法使⽤ SHA384;

  接着,服务端为了证明⾃⼰的身份,发送「Certificate」消息,会把证书也发给客户端。
在这里插入图片描述
  证书发送完毕之后发会发送Server Key Exchange消息
在这里插入图片描述

这段数据告诉客户端:

选择了名为 named_curve 的椭圆曲线,选好了椭圆曲线相当于椭圆曲线基点 G 也定好了,这些都会公开给客户端;
⽣成随机数作为服务端椭圆曲线的私钥,保留到本地;
根据基点 G 和私钥计算出服务端的椭圆曲线公钥,这个会公开给客户端。

为了保证这个椭圆曲线的公钥不被第三方篡改,服务端使用RSA签名算法给服务的的椭圆曲线公钥做签名。
  之后就是server hello done消息,服务端跟客户端表明:这些就是我提供的信息,打招呼完毕。
在这里插入图片描述
注意:TLS第二次握手报文包含的内容比较多。有时候一个报文包含所有载荷,有时各个载荷单独发送。
  ⾄此,TLS 两次握⼿就已经完成了,⽬前客户端和服务端通过明⽂共享了这⼏个信息:Client RandomServer Random使⽤的椭圆曲线椭圆曲线基点 G服务端椭圆曲线的公钥,这⼏个信息很重要,是后续⽣成会话密钥的材料。

4.3、TLS第三次握手

  客户端收到了服务端的证书后,⾃然要校验证书是否合法,如果证书合法,那么服务端的身份就是没问题的。校验证书到过程,会⾛证书链逐级验证,确认证书的真实性,再⽤证书的公钥验证签名,这样就能确认服务端的身份了,确认⽆误后,就可以继续往下⾛。(与RSA一致验证过程可以看RSA篇)。
  客户端会⽣成⼀个随机数作为客户端椭圆曲线的私钥,然后再根据服务端前⾯给的信息,⽣成客户端的椭圆曲线公钥,然后⽤「Client Key Exchange」消息发给服务端。
在这里插入图片描述
  ⾄此,双⽅都有对⽅的椭圆曲线公钥、⾃⼰的椭圆曲线私钥、椭圆曲线基点 G。于是,双⽅都就计算出点(x, y),其中 x 坐标值双⽅都是⼀样的,前⾯说 ECDHE 算法时候,说 x 是会话密钥,但实际应⽤中,x 还不是最终的会话密钥。
  最终的会话密钥,就是⽤「客户端随机数 + 服务端随机数 + xECDHE 算法算出的共享密钥) 」三个材料⽣成的。
  之后客户端会发送一个「Change Cipher Spec」消息,告诉服务端后续改⽤对称算法加密通信。
在这里插入图片描述
  接着,客户端会发「Encrypted Handshake Message」消息,把之前发送的数据做⼀个摘要,再⽤对称密钥加密⼀下,让服务端做个验证,验证下本次⽣成的对称密钥是否可以正常使⽤。
在这里插入图片描述

4.4、TLS第四次握手

  最后,服务端也会有⼀个同样的操作,发「Change Cipher Spec」和「Encrypted Handshake Message」消息,如果双⽅都验证加密和解密没问题,那么握⼿正式完成。于是,就可以正常收发加密的 HTTP 请求和响应了。

猜你喜欢

转载自blog.csdn.net/ZBraveHeart/article/details/124816764