本文首發(fā)于《iOS 成長之路》纱皆，購買可查看更多 WWDC 系列文章，轉(zhuǎn)載請聯(lián)系作者芭商。

現(xiàn)在派草，我們越來越關(guān)注用戶的隱私和信息安全，但是隨著時間的推移铛楣，計算機變得越來越高效近迁，那些年代久遠的網(wǎng)絡(luò)協(xié)議和加密算法，在新的硬件和攻擊方式下蛉艾，變得岌岌可危钳踊。

針對網(wǎng)絡(luò)安全拓瞪，我們要怎樣做？

• 時刻關(guān)注 App 的安全，保證 App 的及時更新
• 了解業(yè)界的發(fā)展變化，跟進最新的標(biāo)準(zhǔn)睦焕、學(xué)術(shù)研究和工業(yè)界的實踐
• 確保集成的第三方庫可以得到及時的更新袜炕，避免安全隱患
• OS 移除安全隱患
• 使用 ATS（App Transport Security）乌助，ATS 會強制在 App 中使用最佳實踐
• 相比被攻擊后的嚴(yán)重后果纵诞，前期投入一定的維護成本是值得的

常見的網(wǎng)絡(luò)攻擊

這里總結(jié)了一些常見的網(wǎng)絡(luò)攻擊，它們針對的對象有所不同纸俭，有的是想竊取數(shù)據(jù)，有的是想偽裝身份，它們在圖中以顏色進行區(qū)分。我將會通過一些實踐來告訴你，如何去避免這些攻擊氧映，具體來說就是關(guān)于加密（encryption）蹭劈、密碼散列（cryptographic hashes）、公共密鑰（public keys）塔逃、網(wǎng)絡(luò)協(xié)議（protocols）立轧、證書吊銷檢查（revocation）等內(nèi)容的一些實踐。

TLS 協(xié)議

現(xiàn)在大多數(shù)的 App 網(wǎng)絡(luò)都已經(jīng)切換到 HTTPS 了，HTTPS 其實就是在 HTTP 下加入了 TLS 層悠菜，TLS 是保證網(wǎng)絡(luò)安全的基礎(chǔ)，它可以對傳輸內(nèi)容加密、進行身份驗證椎麦、避免傳輸內(nèi)容被篡改嘁捷。

TLS 協(xié)議是由 TLS 握手協(xié)議和 TLS 記錄協(xié)議兩部分組成喘蟆，TLS 記錄協(xié)議負責(zé)對傳輸內(nèi)容加密，TLS 握手協(xié)議又分為四個子協(xié)議，負責(zé)協(xié)商加密算法荆残、共享密鑰蕴潦、傳達警告等工作僧诚。

TLS 協(xié)議中涉及到多種不同的密碼技術(shù)，比如在握手協(xié)議中使用到了非對稱加密捎废、散列函數(shù)匾寝、數(shù)字簽名技術(shù)，在 TLS 記錄協(xié)議中使用到了對稱加密四瘫、散列函數(shù)等技術(shù)。具體的這些技術(shù)，在下面會詳細介紹奈虾，并且說明哪些技術(shù)已經(jīng)過時了，需要更換更安全的加密算法來保證安全。

密碼技術(shù)介紹

本文中，涉及到一些加密算法播赁，根據(jù)密鑰的使用方式，可以分為對稱加密和非對稱加密：

• 對稱加密：加密和解密的過程中使用的是同一種密鑰。常用的加密算法有DES、AES等。
• 非對稱加密：又叫做公鑰加密，在加密和解密的過程中使用不同的密鑰。常用的加密算法有RSA再膳、ECC等孽椰。

除了上述兩種加密算法，還有一些用來確保信息完整性和身份認(rèn)證的技術(shù)：

• 密碼散列算法：它不是一種加密算法沛励，而是用來確保信息未被篡改。密碼散列函數(shù)會根據(jù)信息的內(nèi)容計算出一個散列值，這個散列值就被用來檢查信息的完整性惶我。
• 數(shù)字簽名：信息的發(fā)送者用私鑰加密，接收者使用公鑰解密鸣峭。用私鑰加密的密文只能由對應(yīng)的公鑰來解密，所以可以將這個過程叫做數(shù)字簽名喊暖，用來身份認(rèn)證沪么。
• 證書：經(jīng)過 CA 機構(gòu)數(shù)字簽名后的公鑰證書记焊，用于身份認(rèn)證恩尾。

加密

加密是我們眾所周知的用來防止信息被竊聽的手段渔嚷，但是一些加密算法已經(jīng)非常不安全，很容易被攻擊者攻破欺劳。特別是 RC4， 目前可以在短短三天之內(nèi)就可以攻破它群凶。而且，Triple-DES 和 AES 加密算法在 BEAST 和 Lucky 13 這些攻擊面前咆霜，也無法保證安全性。蘋果正在計劃在所有平臺上棄用 Triple-DES 和 RC4拷泽，同時也不推薦使用 AES-CBC 算法庭再，但是還沒給出具體的日期奶卓。Apple 推薦我們使用 AES-GCM 或者 ChaCha20/Poly1305 算法荔茬。

密碼散列

密碼散列會有一個輸入值和一個輸出值，輸入的稱為消息，輸出的稱為散列值狮崩。密碼散列會根據(jù)輸入的內(nèi)容計算一個散列值出來狱窘，這個散列值可以用來判斷信息是否完整蘸炸。但是其中一些密碼散列已經(jīng)不安全了，黑客可以通過碰撞攻擊的方式來篡改數(shù)據(jù)。碰撞攻擊是通過大量的嘗試智嚷，來找到不同的輸入值泉坐，但是輸出值是一樣的情況，進而篡改數(shù)據(jù)坠陈。因為篡改后的散列值并沒有發(fā)生變化萨惑，所以你無法判斷數(shù)據(jù)是否被修改過。

MD-5 和 SHA-1 已經(jīng)不安全了仇矾，Apple 已經(jīng)在前幾年在移除了 MD-5 算法的簽名證書庸蔼。SHA-1 在今年的早些時候，也遭遇了攻擊贮匕。所以姐仅，Apple 將也不再信任 SHA-1 算法的簽名證書。為了保證絕對的安全，開發(fā)者應(yīng)該使用 SHA-2 算法萍嬉。

公鑰密碼

一般情況下乌昔，經(jīng)過公鑰加密的內(nèi)容隙疚，只能通過私鑰打開加密內(nèi)容壤追。但是，768 位的 RSA 在2009 年被攻破供屉，Apple 在 2016 年春天已經(jīng)移除了對 1024 位以下 RSA 簽名的證書的支持行冰。由此來看，對 1024 位 RSA 加密的攻擊也快要來到了伶丐，所以 Apple 也宣布將不再對 2048 位以下 RSA 簽名的證書信任悼做。你應(yīng)該使用 2048 位以上的 RSA 加密，或者其他 Apple 平臺信任的橢圓曲線密碼哗魂。

協(xié)議

如果開發(fā)者正在使用HTTP協(xié)議肛走，那就代表著你傳輸?shù)膬?nèi)容，任何監(jiān)聽者都可以獲取到录别。同時朽色，一些老化的 TLS 版本，也是不安全的组题，比如 SSL 3.0葫男、TLS1.1 和 TLS1.0。應(yīng)該避免使用這些協(xié)議崔列，開發(fā)者應(yīng)該使用基于 TLS1.2 的 HTTPS 協(xié)議梢褐。

同時，Apple 宣布發(fā)布 TLS 1.3 Beta 版赵讯，后續(xù)會詳細講盈咳。

吊銷

當(dāng)私鑰泄漏或者或者其他一些情況出現(xiàn)時，我們可能需要吊銷證書边翼≈硖埃客戶端在收到證書的時候，需要確認(rèn)證書的吊銷情況讯私。

Apple平臺默認(rèn)是不進行吊銷檢查的热押。目前存在的吊銷機制有以下幾種：

• 證書吊銷列表（Certificate Revocation List ，CRL）斤寇，這是一個包含吊銷證書序列號的列表桶癣，證書頒發(fā)機構(gòu)維護著這樣的列表。它的缺點在于娘锁，CRL 會越來越大牙寞，實時查詢會越來越慢，同時需要不斷請求 CA 的CRL，具有一定的延遲性间雀。
• 在線證書狀態(tài)協(xié)議（Online Certificate Status Protocol悔详，OCSP），OCSP 是這樣工作的惹挟。首先茄螃，服務(wù)端會從 CA 申請一個證書，服務(wù)端會把證書發(fā)送給客戶端作為驗證连锯，客戶端為了驗證服務(wù)端的身份會向 CA 發(fā)送一個請求归苍，來獲取該證書的吊銷信息，CA 會返回該證書的狀態(tài)給客戶端运怖∑雌客戶端根據(jù)返回結(jié)果來判斷服務(wù)端的證書是否正確∫≌梗可以看出來吻氧，OCSP 有明顯的缺陷，客戶端需要向 CA 發(fā)送額外的網(wǎng)絡(luò)請求咏连，這導(dǎo)致了它存在一些性能問題盯孙。并且 OCSP 是明文傳輸，會存在安全隱患捻勉《扑螅基于這兩個原因，Apple默認(rèn)不支持OCSP驗證踱启。如果開發(fā)者想啟用 OCSP 查詢报账，需要在 App 中集成其他API。

• OCSP Stapling埠偿，它彌補了 OCSP 的缺陷透罢，服務(wù)端在從 CA 請求證書的時候，也會從 CA 請求到證書的吊銷信息冠蒋，然后將吊銷信息和證書一起發(fā)送給客戶端羽圃，客戶端可以同時對證書和吊銷信息進行校驗。

盡管 Apple 鼓勵開發(fā)者在服務(wù)端采用 OCSP Stapling 這種方式抖剿，但是普及程度遠遠不夠朽寞。Apple 同時宣布加強在所有平臺的證書吊銷驗證。Apple 會從 Certificate Transparency log 中獲取信賴的證書列表斩郎，開發(fā)者和CA都可以向 Certificate Transparency log 提交證書脑融，提交的證書會受到監(jiān)控和審計。然后 Apple 會從證書頒發(fā)機構(gòu)查詢證書的吊銷狀態(tài)缩宜，把所有吊銷證書的信息捆綁到一起肘迎，每隔一段時間自動下發(fā)給客戶端設(shè)備甥温，這樣客戶端就可以周期性的驗證證書的吊銷狀態(tài)了。

在進行 TLS 會話時妓布，如果發(fā)現(xiàn)證書在吊銷列表內(nèi)姻蚓，那么客戶端則執(zhí)行一次 OCSP 檢查，去校驗證書是否真的已經(jīng)被吊銷匣沼。如果證書沒有在吊銷列表中狰挡，則不進行 OCSP 檢查。這樣的話肛著，客戶端一般就不需要向 CA 發(fā)送額外的網(wǎng)絡(luò)請求圆兵，避免了性能問題跺讯。

回顧

Apple 關(guān)于加密枢贿、散列函數(shù)、網(wǎng)絡(luò)協(xié)議刀脏、證書吊銷校驗和公鑰密碼方面的修改如圖所示：

新的證書報錯界面

在 Safari 中重新設(shè)計了新的證書報錯界面局荚，如果你用了不符合要求的證書，那么將會看到如下界面愈污。

可以通過證書查看器耀态，進一步查看證書錯誤的詳細情況。

ATS 與 TLS 1.3

ATS 在 iOS 9 的時候推出暂雹，是為了保證開發(fā)者使用加密的網(wǎng)絡(luò)來傳輸數(shù)據(jù)首装。但是 Apple 發(fā)現(xiàn)全部轉(zhuǎn)為 ATS 的過渡期要比預(yù)期長，所以 Apple 擴大了對 ATS 的豁免的支持杭跪。

去年 Apple 發(fā)現(xiàn)目前的 ATS 豁免并不能滿足所有開發(fā)者的需求仙逻，所以就開放了對AVFoundation、WebView 和 Webkit 的單獨豁免支持涧尿∠捣睿豁免可以限制在一個單一域名內(nèi)和整個 App 內(nèi)，同時也支持對本地網(wǎng)絡(luò)（原始 IP 地址和不合格的主機名）的豁免姑廉。

雖然目前擴大了對豁免的支持缺亮，但是 Apple 依然相信使用 ATS 才是正確的選擇，依然會積極推薦 ATS 的使用桥言。

TLS 發(fā)展歷程

TLS 的前身其實就是 SSL（Secure Sockets Layer）萌踱，Netscape 是最早發(fā)布 SSL 的公司，后續(xù)由于互聯(lián)網(wǎng)標(biāo)準(zhǔn)化組織的接手号阿，將 SSL 標(biāo)準(zhǔn)化并鸵，并在 1999 年將其稱為 TLS（Transport Layer Security）。后續(xù)又在 2006 年 4 月對 TLS 1.0 進行了更新倦西，這個版本與 1.0 差異不大能真。2008 年發(fā)布了 TLS 1.2，也就是目前 Apple 推薦在 HTTPS 網(wǎng)絡(luò)上使用的協(xié)議。

TLS 1.3 是正在制定的 TLS 新標(biāo)準(zhǔn)粉铐，目前還是草案版本疼约。

TLS 1.3

在 WWDC 上 Apple 闡述了 TLS 1.3 相比 TLS 1.2 的一些改變：

• 最佳實踐
• 取消對老舊加密算法支持，比如 RC4蝙泼、SHA-1程剥、CBC 和 RSA 加密算法。
• 更簡單的配置汤踏、更容易測試
• 在 TLS 握手和會話恢復(fù)方面性能提升

關(guān)于第四點應(yīng)該是我們最關(guān)心的優(yōu)化點织鲸，TLS 握手從原來的四次握手變成了兩次握手，也就是說減少了一個 RTT溪胶，TLS 1.3 的密鑰交換和加密算法的協(xié)商都放在了一塊搂擦。由于這套更高效的握手方法，Apple 宣布大概可以減少三分之一的握手延遲哗脖。

雖然正式的版本還沒發(fā)布瀑踢，但是現(xiàn)在你可以對 TSL 1.3 beta 版本進行測試了，你可以在 https://developer.apple.com/go/?id=tls13-mobile-profile 下載安裝一個配置文件在手機上才避，同時手機系統(tǒng)升級到 iOS 11 就可以體驗最新的 TLS 協(xié)議了橱夭。同時，在 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)