Netflix 專注于提供最好的流媒體體驗。我們希望可以立即開始回放(playback)，并且在任何網(wǎng)絡環(huán)境中都不會意外停止。我們還致力于在不犧牲任
Netflix 專注于提供最好的流媒體體驗。我們希望可以立即開始回放(playback)，并且在任何網(wǎng)絡環(huán)境中都不會意外停止。我們還致力于在不犧牲任何回放體驗的情況下保護用戶隱私和服務安全。為實現(xiàn)這一目標，我們正使用 ABR(自適性串流)來實現(xiàn)更好的播放體驗。同時，我們還使用 DRM(數(shù)字版權管理)來保護我們的服務，用 TLS(傳輸層安全)來保護客戶隱私并創(chuàng)建一個更安全的流媒體體驗。
在諸如電視、機頂盒等消費類電子設備上，Netflix 最近才在流媒體業(yè)務上使用 TLS 1.2。現(xiàn)在，為獲得更安全、更流暢的體驗，我們已經(jīng)支持 TLS 1.3。
TLS 是什么?
要實現(xiàn)雙方間的安全通信，就要有一個安全通道。該通道需要具有以下三個特性。
身份驗證：驗證通信雙方的身份。
保密性：通過通道發(fā)送的數(shù)據(jù)僅對端點可見。
完整性：通過通道發(fā)送的數(shù)據(jù)如果被攻擊者修改可以檢測到。
TLS 協(xié)議旨在通過提供實現(xiàn)上述特性的工具和方法，來提供兩個對等點之間的安全通道。
TLS 1.3
TLS 1.3 是傳輸層安全協(xié)議(Transport Layer Security)的最新版本。與前一個版本相比，它更簡單、更安全、更高效。
Perfect Forward Secrecy對 Netflix 而言，我們認為非常重要的一點是提供 PFS (Perfect Forward Secrecy)。
PFS 是密鑰交換算法的一個特性，即使服務器的私鑰被破壞，它也可以確保會話密鑰不被破壞。通過為每個會話生成新的密鑰，PFS 可以保護過去的會話不受未來密鑰泄露的影響。
TLS 1.2 支持具備 PFS 特性的密鑰交換算法，但是它也允許不支持 PFS 的密鑰交換算法。即使在 TLS 1.2 的前一個版本中，Netflix 也總是會選擇一個提供 PFS 的密鑰交換算法，比如 ECDHE(Elliptic Curve Diffie Hellman Ephemeral)。不過，TLS 1.3 刪除了所有不提供 PFS 的密鑰交換算法(如靜態(tài) RSA)，進一步強化了這一概念。
認證加密
對于加密，TLS 1.3 刪除了所有弱密碼，只使用帶有關聯(lián)數(shù)據(jù)(AEAD)的認證加密。這保證了數(shù)據(jù)的保密性、完整性和真實性。我們使用 AES Galois/Counter 模式，因為它同時還提供良好的性能和高吞吐量。
安全握手
雖然上述更改很重要，但 TLS 1.3 中最重要的變化可能是重新設計了握手協(xié)議。
TLS 1.2 的握手并不是為了保護整個握手過程的完整性而設計的。它只保護 cipher suite negotiation 后的握手部分，這就增加了降級攻擊的可能性，讓攻擊者能強制使用不安全的 cipher suites。
使用 TLS 1.3，服務器會對整個握手過程(包括 cipher suite negotiation)進行簽名，從而防止攻擊者降低 cipher suite 的級別。
同樣，在 TLS 1.2 中，擴展在 ServerHello 中是明文發(fā)送的。現(xiàn)在，在 TLS 1.3 中，甚至連擴展都加密了，ServerHello 后的所有握手消息都加密了。
###減少握手TLS 1.2 支持許多密鑰交換算法、cipher suites 和數(shù)字簽名，包括易受攻擊的數(shù)字簽名。因此，它執(zhí)行一次握手需要更多的消息和兩次網(wǎng)絡往返。
相比之下，TLS 1.3 中的握手現(xiàn)在只需要一次往返，它簡化了設計，去掉了所有易受攻擊的算法。
此外，它還有一個針對重新握手的新特性，稱為 0-RTT 或 TLS 早期數(shù)據(jù)。這讓應用程序可以在初始握手消息中包含應用程序數(shù)據(jù)，而不必等到握手完成。
在 Netflix，我們通過高效地恢復 TLS 會話并謹慎地將 0-RTT 用于流數(shù)據(jù)，來減少播放延遲。
A/B 測試結果
基于對 TLS 1.3 的協(xié)議組合分析，我們確信它會給我們帶來更好的安全性，但是，我們不知道它在流媒體環(huán)境下的效果如何。
由于 TLS 1.3 的性能特性是支持重新握手的 0-RTT 模式，所以我們假設 TLS 1.3 將減少延遲。我們不需要再等待握手完成，相反，我們可以更早地發(fā)送媒體數(shù)據(jù) HTTP 請求，并接收媒體數(shù)據(jù)的 HTTP 響應。
為了解 TLS 1.3 在實際應用時的性能，我們做了一個實驗：
用戶帳戶：每個組 50 萬個帳戶
設備類型：中端設備(Quad ARM core @ 1.7GHz)
對照組：TLS 1.2
實驗組：TLS 1.3
播放延遲
播放延遲是指需要多少時間才開始播放。以下是在實驗中測得的播放延遲數(shù)據(jù)。結果表明，在較慢或擁塞的網(wǎng)絡中(即分位數(shù)大于 0.75)，TLS 1.3 的增益最大，并且在所有的網(wǎng)絡條件下都有所改善。
下面是實驗所用的中端設備在實際應用中的時序平均播放延遲圖。從中可以看出，使用 TLS 1.3 播放開始得更早。
Media Rebuffer(媒體重新緩沖)
在 Netflix，我們將媒體重新緩沖定義為非網(wǎng)絡起點的重新緩沖。其發(fā)生通常是由于 CPU 的負載過高導致設備處理媒體數(shù)據(jù)的速度不夠快。與對照組使用的 TLS 1.2 相比，使用 TLS 1.3 的實驗組在媒體重新緩沖方面提高了大約 7.4%。
這個結果表明，使用 TLS 1.3 和 0-RTT 更高效，可以減少 CPU 負載。
小 結
此時，互聯(lián)網(wǎng)正經(jīng)歷著比平時更高的流量和擁堵。我們相信，即使節(jié)省少量的數(shù)據(jù)和網(wǎng)絡往返也很有意義，如果它還能提供更安全、更高效的流媒體體驗，那就更好了。
因此，我們已經(jīng)開始在比較新的消費類電子設備上部署 TLS 1.3，希望不久的將來可以部署到更多的設備上。
關鍵詞： Netflix
