The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software

论文笔记 SSL

作者：Martin Georgiev,Subodh Iyengar,Suman Jana,Rishita Anubhai,Dan Boneh,Vitaly Shmatikov

单位：The University of Texas at Austin,Stanford University

Abstract & Introduction

在许多要求高安全性的应用和库中，SSL都没能被很好的实施，使得其安全性下降，这之中的根本原因在于一些SSL的API设计非常糟糕，给了程序员许多令人困惑的设置和选项，从而使得程序员对许多参数、选项、返回值等等该如何设置产生了误解。论文主要研究了在一些无浏览器的软件中SSL的使用情况，并重点关注了客户端对服务器端的认证，对各类库错误使用SSL的情况进行了具体地列举，在最后也给出了一些意见与建议。

Overview of SSL

1. 威胁模型

一个活跃的中间人攻击者

• 攻击者无法获得合法服务器的私钥
• 攻击者无法控制任何CA
• 攻击者无法伪造证书

2. SSL证书认证

本文主要考虑以下2个方面：

• 证书链认证
• 主机名认证

SSL Abstractions

1. SSL Libraries

OpenSSL

• OpenSSL只提供证书链验证，主机名验证环节由应用自己，或一些data-transport包完成
• 证书链的验证可以通过回调函数或者一些设定参数（如"verify depth"和"verify mode"）进行自定义
• OpenSSL存在函数返回值上的混乱。如，在ssl_connect这一函数（用来建立握手）中，有一部分的错误是通过ssl_connect的返回值来表达的，而有一部分错误ssl_connect会返回OK，具体错误必须通过ssl_get_verify_result函数来获得，（这一点在GnuTL中也有相类似的体现）

JSSE

JSSE中有一个底层的API叫SSLSocketFactory，它会根据SSL客户端设定的不同而采用不同方式来进行主机名验证。
在这个API中有一个函数叫checkIdentity，是用来进行主机名验证的，该函数会通过参数algorithm，来决定采用HTTPS还是LDAP进行操作，如果参数algorithm为NULL或为空，则跳过该步骤，并且不产生任何的提示。
于是这就产生了一个问题，尽管在HttpsClient和HttpsURLConnection在创建SSL客户端时会要求调用SetHostnameVerification来设定algorithm参数，一些应用软件通过原始的SSLSocketFactory函数来创建SSL客户端时，algorithm参数默认是NULL，于是主机名验证就被静默跳过了，而这一点却没有在API的文档中提出，只在JSSE reference guide的中一个不起眼的位置看到关于这一点的提醒。

2. Data-transporter libraries

Apache HttpClient

• 使用了JSSE中的SSLSocketFactory来建立SSL连接
• 在描述HTTP(S)连接时，使用了HttpHost的数据结构

Weberknecht

• 使用了SSLSocketFactory，却没有自行进行主机名验证

cURL

• 参数类型混乱。如，VERIFYPEER参数是一个布尔值，而另一个与其非常相似的VERIFYHOST参数却是一个整数值（1是检查SSL证书中一个common name是否存在，2是不仅仅检查，并且验证这是否与提供的主机名相匹配）。即便开发者没有对这些参数的作用产生误读，但却很有可能把VERIFYHOST设置为TRUE，而这就会被程序理解为1，从而产生灾难性的后果。

PHP

• fsockopen函数不包含任何的证书检查功能，仅仅只是创建了一个可用于SSL连接的socket，却经常被开发者用来建立SSL连接
• PHP提供了cURL的默认设置来创建SSL连接，这个应该是安全的，但开发者经常错误地对cURL进行设置，覆盖了原有的默认值，从而破坏了证书认证过程。

Python

• urllib,urllib2和httplib可以连接SSL服务器，但并没有检查证书，尽管这一点在python文档中的urllib页面上被高亮指出，许多开发者依然在一些要求高安全性的应用中使用它们
• python也有ssl模块，但它仅仅只检查证书链，却不会对主机名进行检验，应用必须自行完成这一内容。而在python3中，ssl模块引入了match_hostname这一方法，但该方法必须被显式地调用才可以。

SSL in Non-browser Software

Cloud Client APIs：
各种云端服务，如将用户的数据储存到云端等

商业支付SDKs：
电子商务网站等，如PayPal和亚马逊快捷支付服务之间的通信，这些都是在服务器后端通过SSL通信完成的

Web-services Middleware

手机广告：
AdMob服务，显示的广告与app提供商的账户绑定（从而获得广告收入等），app提供商的站点与AdMob服务器的通信因为包含有提供商的凭据，所以必须用SSL保护。

