原文連結：http://www.cocoachina.com/ios/20150821/13140.html

在過去幾年中，對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可以幫助到你。
推薦閱讀：蘋果新『應用通訊安全』的理解和使用