BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Jeevak Kasarkod 关注 3 他的粉丝 ,译者 康锦龙 关注 0 他的粉丝 发布于 2012年12月5日. 估计阅读时间: 9 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

美国德州大学奥斯汀分校和斯坦福大学的研究人员公布了他们的研究成果,研究表明大众认为高度安全的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)关注我们,并与我们的编辑和其他读者朋友交流。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT