前言

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

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

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

加密：混淆數(shù)據的機制。

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

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

2.TLS握手

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

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

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

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

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

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

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

應用層協(xié)議協(xié)商

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

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

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

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

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

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

服務器名稱指示

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

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

3.TLS會話恢復

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

會話標識符

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

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

會話記錄單

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

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

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

4.證書頒發(fā)與撤銷

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.TLS記錄協(xié)議

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

記錄協(xié)議接收到應用數(shù)據；

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

數(shù)據壓縮（可選）；

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

使用協(xié)商的加密算法加密數(shù)據。

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

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

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

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

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

6.TLS優(yōu)化

計算成本

盡早完成（握手）

會話緩存與無狀態(tài)恢復

TLS記錄大小

TLS壓縮

證書鏈的長度

OCSP封套

HTTP嚴格傳輸安全
編輯：hfy