本文首發於《iOS 成長之路》，購買可檢視更多 WWDC 系列文章，轉載請聯絡作者。
現在，我們越來越關注使用者的隱私和資訊保安，但是隨著時間的推移，計算機變得越來越高效，那些年代久遠的網路協議和加密演算法，在新的硬體和攻擊方式下，變得岌岌可危。
針對網路安全，我們要怎樣做？
- 時刻關注 App 的安全，保證 App 的及時更新
- 瞭解業界的發展變化，跟進最新的標準、學術研究和工業界的實踐
- 確保整合的第三方庫可以得到及時的更新，避免安全隱患
- OS 移除安全隱患
- 使用 ATS（App Transport Security），ATS 會強制在 App 中使用最佳實踐
- 相比被攻擊後的嚴重後果，前期投入一定的維護成本是值得的
常見的網路攻擊
這裡總結了一些常見的網路攻擊，它們針對的物件有所不同，有的是想竊取資料，有的是想偽裝身份，它們在圖中以顏色進行區分。我將會通過一些實踐來告訴你，如何去避免這些攻擊，具體來說就是關於加密（encryption）、密碼雜湊（cryptographic hashes）、公共金鑰（public keys）、網路協議（protocols）、證書吊銷檢查（revocation）等內容的一些實踐。
TLS 協議
現在大多數的 App 網路都已經切換到 HTTPS 了，HTTPS 其實就是在 HTTP 下加入了 TLS 層，TLS 是保證網路安全的基礎，它可以對傳輸內容加密、進行身份驗證、避免傳輸內容被篡改。
TLS 協議是由 TLS 握手協議和 TLS 記錄協議兩部分組成，TLS 記錄協議負責對傳輸內容加密，TLS 握手協議又分為四個子協議，負責協商加密演算法、共享金鑰、傳達警告等工作。
TLS 協議中涉及到多種不同的密碼技術，比如在握手協議中使用到了非對稱加密、雜湊函式、數字簽名技術，在 TLS 記錄協議中使用到了對稱加密、雜湊函式等技術。具體的這些技術，在下面會詳細介紹，並且說明哪些技術已經過時了，需要更換更安全的加密演算法來保證安全。
密碼技術介紹
本文中，涉及到一些加密演算法，根據金鑰的使用方式，可以分為對稱加密和非對稱加密：
- 對稱加密：加密和解密的過程中使用的是同一種金鑰。常用的加密演算法有DES、AES等。
- 非對稱加密：又叫做公鑰加密，在加密和解密的過程中使用不同的金鑰。常用的加密演算法有RSA、ECC等。
除了上述兩種加密演算法，還有一些用來確保資訊完整性和身份認證的技術：
- 密碼雜湊演算法：它不是一種加密演算法，而是用來確保資訊未被篡改。密碼雜湊函式會根據資訊的內容計算出一個雜湊值，這個雜湊值就被用來檢查資訊的完整性。
- 數字簽名：資訊的傳送者用私鑰加密，接收者使用公鑰解密。用私鑰加密的密文只能由對應的公鑰來解密，所以可以將這個過程叫做數字簽名，用來身份認證。
- 證書：經過 CA 機構數字簽名後的公鑰證書，用於身份認證。
加密
加密是我們眾所周知的用來防止資訊被竊聽的手段，但是一些加密演算法已經非常不安全，很容易被攻擊者攻破。特別是 RC4， 目前可以在短短三天之內就可以攻破它。而且，Triple-DES 和 AES 加密演算法在 BEAST 和 Lucky 13 這些攻擊面前，也無法保證安全性。蘋果正在計劃在所有平臺上棄用 Triple-DES 和 RC4，同時也不推薦使用 AES-CBC 演算法，但是還沒給出具體的日期。Apple 推薦我們使用 AES-GCM 或者 ChaCha20/Poly1305 演算法。
密碼雜湊
密碼雜湊會有一個輸入值和一個輸出值，輸入的稱為訊息，輸出的稱為雜湊值。密碼雜湊會根據輸入的內容計算一個雜湊值出來，這個雜湊值可以用來判斷資訊是否完整。但是其中一些密碼雜湊已經不安全了，黑客可以通過碰撞攻擊的方式來篡改資料。碰撞攻擊是通過大量的嘗試，來找到不同的輸入值，但是輸出值是一樣的情況，進而篡改資料。因為篡改後的雜湊值並沒有發生變化，所以你無法判斷資料是否被修改過。
MD-5 和 SHA-1 已經不安全了，Apple 已經在前幾年在移除了 MD-5 演算法的簽名證書。SHA-1 在今年的早些時候，也遭遇了攻擊。所以，Apple 將也不再信任 SHA-1 演算法的簽名證書。為了保證絕對的安全，開發者應該使用 SHA-2 演算法。
公鑰密碼
一般情況下，經過公鑰加密的內容，只能通過私鑰開啟加密內容。但是，768 位的 RSA 在2009 年被攻破，Apple 在 2016 年春天已經移除了對 1024 位以下 RSA 簽名的證書的支援。由此來看，對 1024 位 RSA 加密的攻擊也快要來到了，所以 Apple 也宣佈將不再對 2048 位以下 RSA 簽名的證書信任。你應該使用 2048 位以上的 RSA 加密，或者其他 Apple 平臺信任的橢圓曲線密碼。
協議
如果開發者正在使用HTTP協議，那就代表著你傳輸的內容，任何監聽者都可以獲取到。同時，一些老化的 TLS 版本，也是不安全的，比如 SSL 3.0、TLS1.1 和 TLS1.0。應該避免使用這些協議，開發者應該使用基於 TLS1.2 的 HTTPS 協議。
同時，Apple 宣佈釋出 TLS 1.3 Beta 版，後續會詳細講。
吊銷
當私鑰洩漏或者或者其他一些情況出現時，我們可能需要吊銷證書。客戶端在收到證書的時候，需要確認證書的吊銷情況。
Apple平臺預設是不進行吊銷檢查的。目前存在的吊銷機制有以下幾種：
- 證書吊銷列表（Certificate Revocation List ，CRL），這是一個包含吊銷證書序列號的列表，證書頒發機構維護著這樣的列表。它的缺點在於，CRL 會越來越大，實時查詢會越來越慢，同時需要不斷請求 CA 的CRL，具有一定的延遲性。
- 線上證書狀態協議（Online Certificate Status Protocol，OCSP），OCSP 是這樣工作的。首先，服務端會從 CA 申請一個證書，服務端會把證書傳送給客戶端作為驗證，客戶端為了驗證服務端的身份會向 CA 傳送一個請求，來獲取該證書的吊銷資訊，CA 會返回該證書的狀態給客戶端。客戶端根據返回結果來判斷服務端的證書是否正確。可以看出來，OCSP 有明顯的缺陷，客戶端需要向 CA 傳送額外的網路請求，這導致了它存在一些效能問題。並且 OCSP 是明文傳輸，會存在安全隱患。基於這兩個原因，Apple預設不支援OCSP驗證。如果開發者想啟用 OCSP 查詢，需要在 App 中整合其他API。
- OCSP Stapling，它彌補了 OCSP 的缺陷，服務端在從 CA 請求證書的時候，也會從 CA 請求到證書的吊銷資訊，然後將吊銷資訊和證書一起傳送給客戶端，客戶端可以同時對證書和吊銷資訊進行校驗。
儘管 Apple 鼓勵開發者在服務端採用 OCSP Stapling 這種方式，但是普及程度遠遠不夠。Apple 同時宣佈加強在所有平臺的證書吊銷驗證。Apple 會從 Certificate Transparency log 中獲取信賴的證書列表，開發者和CA都可以向 Certificate Transparency log 提交證書，提交的證書會受到監控和審計。然後 Apple 會從證書頒發機構查詢證書的吊銷狀態，把所有吊銷證書的資訊捆綁到一起，每隔一段時間自動下發給客戶端裝置，這樣客戶端就可以週期性的驗證證書的吊銷狀態了。
在進行 TLS 會話時，如果發現證書在吊銷列表內，那麼客戶端則執行一次 OCSP 檢查，去校驗證書是否真的已經被吊銷。如果證書沒有在吊銷列表中，則不進行 OCSP 檢查。這樣的話，客戶端一般就不需要向 CA 傳送額外的網路請求，避免了效能問題。
回顧
Apple 關於加密、雜湊函式、網路協議、證書吊銷校驗和公鑰密碼方面的修改如圖所示：
新的證書報錯介面
在 Safari 中重新設計了新的證書報錯介面，如果你用了不符合要求的證書，那麼將會看到如下介面。
可以通過證書檢視器，進一步檢視證書錯誤的詳細情況。
ATS 與 TLS 1.3
ATS 在 iOS 9 的時候推出，是為了保證開發者使用加密的網路來傳輸資料。但是 Apple 發現全部轉為 ATS 的過渡期要比預期長，所以 Apple 擴大了對 ATS 的豁免的支援。
去年 Apple 發現目前的 ATS 豁免並不能滿足所有開發者的需求，所以就開放了對AVFoundation、WebView 和 Webkit 的單獨豁免支援。豁免可以限制在一個單一域名內和整個 App 內，同時也支援對本地網路（原始 IP 地址和不合格的主機名）的豁免。
雖然目前擴大了對豁免的支援，但是 Apple 依然相信使用 ATS 才是正確的選擇，依然會積極推薦 ATS 的使用。
TLS 發展歷程
TLS 的前身其實就是 SSL（Secure Sockets Layer），Netscape 是最早釋出 SSL 的公司，後續由於網際網路標準化組織的接手，將 SSL 標準化，並在 1999 年將其稱為 TLS（Transport Layer Security）。後續又在 2006 年 4 月對 TLS 1.0 進行了更新，這個版本與 1.0 差異不大。2008 年釋出了 TLS 1.2，也就是目前 Apple 推薦在 HTTPS 網路上使用的協議。
TLS 1.3 是正在制定的 TLS 新標準，目前還是草案版本。
TLS 1.3
在 WWDC 上 Apple 闡述了 TLS 1.3 相比 TLS 1.2 的一些改變：
- 最佳實踐
- 取消對老舊加密演算法支援，比如 RC4、SHA-1、CBC 和 RSA 加密演算法。
- 更簡單的配置、更容易測試
- 在 TLS 握手和會話恢復方面效能提升
關於第四點應該是我們最關心的優化點，TLS 握手從原來的四次握手變成了兩次握手，也就是說減少了一個 RTT，TLS 1.3 的金鑰交換和加密演算法的協商都放在了一塊。由於這套更高效的握手方法，Apple 宣佈大概可以減少三分之一的握手延遲。
雖然正式的版本還沒釋出，但是現在你可以對 TSL 1.3 beta 版本進行測試了，你可以在 developer.apple.com/go/?id=tls1… 下載安裝一個配置檔案在手機上，同時手機系統升級到 iOS 11 就可以體驗最新的 TLS 協議了。同時，在 macOS High Sierra 中，可以通過以下終端命令啟用 TLS 1.3。
defaults write /Library/Preferences/com.apple.networkd tcp_connect_enable_tls13 1複製程式碼