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 的一些改變：

• 最佳實踐
• 取消對老舊加密算法支持，好比 RC四、SHA-一、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複製代碼

參考

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