静态密钥文件中的位数并不等于 OpenVPN 加密强度
静态密钥文件中的位数衡量的是保存下来的材料,而不是加密强度。请分别读取文件开头的横幅、配置文件里的模式和协商出的加密算法。
扫描器或同事指着 OpenVPN 静态密钥文件里印出的位数,问隧道为什么不使用这个尺寸的加密。这个问题听起来合理,但答案不是一个数字:横幅统计的是保存下来的密钥材料,而加密只消耗其密钥长度所需的那一部分。把这个总数当成强度设置,只会带来什么都不改变的改动。该格式的设计本意,就是容纳比任何单一算法所用的都更多的材料。
这里混着两个问题:文件保存了多少密钥材料,以及协商出的加密有多强。只有第二个才描述隧道。
横幅里的数字到底在统计什么
该容器把加密材料与 HMAC 材料序列化为各自独立的结构,而双向形态保存两套这样的结构,好让每个方向携带自己的密钥。写入代码根据序列化结构的数量、它们的大小以及每字节八位来推导出印出的数字。这是关于存储的算术,而不是断言某一种加密会消耗每一个保存下来的字节。文件头还固定了加密材料的最大配额,以免库的变动悄然改变格式的尺寸。
把它与证书密钥相比,那里的位数确实描述一个对象的大小。4,096 位的 RSA 密钥与横幅写着 4,096 位的密钥文件是两种不同的产物、承担不同的任务,把它们当作同一个旋钮上的两项设置,会得出糟糕的结论。
一个文件里的两套密钥
文件的每一半都提供加密与认证材料,因为预共享密钥模式正是用这些彼此独立的部件来保护两个方向的报文。启用的加密只使用其密钥长度所需的字节,摘要则使用自己的输出长度,因此可用的强度来自选项,而不是文件的长度。延长十六进制数据块,并不会要求已配置的算法多消耗一些。把注释改成一个更大的数字,改变的东西更少。
如果你真正想要的是更长的密钥,该改的设置是加密算法或摘要,生成器会按所选算法的需要产出。
读懂配置文件,就知道自己用的是哪种模式
同一种文件格式承担两种相当不同的任务,只有配置文件才说明你手上是哪一种。旧式的 secret 行让该文件成为隧道唯一的密钥材料,而 tls-auth 或 tls-crypt 则让它与证书一起构成控制通道的保护。无论这个块看起来多相似,两种用途都不会把它变成客户端的证书私钥。生成替代文件之前,先确定选项与版本,并使用有文档记录的生成器,而不是追加字符。
这一区分也决定了对泄露的应对。泄露的 tls-auth 密钥不会暴露会话密钥,但会让攻击者注入控制通道流量,因此仍然需要更换。泄露的 secret 密钥更糟,因为它正是保护数据本身的材料。
安全评审应当记录什么
把三件事分开记录:协商出的数据通道保护、控制通道保护,以及对端如何认证。像 data-ciphers AES-256-GCM 这样的行只描述了第一项,而停在那里的报告无法回答控制通道到底有没有受到保护。静态密钥文件在与 tls-auth 或 tls-crypt 一起使用时属于第二类,不使用时则两类都不属于。把类别混为一谈的评审者,明明想要更强的加密,却会去要求更大的密钥文件。
如果文件已经泄露,就轮换它,并通过批准的渠道重新分发。给已泄露的秘密追加字符不是轮换,而且会让暴露的材料继续有效。
把轮换记录与它所属的配置文件放在一起。下一次评审会问 哪把密钥保护了哪一段时间,而横幅不会回答这一点。