上周大量的出版物流出這么一個故事，大約有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維護者請求回應。

AFNetworking用戶可操縱的信息

如果你是AFNetworking用戶，那么這里是你需要知道的一些可操縱的信息:

如果你的應用程序通過HTTPS通訊但是尚未啟用SSL 綁定，這可能會被報道中的中間人攻擊

來自AFSecurityPolicy的文檔

添加SSL證書綁定有助于避免你的應用程序遭受中間人攻擊或其他安全漏洞。處理敏感的客戶數據或財務信息的應用程序我們強烈建議啟用SSL綁定并使用 HTTPS 連接通信。

按照以下這些建議操作的任何應用程序在任何時刻應該都不會暴露上述漏洞。

如果你的應用程序啟用了SSL綁定且通過HTTPS通信,它就不會像報道中說的那樣易受 MitM攻擊

大量使用 AFNetworking的應用程序遵循了建議的步驟啟用了SSL證書或公共密鑰綁定。這些應用程序不會像報道中說的那樣易受 MitM攻擊。

如果你正在使用早先的AFNetworking版本, 我們強烈建議你升級到版本2.5.3

AFNetworking 2.5.1 以及 2.5.2 不適合應用程序產品，尤其是它們不經過額外配置就無法提供TLS評分。

AFNetworking 2.5.3默認為安全的行為，即使未使用SSL綁定也支持域名校驗。

如果你正在使用NSURLConnection / NSURLSession而不是AFNetworking，你仍然需要審查你的身份校驗的實現

蘋果內置的NSURLConnection/NSURLSession以及安全框架API提供的憑證校驗的安全實現。然而，就像任何API，應用程序只是在使用這些API的時候是安全的。

決定是否使用AFNetworking并不能保證你的應用程序免受攻擊，例如MitM。這完全卻取決于該應用程序如何使用這些可用的API。最終，這些開發人員還要在生產環境中測試應用程序的健壯性和網絡安全。

如果你想報告一個漏洞，請發郵件給[email protected]

我們會盡快的作出回應。

如果你想要貢獻自己的一份力量來讓AFNetworking變得更改，請打開一個Issue或者Pull Request

AFNetworking是開源的，這意味著任何人都有機會作出貢獻，使它變得更好。Issues 或者Pull Requests 都行。

關于負責的安全研究和新聞聲明

安全研究人員在實現面向用戶的軟件的安全性方面扮演者一個重要的角色。如果安全研究人員與開發者同心協力，遵守協定作出負責任的漏洞報告，那么就可以快速的解決應用程序的脆弱性問題同時將現有用戶的風險降到最低。

我們是這樣子做的，然而，對于某些安全研究人員以及出版商決定由他們自身報道AFNetworking的事情我們感到非常失望。信息安全是所有人都需要了解的一個重要話題，無論是安全研究人員或是新聞工作者都有機會讓讀者了解這些實際情況。很不幸的是，大多數時候，這些報道都是通過恐懼而不是客觀現實來吸引流量的。

目前尚未由明確的方法來證明由多少應用程序遭受了這種行為；猜測安全問題的嚴重性來計算當它們發生的時候會造成多么大的破壞以及反應的比例數。同樣，基于提供少量的工具給商家或他們的用戶來推測出脆弱性的應用程序。

事實是，一直以來編寫安全的軟件都是一個困難的挑戰。這樣做需要跨越多個學科的工程師的合作。它是極為重要的任務，那個人最好是理性的、 負責任的。

作為軟件維護者，由許多東西我們可以做得更好的，并且正在積極采取步驟來改善我們的組織和流程。我們期待著與信息安全社會的成員密切合作，從現在開始負責任地找出并解決任何漏洞。

一項關于負責任的開放源代碼維護聲明

我們對那些正在使用AFNetworking的所有開發者以及iOS社區表示最誠摯的歉意。

作為一個著名的開源項目維護者，提供滿足高標準的選擇讓用戶選擇作為應用程序的依賴是我們的責任。我們未能盡快的發布更新版本的回應。我們未能有效地傳達給你的重要的安全信息。以上，我們真的很抱歉，我們愿意承擔全部責任。

在未來的幾周，我們將推出了重構的的 AFNetworking 和及其相關的項目，以確保軟件質量和通信的一致性一同向前發展。對于用戶而言這意味著更加頻繁的版本發布和更多的透明度和反饋處理issues和pull requests的過程。我們很興奮地想知道對于AFNetworking 項目和它的用戶，這將意味著什么。