前言

由于在TCP、UDP等方式傳輸數據時，數據包有可能被其他人截獲，并解析出信息，這就給信息安全帶來了很大的挑戰。最初的SSL協議被網景公司提出，它不會影響上層協議(如HTTP、電子郵件等)，但可以保證上層協議的通信安全。如果正確的使用SSL，第三方只能推斷連接的兩端地址、加密類型，以及數據頻率和發送的大概數據量，但無法讀取或修改任何實際數據。IETF后來在標準化SSL協議時，將其改為了TLS。很多人會混用SSL與TLS，但嚴格來說它們指代的協議版本不同（SSL3.0的升級版才是TLS1.0）。本文重在講述TLS的概念和原理及其網絡優化。

1.加密、身份驗證與完整性

TLS協議的目標是為信息傳輸提供三個基本的保證：加密、身份驗證和數據完整性。這三種服務并不是必須的，可以根據具體的應用場景進行選擇。

加密：混淆數據的機制。

身份驗證：驗證身份標識有效性的機制。

完整性：檢測消息是否被篡改或偽造的機制。

2.TLS握手

客戶端與服務器在通過TLS交換數據之前，必須協商建立加密信道。協商內容包括：TLS版本、加密套件，必要時還要驗證證書。其每次協商，都需要在客戶端和服務端往返，大致過程如下：

0 ms：TLS運行在TCP基礎之上，這意味著我們必須首先完成TCP 三次握手“ ，這需要一個完整的來回交互(RTT)。

56 ms：TCP連接建立后，客戶端發送一些協商信息，如TLS協議版本，支持的密碼套件的列表，和其他TLS選項。

84 ms：服務器挑選TLS協議版本，在加密套件列表中挑選一個密碼套件，附帶自己的證書，并將響應返回給客戶端。可選的，服務器也可以發送對客戶端的證書認證請求和其他TLS擴展參數。

112 ms：假設雙方協商好一個共同的TLS版本和加密算法，客戶端使用服務器提供的證書，生成新的對稱密鑰，并用服務器的公鑰進行加密，并告訴服務器切換到加密通信流程。到現在為止，所有被交換的數據都是以明文方式傳輸，除了對稱密鑰外，它采用的是服務器端的公鑰加密。

140 ms：服務器用自己的私鑰解密客戶端發過來的對稱密鑰，并通過驗證MAC檢查消息的完整性，并返回給客戶端一個加密的“Finished”的消息。

168 ms：客戶端采用對稱密鑰解密消息，并驗證MAC，如果一切OK，加密隧道就建立好了。應用程序數據就可以發送了。

應用層協議協商

理論上，兩個網絡節點可能使用一個自定義的應用程序協議進行互相通信。解決這個問題的方法之一是在確定協議的前期，給它分配一個眾所周知的端口（例如，端口80用于HTTP，TLS的端口443），并配置所有客戶端和服務器使用它。然而，在實踐中，這是一個緩慢和不切實際的過程：每個端口的分配必須批準，更糟的是防火墻及其他中間服務器往往只允許使用80和443進行通信。為了簡化自定義協議的部署，需要重用80或443端口，再通過額外的機制協商確定協議。80端口被保留用于HTTP，HTTP規范提供了一個特殊的Upgrade流程來完成這個目標。然而，使用Upgrade可能帶來額外的網絡往返延遲，并在實際應用中往往因為許多中間服務器的存在是不可靠的。

既然80端口不太適合用來協商協議，那就使用443端口，這是給安全HTTPS會話保留的。端到端的加密隧道對中間設備模糊了數據，因此這就成為了一種可以快速和可靠的方式實現和部署任意的應用程序協議。然而，使用TLS解決了可靠性，我們仍然需要一種方式來協商應用協議！作為HTTPS會話，當然可以復用了HTTP的Upgrade機制來協商，但這會帶來一個額外完整的往返延遲（RTT）。如果在把TLS握手的同時協商確定協議可行嗎？

應用層協議談判（ALPN）是一個TLS擴展，支持在TLS握手過程中進行協議協商，從而省去通過HTTP的Upgrade機制所需的額外往返延遲。過程如下：

客戶在ClientHello消息添加新的ProtocolNameList字段，包含支持的應用程序協議列表。

該服務器檢查ProtocolNameList字段，并在ServerHello消息中返回一個ProtocolName字段，用來指示服務器端選擇的協議。

