研究人员揭露 SSL 库及其在非浏览器服务方面的弱点

美国德州大学奥斯汀分校和斯坦福大学的研究人员公布了他们的研究成果，研究表明大众认为高度安全的 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 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。