TLS擴展于2003年以一個獨立的規范（RFC3456)被提出，之后被加入到TLS1.1和TLS1.2的版本中。它主要用于聲明協議對某些新功能的支持，或者攜帶在握手進行中需要的額外數據。TLS擴展機制使得協議在不改變本身基本行為的基礎上增加了額外的功能，因此從出現以來，它就成為協議功能不斷發展的主要載體。
實際使用中，擴展以擴展塊的形式出現在ClientHello和ServerHello消息的最后，例如我們訪問百度網站時，ClientHello數據包如下圖所示，其中Extensions Length之后的字段都是擴展字段。在這一講中，我們對這些比較常見的擴展進行詳細的介紹。
如上圖所示，各個擴展以擴展塊的形式并列出現。而每個擴展都以兩個字節的表明擴展類型的字段開始，后面接著擴展的數據。
Extension extensions;
struct {
ExtensionType extension_type;
opaque extension_data;
} Extension;
全部的擴展類型可以在IANA的網站看到，擴展數據的格式以及對TLS協議的影響由各個擴展的規范來規定。這里我們主要介紹實際中比較常見的一些擴展。下表列出了我們接下來要介紹的一些擴展名稱以及對其功能的簡單介紹。
| 類型 | 擴展名稱 | 功能描述 |
|---|---|---|
| 0xff01 | renegotiation_info | 表明可以支持安全的重協商 |
| 0x00 | server_name | 表明連接中要訪問的virtual hostname |
| 0x23 | session_ticket | 表明支持沒有狀態的會話恢復 |
| 0x0d | signature_algorithms | 表明支持的簽名算法和哈希函數對 |
| 0x05 | status_request | 表明支持OCSP Stapling |
| 0x3374 | next_protocol_negotiation | 表明支持NPN |
| 0x12 | signed_certificate_timestamp | 表明證書已通過Certificate Transparency公開 |
| 0x10 | application_layer_protocol_negotiation | 表明支持的應用層協議 |
1.安全重協商
在介紹renegotiation_info這個擴展之前，我們對TLS重協商機制進行簡單的描述。正常的TLS連接以握手開始，在交換數據之后關閉連接。但若通信過程中雙方有一方請求重協商，那么會再發生一次握手以協商出新的通信安全參數。重協商可能會在以下幾種情況中出現：
協議規定客戶端可以在任何時候發起重協商，只需發送一個新的ClientHello消息。如果服務器想要重協商，則向客戶端發送一個HelloRequest消息，告訴客戶端停止發送加密數據并且發起一次新的握手。
最初設計的重協商機制無法抵御如下圖所示的中間人攻擊。攻擊者可以在客戶端連接的開始注入任意的明文，無法保證TLS傳輸數據的完整性。
renegotiation_info擴展的提出就是為了阻止這種中間人攻擊，保證重協商是發生在之前已完成握手的雙方之間。一次由客戶端發起的重協商如下圖所示，在第一次握手中ClientHello消息中包含一個沒有數據的renegotiation_info擴展，表明客戶端支持重協商，服務器在ServerHello中也包含一個沒有數據的renegotiation_info擴展表明支持，并且在握手協商完成后，雙方將Finished消息中的verify_data存在本地。之后客戶端要發起重協商時，發送一個包含客戶端verify_data擴展的ClientHello消息到服務器，服務器回復一個包含客戶端和服務器verify_data重協商擴展的ServerHello消息表明愿意重協商上一次的握手，之后重新協商通信安全參數。
對于不支持擴展的SSL3，客戶端可以在密碼套件列表中加入TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0xff)表明對重協商的支持。
2.Server Name Indication（SNI）
SNI提供了一種機制，可以讓客戶端指明它想要連接的服務器的名稱。也就是說server_name這個擴展提供了對虛擬服務器的支持，可以讓服務器在眾多虛擬主機中找到相應的證書。比如一臺服務器中有兩個虛擬主機，分別是alipay.com和baidu.com，若客戶端不指明其要訪問的主機名，則服務器無法判斷應該回復支付寶還是百度的證書，那么一個IP地址就只能有一個證書。
3.Session Tickets
Session Tickets提供了一種新的會話恢復機制。在介紹session_ticket這個擴展之前，我們還是先對會話恢復進行簡單地描述。之前介紹的SSL握手的全部過程需要客戶端和服務器的兩輪交互，其中的密碼學操作通常需要密集的CPU處理，且基于客戶端和服務器證書驗證的身份認證還要更多的操作，因此開銷相對較大。而這種開銷可以通過恢復之前的會話來避免。
原本的會話恢復是基于客戶端和服務器在第一次握手完成后保存相關的會話安全參數。在第一次握手中，服務器若想在之后恢復這個會話，則在ServerHello消息中包含一個Session ID。之后若客戶端想要恢復這個會話，則在ClientHello中包含這個Session ID，服務器在ServerHello中回復相同的Session ID表明同意恢復會話，雙方根據上次握手中的master secret計算本次的密鑰，之后互發Finished消息完成握手。這種握手只需要一輪交互，大大縮短了握手開銷。
而通過Session Tickets引入的這種會話恢復機制，則不需要服務器端存儲任何數據。服務器只需將恢復會話所需的信息加密以ticket的形式發送給客戶端。在第一次握手中，session ticket包含在New Session Ticket消息中發給客戶端。
在客戶端想要恢復前面的某一會話時，就在ClientHello中包含那次會話的Session Ticket，服務器決定接收后發送ServerHello并繼續發送ChangeCipherSpec。
4.簽名算法
signature_algorithms這個擴展是在TLS1.2中定義的，用于表明客戶端支持的簽名和哈希算法。這個擴展可有可無，若沒有，則服務器從客戶端提供的密碼套件列表里推斷支持的簽名算法（比如RSA密碼套件就表明支持RSA簽名算法），而直接假設支持的哈希算法是SHA1.
5.OCSP Stapling
status_request這個擴展用于表明客戶端支持OCSP stapling。OCSP是一個檢查證書吊銷信息的協議，OCSP stapling機制可以使服務器向客戶端發送最新的證書吊銷信息，而無需客戶端去訪問CA的證書吊銷列表。
如上圖所示，在客戶端和服務器都表明支持OCSP stapling后，服務器在發送完Certificate消息后緊跟著發送Certificate Status消息，提供關于證書吊銷的必要信息。
6.Certicate Transparency
signed_certificate_timestamp擴展是Certificate Transparency（CT）運用在TLS協議中的一種體現。CT是為改善PKI現狀而提出的一種提議，它將所有證書都記錄下來。CA將其簽發的所有證書都提交給一個公共的log服務器，并收到Signed Certificate Timestamp (SCT)作為提交的證據。在這個擴展機制中，SCT就通過ServerHello的擴展發給服務器。
7.Application Layer Protocol Negotiation(ALPN)
application_layer_protocol_negotiation擴展可以讓通信雙方協商運行在TLS連接之上的應用層協議，比如SPDY，HTTP2.0等。客戶端在ClientHello中包含擴展字段，里面的內容是其支持的協議列表，服務器在ServerHello中回復的擴展字段包含其選擇的協議。
值得注意的是客戶端支持的協議列表和服務器最終選擇的結果都沒有被加密，任何可以看到流量的中間人都可以得知這些信息。
8.Next Protocol Negotiation(NPN)
next_protocol_negotiation擴展是為了支持NPN機制而引入的。而NPN是谷歌為了推廣SPDY的應用，解決防火墻問題和代理問題的前提下提出的。
與ALPN基本類似，只不過NPN為了保護最終的選擇結果，這個信息是加密傳送的，也就是說在ChangeCipherSpec后發送，這就需要引入一個新的消息NextProtocol。由于需要引入新的握手消息，并且選擇結果不被中間的設備看到可能會有問題，因此TLS working group拒絕了這一方案，而是采用了ALPN。
本講介紹了TLS協議的幾個常見擴展，希望對大家在深入理解TLS協議以及深入分析SSL數據包方面有所幫助。
注：本文涉及的基本知識來源于《BulletProof SSL and TLS》，這是一本講SSL很好的教材，推薦給大家。另本文內容是作者在教材內容的基礎上結合自己的理解及具體數據包分析寫作完成的，特此聲明。