服務器可能只響應其中一個協議，如果它不支持任何客戶端要求的協議，那么它可能選擇中止連接。其結果是，TLS握手完成后，安全隧道建立好了，客戶端和服務端也協商好了所使用的應用協議 - 它們可以立即開始通信。

服務器名稱指示

任意兩個TCP端之間都可以建立加密的TLS隧道：客戶端只需要知道對端的IP地址就可以建立連接，并執行TLS握手。但是，如果服務器需要部署多個獨立的網站，每個與自己的TLS證書，但使用同一個IP地址 - 請問如何處理？為了解決上述問題，SNI（服務器名稱指示）擴展被引入到TLS協議中，它允許客戶端在握手開始指示他想要連接的主機名。服務器檢查SNI主機名，選擇適當的證書，并繼續握手。

注：TLS + SNI工作流程和HTTP的Host頭域宣告流程是相同的，客戶端在頭域中指示它要請求的Host：同一IP地址可能會部署許多不同domain，SNI和Host都是用來區分不同的Host或者Domain。

3.TLS會話恢復

完整的TLS握手需要額外延遲和計算，為所有需要安全通信的應用帶來了嚴重的性能損耗。為了幫助減少一些性能損耗，TLS提供恢復機制，即多個連接之間共享相同的協商密鑰數據。

會話標識符

“會話標識符”（RFC 5246）恢復機制在SSL 2.0中首次被引入，支持服務器端創建32字節的會話標識符，并將其作為“ServerHello”消息的一部分進行發送。在服務器內部，服務器保存一個會話ID和其對應的協商參數。對應地，客戶端也同時存儲會話ID信息，在后續的會話中，可以在“ClientHello”消息中攜帶session ID信息，告訴服務器客戶端還記著session ID對應的密鑰和加密算法等信息，并且可以重用這些信息。假設在客戶端和服務器都能在它們各自的緩存中找到共享的會話ID參數，那么就可以縮減握手了，如下圖所示。否則，開始一個新的會話協商，生成新的會話ID。

借助會話標識符，我們能夠減少一個完整的往返，以及用于協商的共享密鑰的公鑰加密算法開銷。這讓我們能快速的建立安全連接，而不損失安全性。然而，“會話標識符”機制的一個限制就是要求服務器為每個客戶端創建和維護一個會話緩存。這會為服務器上帶來幾個問題，對于一些每天同時幾萬，甚至幾百萬的單獨連接的服務器來說：由于緩存session ID所需要的內存消耗將非常大，同時還有session ID清除策略的問題。這對一些流量大的網站來說不是一個簡單的任務，理想的情況下，使用一個共享的TLS會話緩存可以獲得最佳性能。上述問題沒有是不可能解決的，許多高流量的網站成功的使用了會話標識符。但是，對任何多服務主機的部署，會話標識符方案需要一些認真的思考和好的系統架構，以確保良好的的會話緩存。

會話記錄單

由于在服務器訪問量很大的情況下，緩存會話信息是一個很大的負擔，為消除服務器需要維護每個客戶端的會話狀態緩存的要求，“Sesion Ticket”機制被引入--服務器端不再需要保存客戶端的會話狀態。如果客戶端表明它支持Session Ticket，則在服務器完成TLS握手的最后一步中將包含一個“New Session Ticket”信息，這個信息包含一個加密通信所需要的信息，這些數據采用一個只有服務器知道的密鑰進行加密。這個Session Ticket由客戶端進行存儲，并可以在隨后的會話中添加到ClientHello消息的SessionTicket擴展中。因此，所有的會話信息只存儲在客戶端上，Session Ticket仍然是安全的，因為它是由只有服務器知道的密鑰加密的。

會話標識符和會話記錄單機制，通常分別被稱為“會話緩存”和“無狀態恢復”機制。無狀態恢復的主要改進是消除服務器端的會話緩存，從而簡化了部署，它要求客戶在每一個新的會話開始時提供Session Ticket，直到Ticket過期。

注：在實際應用中，在一組負載平衡服務器中部署Session Ticket，也需要仔細考慮：所有的服務器都必須用相同的會話密鑰，或者可能需要額外的機制，定期輪流在所有服務器上的共享密鑰。

4.證書頒發與撤銷

