近日，苹果向iOS用户推送了一个安全更新，指出在iOS系统中SSL/TLS安全连接存在严重的bug，但并没有给出更详细的说明。对此问题的解答已经出现在Hacker News的头条，我想大家都已经知道了这个漏洞，也不需要再胡乱猜测了。
　　以下是导致这个bug的一段代码：
static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx， bool isRsa， SSLBuffer signedParams，
uint8_t *signature， UInt16 signatureLen)
{
OSStatus        err;
...
if ((err = SSLHashSHA1.update(&hashCtx， &serverRandom)) != 0)
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx， &signedParams)) != 0)
goto fail;
goto fail;
if ((err = SSLHashSHA1.final(&hashCtx， &hashOut)) != 0)
goto fail;
...
fail:
SSLFreeBuffer(&signedHashes);
SSLFreeBuffer(&hashCtx);
return err;
}
　　注意其中有两个连续的go to fail语句，第一个会正确地在if判断为真时执行，但是第二个却在任意情况下都会执行，尽管它有着看似标准的语句缩进。于是当代码跳转至fail时，由于认证使用的final方法还未执行，而update方法执行成功，因此err会包含一个校验成功的信息，导致对签名的认证永远不会失败。
　　认证签名时将会检测ServerKeyExchange消息中的签名，它用于DHE和ECDHE加密套件（多种加密算法联合使用）在建立连接时获取会话密钥（ephemeral key，本次会话的临时密钥）。服务器告诉客户端：“这是给你的会话密钥和签名，通过我的证书，你可以确定密钥和签名是来自于我的。”而现在会话密钥和证书链之间的关联已经断裂，所有曾经安全的认证都不再有效。这意味着，服务器可以向客户端发送正确的证书链，但在连接握手的过程中使用错误的私钥进行签名甚至干脆不签名，因为我们无法确认这个服务器是否持有对应此证书的正确的私钥。
　　这个Bug出现在SecureTransport的代码中，它将影响iOS的某个早期版本直到7.0.6（其中7.0.4我已经确认过），同时也会影响OS X系统（在10.9.1上已经得到确认）。所有使用了SecureTransport的地方都会被波及到，也等于是绝大部分苹果系统上的软件。Chrome和Firefox在SSL/TLS连接中使用的NSS，因此得以幸免。然而如果你的软件更新程序使用了SecureTransport，那么前面的讨论都不能说明什么了。（译注：更新程序可能连接到仿冒主机。）
　　对此我构建了一个简单的测试网站：https://www.imperialviolet.org:1266。注意端口号（1226是这个漏洞在CVE里的编号），443端口运行着一个正常的网站，而1226端口的网站将会发送使用错误私钥签名的证书。如果你使用https连接去访问，能够重现这个bug。
　　即使证书链是正确的，由于它和连接握手之间的关联已经被破坏，我认为任何形式的证书锁定都无法阻止这种错误的认证。同时，这个bug不仅仅影响使用DHE或者ECDHE加密套件的网站，因为攻击者可以自行选择合适的加密套件。
　　在TLS 1.2的针对ServerKeyExchange消息的认证是使用的另一个方法，因此没有受到影响。但仍然有上面提到的问题，攻击者可以选择任何客户端能够使用的版本。当然如果客户端仅支持TLS 1.2，那完全没有问题了。客户端也可以只使用明文-RSA加密套件，那么不存在ServerKeyExchange消息，同样起到了防范的效果。（当然在这两种方法中，前一种更加可取。）
　　根据我的测试发现，iOS 7.0.6已经修复了这个问题，但是在OS X 10.9.1中仍然存在。（补充：好像这个bug在OS X系统中是在10.9版引入的，但是iOS6的某些版本中早已出现了。iOS 6.1.6昨天修复了此bug。）