Experimental Testbed

实施中间人攻击的服务器有两个：一个是由Java写成的，用的是JKS keystore来管理攻击者的证书和密钥；另一个则由C写成，使用OpenSSL来认证和管理密钥。

Fiddler被用作代理来获取连接请求。
如果出现了一个从未获得过的连接请求，则创建一个新的证书，其common name与所要求的名字相一致，并将它添加到仓库；否则就直接使用已有的。

中间人使用了几份不同的证书：
1. 一个自签名的证书，common name与host和client尝试传输的相同
2. 一个自签名的证书，但common name是不正确的
3. 一个合法的证书，由一个被信任的CA颁发给一个叫AllYourSSLAreBelongTo.us的域名

如果使用以上任何一个证书，能够与客户端成功建立起SSL连接，则需要进一步的分析与调查。

Misunderstanding the SSL API

1. Amazon Flexible Payments Service(PHP)

在src\Amazon\FOPS\Client.php文件中存在以下代码：

curl_setopt($curlHandle, CURLOPT_SSL_VERIFYPEER, true);
curl_setopt($curlHandle, CURLOPT_SSL_VERIFYHOST, true);
...
// Execute the request
...

正如之前提到的，CURLOPT_SSL_VERIFYHOST应该被设置为2，而不是true，后者会被程序解读为1，从而导致没有能够检查获得的名字与主机名是否匹配。

这样的问题在src\Amazon\IpnReturnUrlValidation\SignatureUtilsForOutbond.php也有暴露，使得URL认证功能被破坏。

2. PayPal Payments Standard and PayPal Invoicing(PHP)

一开始，PayPal Payments Standard SDK关闭了所有验证：

curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
...
// Execute the request
...

后来他们修正了这个问题，然而依然不对：

curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, true);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, true);
...
// Execute the request
...

这个问题就和上面一样，在PayPal Invoicing也有相类似的错误：

public function setHttpTrustAllConnection($trustAllConnection)
{
    $this->curlOpt[CURLOPT_SSL_VERIFYPEER] = !$trustAllConnection;
    $this->curlOpt[CURLOPT_SSL_VERIFYHOST] = !$trustAllConnection;
}

3.PayPal IPN in ZenCart

