笔记：

Web技术（三）：TLS 1.2/1.3 加密原理(AES-GCM + ECDHE-ECDSA/RSA)_流云IoT的博客-CSDN博客_tls加密算法

一 ：TLS定义的key交换方法如下表格：

二 服务器选择算法原则

服务器在选择算法时，会有优先级，是以客户端提供的的为最优，还是服务器端配置的为最优。

所谓的客户端最优，就是服务端根据客户端提供的加密套件，从上到下，看是否有本地（服务端）支持的，有的话则使用。

所谓服务器端最优，就是服务器端根据自身配置的加密套件顺序，一个个在client hello中找，找到了就使用。

其次

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

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

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

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

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

1. 由于ECDH加密套件默认表明了握手需要ECC证书（即ECC证书的公钥充当握手中server key exchange中的公钥，证书的私钥同样也是握手过程中的私钥，握手过程不需要server key exchange）
2. 第二部分_RSA或者_ECDSA表明的是想要的服务器证书签名类型。
3. 比如说服务器选择了ECDH_RSA加密套件，但是发送的证书却是ECDSA签名的证书，虽然说证书签名类型不影响整个握手，但是对于校验严格的客户端，这种情况可能会导致客户端断开链接。详见 RFC：https://tools.ietf.org/html/rfc4492#section-2.3
4. 像ECDHE-RSA，表示证书必须是RSA签名的，证书里的公钥必须是RSA的公钥，可以用来给serve key exchange的内容进行RSA签名用。

三  加密套件格式说明：

TLS 使用到的认证加密算法、完整性校验算法、密钥协商算法、数字签名算法等，这些算法都是要配合使用的（单独使用无法保证信息安全传输），各类算法相互组合可以形成一套套加密方案。TLS 握手阶段，服务器与客户端需要协商都使用哪些加密算法，如果逐个协商显然效率较低，TLS将可用的加密算法组合为一个个密码套件，服务器与客户端只要协商一种密码套件，就确定了整个加密方案中用到的所有加密算法，能提高通信效率。

TLS密码套件主要由密钥交换方法、身份验证方法、密码定义（包括对称加密算法、安全强度、认证与分组模式）以及可选的MAC或PRF算法组合而成（如果没有采用AEAD认证加密方案，则需提供MAC消息认证码，若采用AEAD（AES-CCM、AES-GCM、ChaCha20-Poly1305）则不再需要单独指定MAC，因为AEAD可以附带产生MAC码），图示如下：
 

这里面的身份验证应该是对公钥证书的签名要求，详细见第四节。

PRF(Pseudo Random Function)

指的是伪随机函数，不管是对称密钥非对称密钥的生成都离不开随机数，随机数质量的好坏决定了加密法的安全强度，真正的随机数很难获取，更常用的是通过算法实现的伪随机数。

1. 从TLS 1.2起，所有的算法套件都需要明确指定它们的PRF，一般伪随机函数PRF由一个密钥secret、一颗种子seed、一个唯一标签label 构成（引入种子和标签便于每次生成不同的伪随机数，而密钥secret可以重用）。
2. PRF的生成主要使用了Hash算法，所以密码套件中的PRF字段是以散列函数强度来描述的（比如SHA-256）

AEAD算法： 

AEAD算法	AEAD方法	优缺点对比	使用场景举例
AES-CCM (AES-CTR + CBC-MAC)	Encrypt-and-MAC	受限于CBC模式特性，不能充分发挥并行处理的优势	TLS 1.2/1.3、IPsec、WLAN WPA2、BT LE等
AES-GCM (AES-CTR + Galois-MAC)	Encrypt-then-MAC	可以充分利用并行处理提高效率	TLS 1.2/1.3、IPsec、WLAN WPA3、SSH等

四：​​​​​​​RFC4492定义了每种交换算法需要的证书类型

RFC 4492 - Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)

定义了每种交换算法需要的证书类型

          Key Exchange Algorithm  Server Certificate Type
          ----------------------  -----------------------

          ECDH_ECDSA              Certificate MUST contain an
                                  ECDH-capable public key.  It
                                  MUST be signed with ECDSA.

          ECDHE_ECDSA             Certificate MUST contain an
                                  ECDSA-capable public key.  It
                                  MUST be signed with ECDSA.

          ECDH_RSA                Certificate MUST contain an
                                  ECDH-capable public key.  It
                                  MUST be signed with RSA.

          ECDHE_RSA               Certificate MUST contain an
                                  RSA public key authorized for
                                  use in digital signatures.  It
                                  MUST be signed with RSA.

                    Table 3: Server Certificate Types    
  The ECDH_RSA mechanism requires a server to acquire an ECC
   certificate, but the certificate issuer can still use an existing RSA
   key for signing.  This eliminates the need to update the keys of
   trusted certification authorities accepted by TLS clients. 
 The  ECDH_ECDSA mechanism requires ECC keys for the server as well as the
   certification authority and is best suited for constrained devices
   unable to support RSA.