身份驗證是建立每個TLS連接一個重要的組成部分。畢竟，TLS可以與任何端通過一個加密的隧道進行通信，包括攻擊者，除非我們可以確信和我們通信的對方是可信任的，不然所有的加密工作都是無效的。如何證明某個主機是可信的呢？這就需要用證書，只有具有合法證書的主機才是可信。證書的來源有哪些呢？

手動指定的用戶證書：每一個瀏覽器和操作系統都提供了手動導入任何您信任的證書的機制。如何獲得證書，并驗證其完整性完全取決于你。

證書頒發機構 ：證書頒發機構（CA）是一個值得信賴的第三方的機構（所有者），其證書值得信任。

瀏覽器和操作系統：每個操作系統和大多數瀏覽器都包含了知名的證書頒發機構的列表。因此，你也可以信任這個軟件的供應商，提供并維護的信任列表。

在實際應用中，手動驗證為每一個網站的證書（盡管你可以，如果你是這樣的傾向）是不切實際。因此，最常見的解決方案是借助證書頒發機構（CA）做這項工作（如下圖） ：在瀏覽器中指定哪些CA是可信任（根CA證書），CA負責驗證你訪問的每個網站，并進行審核，以確認這些證書沒有被濫用或受損害。如果任何網站違反了CA的證書的安全性規定，那么CA有責任撤銷其證書。

偶爾證書的頒發機構可能需要撤銷或作廢證書，這可能由于證書的私鑰被攻破了，證書頒發機構本身被攻破，或者其他一些正常的原因譬如證書替換、證書簽發機構發生變化，等等。為了解決這個問題，證書本身包含了檢查是否已吊銷的邏輯。因此，為了確保信任鏈不會受到攻擊影響，每個節點都可以檢查每個證書的狀態，連同簽名。

證書撤銷名單（CRL）：每個證書頒發機構維護并定期發布一份吊銷證書序列號列表。要想驗證證書的可靠性，直接查詢CRL名單即可。

CRL文件本身可以定期公布，或在每次更新時都公布，CRL文件可以通過HTTP，或任何其他文件傳輸協議傳輸。該名單也是由CA簽名，通常允許以指定的時間間隔緩存。在實際應用中，這個流程運行得很好，但也有一些場景CRL機制可能存在缺陷：

越來越多的撤銷意味著CRL列表只會越來越長，每個客戶端必須獲取整個序列號列表

沒有證書吊銷即時通知機制 - 如果在客戶端緩存期間，證書被吊銷，客戶端將認為證書是有效的，直到緩存過期。

在線證書狀態協議（OCSP）：提供一種實時檢查證書狀態的機制，支持驗證端直接查詢證書數據庫中的序列號，從而驗證證書是否有效。

OSCP占用帶寬更少，支持實時驗證，也帶來了一些問題。如下：

CA必須能夠處理實時查詢的實時性和負荷。

CA必須確保該服務在任何時候全球都可用。

客戶端在進行任何協商前都必須等待OCSP請求。

因為CA知道哪些網站的客戶端訪問，實時的OCSP請求可能暴露客戶的隱私。

5.TLS記錄協議

TLS記錄協議主要用來識別TLS中的消息類型（通過“Content Type”字段的數據來識別握手，警告或數據），以及每個消息的完整性保護和驗證。交付應用數據的典型流程如下：

記錄協議接收到應用數據；

數據分塊，每個塊最大2^14即16 KB；

數據壓縮（可選）；

添加消息認證碼（MAC）或HMAC（用于驗證消息的完整性和可靠性）；

使用協商的加密算法加密數據。

一旦上述步驟完成后，加密的數據被向下傳遞到TCP層進行傳輸。在接收端，采用反向相同的工作流程：使用協商的加密算法對數據進行解密，驗證MAC，提取的應用數據給應用層。另一個好消息，所有上述的處理都是TLS層本身處理，對大多數應用程序是完全透明的。

當然，TLS記錄協議也帶來了一些重要限制：

TLS記錄的最大大小為16KB；

每個記錄包含一個5字節的頭部，MAC（SSLv3，TLS 1.0，TLS 1.1最多20個字節，TLS 1.2的多達32個字節），如果采用塊加密算法則還有填充塊（padding）；

為了解密和驗證每一塊數據，必須保證所有數據都已收到。

6.TLS優化

計算成本

盡早完成（握手）

會話緩存與無狀態恢復

TLS記錄大小

TLS壓縮

證書鏈的長度

OCSP封套

HTTP嚴格傳輸安全
編輯：hfy