WWDC 2017：Your Apps and Evolving Network Security Standards

本文首發于《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。

參考

• 視訊位址：Your Apps and Evolving Network Security Standards
• PPT 位址：Presentation Slides (PDF)