在 SSL 中,客户端连接并发送它支持的密码列表;然后服务器选择它也支持的密码之一,并且该密码用于连接。只有当连接建立(“握手”完成)时,HTTP 才会发挥作用。
在您的设置中,这意味着您应该配置您的 SSL 服务器以接受各种密码,但优先使用具有 128 位或更多位私钥的密码。因此,只有当客户端和服务器都不支持 128 位或更多的密码时,才会选择小于 128 位的密码。然后,在该连接中发送的页面将被更改,具体取决于实际协商的密码。
对于这样的设置,您需要能够执行以下操作:
- 配置 SSL 服务器支持的密码列表;
- 在客户端和服务器都支持的密码列表中强制执行服务器首选项而不是客户端首选项;
- 从您的页面生成引擎(例如 PHP)中访问实际使用的密码。
在 Apache 的mod_ssl中,第 1 点似乎很简单(“SSLCipherSuite”指令),“环境变量”部分似乎表明 SSL 服务器愿意向页面生成引擎提供有关选择了什么密码的信息;特别是,SSL_CIPHER_USEKEYSIZE
变量看起来相当不错。因此第 3 点看起来也很简单。但是,我不确定这如何转化为 PHP 世界。
对于第 2 点,它有点困难。“SSLCipherSuite”的文档似乎告诉服务器,默认情况下,使用自己的偏好顺序,所以第 2 点也很容易,但这需要一些测试。
Now only remains a minor point, which is the status of 3DES. Nominally, it uses a 192-bit key. Any decent cryptographer or programmer would point out that out of those 192 bits, only 168 bits are used (the extra bits were supposed to act as parity check bits, but nobody bothers verifying those, they are just ignored). Now, some academics have also shown that the actual algorithm strength is lower, somewhat equivalent to a 112-bit key, at least when seen in the proper academic light. The NIST (the US federal institution which deals with such standards) has therefore issued a recommendation, that 3DES should be considered as offering "only 112 bits of security", and 112 is lower than 128.
当然,112 位在技术上仍然很不可行(并且应该至少保持 30 年,即使技术进步保持其繁忙的步伐),所以这对于任何实际情况都不是一个真正的问题,但是,如果您处于标准疯狂的心态并希望强制执行“真实”128 位,那么这是一个需要考虑的问题。