$curlOpts = array( ...
    CURLOPT_SSL_VERIFYPEER => FALSE,
    CURLOPT_SSL_VERIFYHOST => 2

虽然CURLOPT_SSL_VERIFYHOST设置对了，但在CURLOPT_SSL_VERIFYPEER被设置为FALSE的情况下，CURLOPT_SSL_VERIFYHOST不起到任何作用。

4. Lynx

ret = gnutls_certificate_verify_peers2(handle->gnutls_state,
    &tls_status);
if (ret < 0) {
    int flag_continue = 1;
    char *msg2;
    if (tls_status & GNUTLS_CERT_SIGNER_NOT_FOUND) {
        msg2 = gettext("no issuer is found");
    } else if (tls_status & GNUTLS_CERT_SIGNER_NOT_CA) {
        msg2 = gettext("issuer is not a CA");
    } else if (tls_status & GNUTLS_CERT_SIGNER_NOT_FOUND) {
        msg2 = gettext("the certificate has no known issuer");
    } else if (tls_status & GNUTLS_CERT_REVOKED) {
        msg2 = gettext("the certification has been revoked");
    } else {
        msg2 = gettext("teh certificate is not trusted");
    }
    ...
}

Lynx使用了GnuTLS来认证SSL证书，而GnuTLS中的一个函数，gnutls_certificate_verify_peers2的返回值情况非常复杂，从而造成了错误。
这个函数，如果是证书认证失败（如证书不完全或者没有找到证书），会通过设置tls_status的值来表明，并返回一个负值，但是对于一些特定的错误（如自签名证书等等），这个函数会返回0，从而导致这一段代码被跳过。
另外，尽管这一段代码对GNUTLS_CERT_SIGNER_NOT_FOUND进行了2遍一模一样的检查，但当该值是true时，没有一次检查能够被成功执行。

5. Apache HttpClient

Apache HttpClient3.1是目前使用最广泛的版本，而在这个版本中，它使用了JSSE的SSLSocketFactory，并且没有自行对主机名进行验证。
在后来的4.*版本中修复了这一问题，然而依然存在问题。

6. Trillian

• Trillian使用了OpenSSL，OpenSSL需要设置SSL_VERIFY_PEER位来让SSL_connect存在，并且当证书认证失败的时候显示错误信息，而Trillian并没有设置。
• OpenSSL通过调用SSL_get_verify_result来获得证书认证的状态，Trillian也没有调用

这两点使得Trillian会接受任何的SSL证书，无法抵御中间人攻击。

7. Rackspace

Rackspace是一个iOS的开源应用。它使用了OpenStack iOS cloud client framework来确立HTTPS连接。

• 其中ignoreSSLValidation变量的值是通过GUI上的一个开关来控制的，这个应该显示给用户，然而Rackspace并没有。
• 另一个ValidatesSecureCertificate的配置变量，在RackSpace进行初始化的时候，将其设置为0（默认是1），这就意味着它同时关闭了对证书链和主机名的认证。

8. TextSecure

TextSecure是一个安卓应用，用来加密SMS和MMS消息。
它在443端口试图使用https时，用了DEFAULT_SCHEME_NAME变量，然而在该段代码中，这个变量是“http”而不是“https”，这使得连接时信息是通过http传递，而不是https（虽然目前可能无法利用这个漏洞）。

Using Insecure Middleware

1. Apache Axis，Axis2，Codehaus XFire

用了SSLSocketFactory却没有自行对主机名进行认证。

2. Pusher

Pusher的安卓库中有Weberknecht，这个在之前的内容中有提到过，Weberknecht也是用了SSLSocketFactory却没有自行对主机名进行认证的，所以这种错误也被继承了下来。

在这之中必须注意，任何使用了任意上述Web-service框架的软件都无法抵御中间人攻击。

Using Insecure SSL Libraries

这一块主要是对于fsockopen的误用，在之前谈PHP的时候也提到过。
举例：

// post back to PayPal utility to validate
...
$fp = fsockopen('ssl://www.paypal.com', 443, $errno, $errstr, 30);

这是ZenCart中使用PayPal支付模块的代码，在许多其他购物卡或应用的支付过程中也有出现，开发者并没有意识到fsockopen不包含任何认证过程。

Python中的问题也在很多应用中有体现。

Breaking Or Disabling Certificate Validation

这个与其说是技术上的问题，更多的是来源于开发者自身安全意识的薄弱，许多人在开发过程中，在SSL上碰到一些问题，而往往在这个时候，关闭证书认证成了最简单的解决方式。

除此之外还有一些因为疏忽而造成的问题，使得证书认证环节被破坏。

Chase手机银行
在进行检查之前就return了。

Apache Libcloud
正则表达错误，使得oogle.com可以和google.com相匹配

Amazon Elastic Load Balancing API Tools

• 它重写了JDK的默认X509TrustManager，关闭了主机名认证
• 它使用了Codehaus XFire，这在之前已经说明过其不安全性了

Shopping carts
osCommerce, ZenCart, Ubercart, PrestaShop这些几乎都取消了证书认证。只有osCommerce和PrestaShop的Google模块是正确的。

AdMob
Google的AdMob提供了示例代码，然而在示例代码中就关闭了证书认证功能。中间人攻击者从而可以获得所有开发者的谷歌服务。

一些Android应用
Groupon Redemption使证书认证失效了2次：hostname verifier是“allow all”，并且绑定了一份空白的trust manager。
Breezy，使主机名认证失效并重写了trust manager
ACRA，一个Android库，重写了trust manager，所有使用了该库的app都无法抵御中间人攻击。

AIM

FilesAnywhere
在SSL连接中接受自签名或者第三方签名的证书

Suggestion

For application developers

• 使用fuzzing和adversarial testing，从而了解应用获得错误的SSL证书时的表现
• 在测试自签名和不可信的证书时，不要修改代码使得证书认证失效，以防忘记改回来
• 如果想要安全地建立起SSL连接，不要去依赖库的默认值，总是显式地进行安全设置

For SSL library developers

• 使SSL库的API更加意图明确，语义清晰
• 不要将管理SSL连接的责任推给应用
• 设计一份清晰的、前后一致的错误信息接口

Conclusion

1. 论文证明了许多标准SSL库经常错误地实现SSL证书认证，甚至根本没有认证，这些错误被许多对安全有着极高要求的应用和软件所继承，使得这些应用或软件无法抵御中间人攻击

2. 论文也对如何更加安全地在非浏览器的软件中使用SSL连接提出了一些建议：如1）进行更完善的黑盒测试和代码分析；2）设计更加严谨的认证技术和代码语言，从而使得自动检查SSL使用的正确性得到实现，并且减少对于一些重要参数和设置的误读；3）为SSL和其他网络安全协议设计更好的API。