美国德州大学奥斯汀分校和斯坦福大学的研究人员 公布了他们的研究成果，研究表明大众认为高度安全的SSL库，在非浏览器应用使用的过程中存在严重的漏洞。这些需要高度安全保障的关键性服务包括银行服务、电子商务用户的SDK及关键程度稍低一些的软件服务，如云存储服务和通讯服务。这篇文章指出了以下问题：对抗测试表现不佳、SSL库本身存在漏洞，程序调用SSL库的过程中存在漏洞，查找深藏在堆栈中的漏洞复杂，以及开发人员普遍禁用证书验证的不安全的实践。
该研究团队所使用的威胁模型是动态的中间人攻击模型（MITM）。模拟中间人使用了三份证书进行攻击：(1)一份自签发的证书，证书的通用名（common name）与客户端尝试连接的主机的通用名相同，(2)一份使用错误通用名的自签发证书， (3)由可信的认证授权机构AllYourSSLAreBelongTo.us签发的一份有效证书。中间人集中对信任验证链和主机名验证进行攻击，未对证书吊销或是X.509的扩展内容进行测试。可以在 这里下载到威胁模型模拟的代码。
这篇文章向开发人员分享了使用SSL库的相关实现细节：OpenSSL、JSSE以及数据传输库：Apache HttpClient、Weberknecht、cURL、PHP的fsockopen方法，cURL 绑定，以及Python的urllib、urllib2和httplib。多数SSL库在进行证书验证的时候，向客户端开放了一些主机名验证的选项，但它们被很多开发人员忽略了。比如，JSSE底层的API，SSLSocketFactory类，如果未指定算法，那么会自动关闭主机名验证。多数客户端，包括Apache HttpClient，均未在程序中另行实现主机名验证功能，使其存在安全风险。
下面是SSLSocketFactory中进行证书验证的代码片段，证明这种问题是普遍存在的。
private void checkTrusted(X509Certificate[] chain, String authType,
Socket socket, boolean isClient)
throws CertificateException {
...
// check end point identity
String identityAlg = sslSocket.getSSLParameters().
getEndpointIdentificationAlgorithm();
if (identityAlg != null && identityAlg.length != 0)
{
String hostname = session.getPeerHost();
checkIdentity(hostname, chain[0], identityAlg);
}
}
使用这些库的非浏览器应用，其堆栈中都会隐藏着这类漏洞。如需获得客户端正确调用SSL和数据传输库的具体建议，请参考 本文作者提供的FAQ。
文章的后半部分主要讨论了各种模拟攻击的研究成果，它们是云客户端的API（AWS EC2和ELB的API工具）、应用程序（大通银行的移动应用、Rackspace的IOS应用、Groupon的安卓应用和TextSecure）、SDK（亚马逊灵活支付服务SDK，PayPal支付标准SDK）、Web服务中间件（Apache Axis、Axis2、CodeHaus XFire和Pusher）以及移动广告应用（AdMob）。文章总结了给应用开发人员的一些建议：
切记进行模糊测试（黑盒测试，如果有必要）和对抗测试，去观察在使用异常SSL证书时，应用的具体行为。漏洞一般很微小，但是通常带来的问题却不小。在我们的许多研究案例中，很明显的现象是，除了目标服务器的证书外，开发人员没有使用别的证书进行过测试。当使用AllYourSSLAreBelongTo.us签发的证书替代亚马逊、PayPal或大通银行的证书时，这些程序立刻建立了SSL连接，并将秘密拱手相让。这些问题，应当在测试阶段暴露出来。
切勿在对自签发和（或者）不可信证书进行测试的时候，改动程序代码并关闭证书验证。因为我们发现，在研究中，开发人员常常忘记在软件的正式版本中撤销这些改动。作为替代的办法，我们可以创建一个不可信的CA公钥，并将其存放在一同创建的临时证书库中。测试代码的时候，如需使用自签发或是不可信证书时，可以使用刚刚创建的证书库来替代你的可信证书库。
切勿寄希望于SSL库的默认设置保证SSL连接的安全。同一库的不同版本的默认设置都有可能不同，更别说不同的库了——比如，cURL 7.10之前的版本，默认不会验证证书，但是7.10及以后的版本则会进行验证。因此，为建立安全的连接，往往需要显式地设置这些选项，而不能使用默认的设置。
下面是对SSL库开发人员的建议：
切记在开发SSL库时，API的语义要更加明确和详细。在许多情况下，应用开发人员明显不明白参数和大量选项的作用。比如，亚马逊灵活支付服务（Amazon Flexible Payments Services）和PayPal支付标准（PayPal Payments Standard）的PHP库尝试在cURL中启用主机名验证，但是，偶尔会因为覆盖了正确的缺省值而最后禁用了验证（详见7.1和7.2节）。这说明，即使默认值足够安全，也不能够保证安全。Lynx尝试对自签发的证书进行检查，但是因为误解了GnuTLS证书验证功能返回值的意思，导致这个检查实际上从未执行过（详见7.4节）。
规范化SSL库的API的简要的语义描述，以及严格验证应用程序与库之间的“契约”，，这些将是未来研究中的一个有意思的课题，那时可能需要编程语言的支持。
切勿将管理SSL连接的责任扔给应用。现有SSL库为更高层的软件调用提供了很多选项。丰富的选择使其充满了危险。应用开发人员并没有意识到，他们必须明确的选择特定的选项，才能进行证书验证。因此，SSL库应当尽可能地使用安全的默认值。此外，SSL库不应该在未启用重要功能（如主机名验证）时保持沉默，就像JSSE一样，当算法字段为Null或留空的时候无任何提示（详见4.1节）。相反，SSL库应当抛出一个异常或是通过其他方式通知应用。
务必设计简洁、一致的错误报告接口。SSL库如OpenSSL和GnuTLS，在报告错误的时候，有时会通过函数的返回值，有时会通过传入的标记参数返回。混乱的报告接口搞得开发人员晕头转向，以至于在应用排错的时候会无意中漏掉了一些问题。
部分软件的开发商已经对文中指出的问题进行处理，并且将处理结果反馈给了研究人员，详见 FAQ。为了便于开发人员处理这些SSL的问题， ISec合作伙伴已经就本文内容，发布了三款漏洞测试的工具。但是这些工具的使用，并不能代替作者所建议的对SSL实现方法的完全审查或是对抗测试。
查看英文原文： Researchers Expose SSL Vulnerabilities in Libraries and Their Usage in Popular Non-Browser Services
感谢 马国耀对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至 [email protected]。也欢迎大家通过新浪微博（ @InfoQ）或者腾讯微博（ @InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。
