本文由CocoaChina譯者YueWang翻譯自tutsplus
原文：Apple Tightens Security With App Transport Security

---

在過去幾年中，對web安全的注意和它的重要性都在充分的穩定增長。在今年的WWDC大會上，Apple明確表示了它打算以身作則的通過一個新特性來提高操作系統的安全性，它就是App Transport Security.

當然，一個平台的安全性跟它的各個組件以及包括的第三方應用的安全性能息息相關。換句話說，Apple期望開發者們在他們的應用中使用App Transport Security.

在這篇文章中，我會解釋App Transport Security帶來了什麼，它怎樣影響你的應用程序，以及你可以怎樣更新你的應用來遵循Apple的指南和建議。

什麼是 App Transport Security?

App Transport Security，簡短的說就是ATS，是iOS9和OS X El Capitan的一個新特性。盡管Apple沒有提到watchOS，我們可以推測 App Transport Security 也同樣適用於watchOS 2.App Transport Security 的目標是提高Apple 操作系統的安全性以及在此操作系統上運行的任何應用的安全性。

基於HTTP傳輸數據的網絡請求都是明文。不言而喻的這會引起相當大的安全風險。Apple強調每個開發者都應該致力於保證客戶的數據都是安全的，盡管那些數據可能看起來並不是很重要或者很敏感。

App Transport Security 通過強力推行一系列的最好的安全實際操作來積極地促進安全性，最重要的一個就是要求網絡請求必須在一個安全的鏈接上傳輸。開啟App Transport Security後，網絡傳輸自動通過HTTPS傳輸而不是HTTP.

還有一系列其他的要求來進一步提高安全性能。例如，App Transport Security要求TLS (Transport Layer Security) 1.2或者更高。可能你並不是很了解 TLS，但我保證你肯定聽過SSL (Secure Sockets Layer)。TLS是SSL的繼承人，它是一系列加密協議的集合用來加強在網絡連接上的安全性。

Apple最近發表了一篇公開的，先導篇的文章?technote about App Transport Security，給了開發者們一個機會去研究 App Transport Security。這篇文章列出了 App Transport Security 期望從你的應用和與應用交互的網絡服務中得到的東西。

例外

等一下。我的應用使用的是我沒有權限控制的CDN (Content Delivery Network)而且它不支持HTTPS。別擔心，Apple都替你考慮好了。關於App Transport Security，每個應用都屬於4個大類當中的一類。我們來看看每一個大類都是怎樣影響應用的。

只有HTTPS

如果你的應用只基於支持HTTPS的服務器，那麼你太幸運了。你的應用不需要做任何改變。但是，注意App Transport Security要求TLS 1.2而且它要求站點使用支持forward secrecy協議的密碼。證書也要求是符合ATS規格的。因此慎重檢查與你的應用交互的服務器是不是符合ATS的要求非常重要。

混合

你的應用與一個不符合ATS要求的服務器工作是很有可能的。在這種情況下，你需要告訴操作系統哪些站點是涉及到的然後在你的應用的 Info.plist文件中指明哪些要求沒有達到。

這意味著對於每個與你應用交互的站點， 除了在你的應用的 Info.plist中聲明的那些以外不強制要求App Transport Security,其它的都需要。你可以使用很多的預定義的keys值來配置例外（exceptions）。在下面的 Info.plist文件中，我們定義了3個例外。

api.insecuredomain.com

我們定義的第一個例外告訴ATS當與這個子域交互的時候撤銷了必須使用HTTPS的要求。注意這個僅僅針對在例外中聲明了的子域。非常重要的一點是要理解NSExceptionAllowsInsecureHTTPLoads關鍵字並不僅僅只是與使用HTTPS相關。這個例外指明了對於那個域名，所有的App Transport Security的要求都被撤銷了。

cdn.domain.com

很可能你的應用是與一個支持HTTPS傳輸數據的服務器交互，但是並沒有使用TLS 1.2或更高。在這種情況下，你定義一個例外，它指明應該使用的最小的TLS的版本。這比完全撤銷那個域名的App Transport Security要更好更安全。

thatotherdomain.com

NSIncludesSubdomains關鍵字告訴 App Transport Security這個例外適用於這個特定域名的所有子域。這個例外還進一步通過擴展可接受的密碼列表來定義這個域名可以使用不支持forward secrecy(NSExceptionRequiresForwardSecrecy) ?協議的密碼。想了解更多關於forward secrecy的信息，我推薦你去看這個文章?Apple's technote。

撤銷

如果你在創建一個網頁浏覽器，那麼你有一個更大的麻煩。因為你不可能知道你的用戶將要訪問那個網頁，你不可能指明這些網頁是否支持ATS要求且在HTTPS上傳輸。在這種情況下，除了全部撤銷 App Transport Security 沒有其它辦法。

非常重要的是你要明確的指明撤銷 App Transport Security。牢記App Transport Security是默認強制執行的。在你的應用的Info.plist, 文件中，為NSAppTransportSecurity關鍵值添加一個字典。這個字典應該包括一個關鍵字，NSAllowsArbitraryLoads，以及它的值要被設置為YES。如果你撤消了App Transport Security，下面內容就是你的應用的 Info.plist 文件應該看起來像的東西：

有著例外的撤銷

第四個大類是當你的應用撤消了App Transport Security,，但同時定義了一些例外。這非常有用就是當你的應用從很多的服務器上取數據，但是也要與一個你可控的API交互。在這種情況下，在應用的Info.plist文件中指定任何加載都是被允許的，但是你也指定了一個或多個例外來表明哪些是必須要求 App Transport Security的。下面是Info.plist文件應該會有的內容：

時間

Apple強調如果應用是建於iOS9 或者 OS X El Capitan，那麼它們自動的加入 App Transport Security 。這意味著只要你的應用建於 iOS 8或OS X Yosemite上，你不需要對你的應用做任何改變。

基於以前發布的iOS和OSX X系統的經驗，我們了解到Apple在發布了官方版本後不久就要求開發者們使用最新的SDK來創建應用。換句話說，即便你不想在今年末當iOS 9 和OS X El Capitan 發布的時候遵守App Transport Security ，很有可能蘋果會在2016年的第一或第二季度要求開發者們基於最新的SDK來開發應用。因此我推薦你盡早研究App Transport Security 將會對你的應用帶來的影響。

總結

我希望這篇文章清楚地講明了App Transport Security並不是那些哪天采用都無所謂的技術。它跟之前Apple要求所有應用都支持64位一樣，遲早要全部采用。除非你的應用只跟基於HTTPS傳輸協議遵循ATS要求的服務器交互，你需要花些時間研究清楚App Transport Security將會怎樣影響到你的應用。Apple的這篇文章technote about App Transport Security可以幫助到你。
推薦閱讀：蘋果新『應用通信安全』的理解和使用