上周大量的出版物流出这么一个故事，大约有1000多个应用程序由于AFNetworking的一个SSL Bug而易受侵害。这些文章中对于该问题包含了一些不正确的误导性称述。

正是因为如此，我们发表了这篇文章来回应并澄清这些不正确的描述。

　　背景信息

对于那些不熟系AFNetworking的童鞋，我们准备了一些与该故事有关联的详细信息:

AFNetworking是一个开源的第三方库，其基于苹果的基础平台上为开发者提供了便利的工具。

AFNetworking 其中的一个组件名为AFSecurityPolicy，它负责依据应用程序配置的策略处理身份验证。这其中包括了X.509证书 (当通过HTTPS连接时服务器传回的)的校验。

证书绑定 是通过强制执行证书服务器发送证书与客户端的凭证来改进标准TLS评分的安全技术。从版本1.2.0开始，AFNetworking提供证书绑定功能。

中间人攻击是一个攻击服务，通过将其本身嵌入到服务器与客户端之间的这种方式，这样两者都认为它们仍然是在直接通信。

这样的攻击会通过不可信的WiFi热点代理客户端与服务器之间的请求。如果没有正确的验证响应，攻击者可以拦截通讯信息，这样可能会暴露用户凭证或其他敏感信息。

AFNetworking文档 强烈建议应用程序间通过HTTPS以及使用证书/公钥绑定来通信，以减轻MitM攻击.。

　　时间线

考虑到有些朋友对此还不太了解，我们提供了与此相关的突发事件的时间表：

在2015年2月12日，AFNetworking 2.5.1发布。此版本合并了一个补丁来修正当安全机制由SSLPinningMode 设为AFSSLPinningModeNone时的校验凭证。默认情况下，证书服务器不会在 授权改变时做合法性验证，除非客户端配置不同的行为，比如启用SSL绑定。

在2015年3月12日，从这个GitHub的Issue 中我们第一次意识到这种变化的行为的影响。

在2015年3月26日，Minded Security Research机构的Simone Bovi 和 Mauro Gentile 发表了一篇博客详述在AFNetworking 2.5.1中潜在的MitM漏洞。

同样在2015年3月26日， AFNetworking 2.5.2发布。这个版本恢复到之前的证书校验机制以及如果将机制validatesDomainName设为YES，那么就设置安全机制SSLPinningMode 为AFSSLPinningModeNone。

在2015年4月20日，AFNetworking 2.5.3发布。该版本做的附加改变是默认将所有机制的validatesDomainName设为YES。

在2015年4月21日，一个Issue在Github上被打开，该Issue请求增加关于AFNetworking安全特性的文档。我们遵循了这个建议并且正在积极的检查我们的参考文档。

同样在2015年4月21日，来自SourceDNA的Nate Lawson发布了一篇博客 宣传说在应用商店中识别iOS应用程序的工具就是使用了AFNetworking 2.5.1的。一些记者，包括Ars Technica的的Dan Goodin，发表了一篇文章引用该博客及其作者。但是所有出版物都未向任何一个AFNetworking维护者请求回应。

在2015年4月24日，SourceDNA继续发表了一篇博客指称更多的应用程序变得易受侵害。Ars Technica的的Dan Goodin同样也跟着发表了一篇文章做了同样的事.同样的，没有任何一个出版物向任何一个AFNetworking维护者请求回应。

(责任编辑：安博涛)