SSL/TLS学习-ECDHE

1、RSA算法缺陷

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

2、DH算法

DH算法的核心数学思想是离散对数是离散+对数两个数学概念的组合。
指数运算

对数运算

  其中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 Random、Server Random 、使⽤的椭圆曲线、椭圆曲线基点 G、服务端椭圆曲线的公钥，这⼏个信息很重要，是后续⽣成会话密钥的材料。

4.3、TLS第三次握手

  客户端收到了服务端的证书后，⾃然要校验证书是否合法，如果证书合法，那么服务端的身份就是没问题的。校验证书到过程，会⾛证书链逐级验证，确认证书的真实性，再⽤证书的公钥验证签名，这样就能确认服务端的身份了，确认⽆误后，就可以继续往下⾛。（与RSA一致验证过程可以看RSA篇）。
  客户端会⽣成⼀个随机数作为客户端椭圆曲线的私钥，然后再根据服务端前⾯给的信息，⽣成客户端的椭圆曲线公钥，然后⽤「Client Key Exchange」消息发给服务端。

  ⾄此，双⽅都有对⽅的椭圆曲线公钥、⾃⼰的椭圆曲线私钥、椭圆曲线基点 G。于是，双⽅都就计算出点（x， y），其中 x 坐标值双⽅都是⼀样的，前⾯说 ECDHE 算法时候，说 x 是会话密钥，但实际应⽤中，x 还不是最终的会话密钥。
  最终的会话密钥，就是⽤「客户端随机数 + 服务端随机数 + x（ECDHE 算法算出的共享密钥） 」三个材料⽣成的。
  之后客户端会发送一个「Change Cipher Spec」消息，告诉服务端后续改⽤对称算法加密通信。

  接着，客户端会发「Encrypted Handshake Message」消息，把之前发送的数据做⼀个摘要，再⽤对称密钥加密⼀下，让服务端做个验证，验证下本次⽣成的对称密钥是否可以正常使⽤。

4.4、TLS第四次握手

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