TLS加密套件之密钥交换

套件组成

TLS是固定格式，一般在ng配置的时候是不需要配置TLS_这一部分的，直接从密钥交换开始算。

第一部分是密钥交换算法，常见的有DH、DHE、ECDHE等，目前支持前向加密的只有ECDHE和DHE算法，很多安全扫描里面提到的不支持AEAD就是在说这个套件。

DH 算法：

DH 交换密钥时就只有客户端的公钥是变化，而服务端公钥是不变的，那么随着时间延长，黑客就会截获海量的密钥协商过程的数据，因为密钥协商的过程有些数据是公开的，黑客就可以依据这些数据暴力破解出服务器的私钥，然后就可以计算出会话密钥了，于是之前截获的加密数据会被破解

DHE 算法

既然固定一方的私钥有被破解的风险，那么干脆就让双方的私钥在每次密钥交换通信时，都是随机生成的、临时的，这个方式也就是 DHE 算法，E 全称是 ephemeral（临时性的）。

所以，即使有个牛逼的黑客破解了某一次通信过程的私钥，其他通信过程的私钥仍然是安全的，因为每个通信过程的私钥都是没有任何关系的，都是独立的，这样就保证了「前向安全」。

ECDHE 算法

DHE 算法由于计算性能不佳，因为需要做大量的乘法，为了提升 DHE 算法的性能，所以就出现了现在广泛用于密钥交换算法 —— ECDHE 算法。

ECDHE 算法是在 DHE 算法的基础上利用了 ECC 椭圆曲线特性，可以用更少的计算量计算出公钥，以及最终的会话密钥。

因为加密套件的第二个部分是针对证书的要求，所以

当服务器配置ECC证书时，加密套件只能选择ECDSA_XXX或者ECDH_XXX。

当服务器配置RSA证书时，只能选择RSA_XXX或者ECDHE_RSA_XXX形式的加密套件。

(这里解释下原因：如果RSA证书，那么密钥交换方式也是RSA的，肯定可以。密钥交换模式是ECDHE的话，由于ECDHE的密钥交换过程无需证书的实质性参与，所以RSA证书也可以和ECDHE一起工作；ECDHE的密钥交换方式可以参考我的另一篇博客；交换过程主要是client和server按照协商好的椭圆曲线去生成会话密钥，无需使用证书)

如果加密套件选择ECDH_RSA或者ECDH_ECDSA时：

由于ECDH加密套件默认表明了握手需要ECC证书（即ECC证书的公钥充当握手中server key exchange中的公钥，证书的私钥同样也是握手过程中的私钥，握手过程不需要server key exchange）

第二部分_RSA或者_ECDSA表明的是想要的服务器证书签名类型。

比如说服务器选择了ECDH_RSA加密套件，但是发送的证书却是ECDSA签名的证书，虽然说证书签名类型不影响整个握手，但是对于校验严格的客户端，这种情况可能会导致客户端断开链接。详见 RFC：https://tools.ietf.org/html/rfc4492#section-2.3

像ECDHE-RSA，表示证书必须是RSA签名的，证书里的公钥必须是RSA的公钥，可以用来给serve key exchange的内容进行RSA签名用。