摘要

  • RFC 3268 没有重写 TLS 的协商流程，而是在原有套件列表中加入十二种 AES 组合：六类密钥交换/认证方式，各有 128 位和 256 位两种密钥。
  • AES-256 本身既不证明对端身份，也不带来前向保密；这些性质取决于握手方式及其实现。

AES 需要一个双方都能理解的入口

AES 被确定为标准，不等于 TLS 客户端和服务器已经能协商使用它。双方需要一种共同的方式来命名一整组参数。TLS 1.0 已有这个接口：客户端在 ClientHello 列出支持的密码套件，服务器从中选一个。RFC 2246 规定，一套组合包含密钥交换、批量加密和消息认证算法。

2002 年 6 月发布的 RFC 3268 沿用了这个框架。它增加了 CBC 模式 AES 和 HMAC-SHA-1，但不是一个笼统的“AES 选项”。规范列出六类握手组合：RSA；由 DSS 或 RSA 证书认证的静态 DH；分别由 DSS 或 RSA 签名的临时 DHE；以及匿名 DH。每类又配有 128 位或 256 位 AES 密钥，所以新增的是十二个套件标识。

套件各部分不能互相替代。RSA 密钥传输、经过认证的 DH 与匿名 DH 不会因为都使用 AES 就变成同一种安全属性。DHE 可以提供前向保密，但需要每次使用新的临时密钥、妥善销毁密钥，并有不泄露历史输出的随机数生成器。匿名 DH 不认证对端，因此容易受到中间人攻击，除非另有方法把双方绑定到同一条 TLS Finished 消息。密钥长度不回答这些问题。

AES 支持 128、192、256 位密钥，RFC 3268 只规定前两者中的 128 和 256 位，以避免套件数量继续膨胀。十二个套件全部使用 128 位分组；更长的密钥不意味着更大的分组。它们也共同使用 CBC 与 HMAC-SHA-1。“AES”只描述整个组合中的一项。

兼容性带来更大的选择表

RFC 3268 在引言中指出，当时的 DHE 套件主要是三重 DES，另有密钥长度不理想的出口版本。新增 AES 不必改变 ClientHello 或 TLS 1.0 的选择机制，但每个组合都要拥有自己的名称、编号、策略和实现。

注册表里出现一个编号，不证明软件已经支持或优先选择它，更不证明生产连接实际协商了它。后来 TLS 的发展把这一点变得更清楚：TLS 1.2 的许多套件仍把多个因素合在一起；TLS 1.3 则让套件标识描述 AEAD 算法与哈希，把密钥交换组和签名算法分开协商。RFC 3268 因而也是 TLS 决策边界演变的一段历史。

它留下的观察方法很实用：算法、密钥长度、认证、密钥交换和记录构造是不同维度。密码套件是经协商得出的组合；若只看名称里的一项，就会把部件误当成整条连接的安全结论。

来源