HTTPS那些協議：TLS, SSL, SNI, ALPN, NPN
如今 HTTPS 已經普遍應用了，在帶來安全性的同時也確實給 Web 引入了更多復雜的概念。這其中就包括一系列從沒見過的網絡協議。現在 Harttle 從 HTTPS 的原理出發，嘗試以最通俗的方式來解讀 HTTPS 涉及的這些協議。
HTTPS 概要
HTTPS 是建立在安全通信之上的 HTTP，使用傳輸層加密(TLS 或 SSL)的手段。其目的是保護用戶隱私(比如防止經過的網絡節點截獲 HTTP 內容)和數據完整性(比如運營商強插廣告)，就是端到端加密來防止中間人攻擊。
TLS/SSL 是在傳輸層之上應用層之下的協議，因此 HTTP 協議的內容不受影響。這些加密采用非對稱加密算法因此需要一個官方來發布公鑰，這就是 密鑰基礎設施(CA)。因此各瀏覽器會內置一些 CA 的根證書，這些 CA 可以進一步授權其他的域名，這樣你的瀏覽器就可以對正在訪問的域名進行身份認證。
如果你要自己的服務也支持 HTTPS 去 CA 注冊自己的域名就可以了。有一些免費的 CA 比如 GoDaddy, Let’s Encrypt, CloudFlare 等可以選擇。
HTTPS 交互示例
以下 Wireshark 日志記錄了一個發往 https://github.com/harttle 的 GET 請求，可以看到主要的幾個協議的交互過程：
- TCP。前三行完成一對 SYN/ACK(即俗稱的三次握手)，至此 TCP 連接已經成功建立。
- TLS。4-5 行開始了 TLS 握手，建立這個加密層。
- TLS 有眾多擴展協議比如 SNI，NPN，ALPN 等(見下文)，就發生在 TLS 的 ClientHello 和 ServerHello 階段。
TLS/SSL
TLS 的前身是 SSL，TCP/IP 協議棧中運行在 TCP 之上，用來交換密鑰并形成一個加密層(Record Layer)。 TLS 是 HTTPS 的核心協議，HTTPS 交互與 HTTP 交互的主要區別就在這一層：
開始傳輸密文前需要進行互換密鑰、驗證服務器證書等準備工作，因此 TLS 也存在握手階段，主要步驟為：客戶端發送 ClientHello，服務器發送 ServerHello，服務器繼續發送 Certificate，然后互相發送 KeyExchange 消息，最后發送 ChangeCipherSpec 來通知對方后續都是密文。具體交互和協議字段請參考 RFC 5246(TLSv1.2)和 RFC 6176(TLSv2.0)。
TLS 作為 TCP/IP 協議棧中的加密協議有廣泛的用途，為支持通用機制的協議擴展，定義了 RFC 4366 - TLS Extensions。 TLS 先后被郵件服務、Web 服務、FTP 等采用，這里有一個 擴展協議列表。
本文關注其中 Web 服務(HTTPS)相關的擴展，如 SNI, NPN, ALPN。這些協議通過擴展 TLS 的 ClientHello/ServerHello 消息為 TLS 增加新的功能。為此我們先看一下 ClientHello 消息的結構(ServerHello 類似)：
- struct {
- ProtocolVersion client_version;
- Random random;
- SessionID session_id;
- CipherSuite cipher_suites<2..2^16-2>;
- CompressionMethod compression_methods<1..2^8-1>;
- select (extensions_present) {
- case false:
- struct {};
- case true:
- Extension extensions<0..2^16-1>;
- };
- } ClientHello;
注意最后一個字段，最多可以有 65536 個 Extension，其中 Extension 定義為一個兩字節的 ExtensionType 以及對應的不透明數據。下文的 SNI，NPN，ALPN 都是其中之一。
SNI
SNI(Server Name Indication)指定了 TLS 握手時要連接的 主機名。 SNI 協議是為了支持同一個 IP(和端口)支持多個域名。
因為在 TLS 握手期間服務器需要發送證書(Certificate)給客戶端，為此需要知道客戶請求的域名(因為不同域名的證書可能是不一樣的)。這時有同學要問了，要連接的主機名不就是發起 HTTP 時的 Host 么!這是對 HTTPS 機制的誤解，TLS Handshake 發生時 HTTP 交互還沒開始，自然 HTTP 頭部還沒到達服務器。SNI 協議就定義在 RFC 6066 中：
- struct {
- NameType name_type;
- select (name_type) {
- case host_name: HostName;
- } name;
- } ServerName;
- enum {
- host_name(0), (255)
- } NameType;
- opaque HostName<1..2^16-1>;
- struct {
- ServerName server_name_list<1..2^16-1>
- } ServerNameList;
我們看本文剛開始的例子，第4行發往 github.com 的 ClientHello 中的 SNI Extension 字段：
- Extension Header || Extension Payload (SNI)
- ---------------------------------------------------------------------------------------------------
- ExtensionType Length || PayloadLength Type ServerLength ServerName
- ---------------------------------------------------------------------------------------------------
- 00 00 00 0f 00 0d 00 00 0a 67 69 74 68 75 62 2e 63 6f 6d
- sni(0) 15 || 13 host_name 10 github.com
ALPN/NPN
ALPN(Application-Layer Protocol Negotiation)也是 TLS 層的擴展，用于協商應用層使用的協議。它的前身是 NPN，最初用于支持 Google SPDY 協議(現已標準化為 HTTP/2)。 TLS 客戶端和服務器版本的問題，導致 SPDY->HTTP/2 和 NPN -> ALPN 的切換過程引發了不少陣痛：
- The day Google Chrome disables HTTP/2
- 從啟用 HTTP/2 導致網站無法訪問說起
因此 以標準先行的方式來推進 Web 基礎設施 已成為今日 Web 平臺的共識。這里我們不提那些仍然在進行作坊式生產的(類)瀏覽器廠商，任何阻擋 Web 平臺發展的實現(甚至標準，試看 XHTML, OSI…)遲早會被淘汰。
言歸正傳，ALPN 定義在 RFC 7301 - Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension，
- enum {
- application_layer_protocol_negotiation(16), (65535)
- } ExtensionType;
- opaque ProtocolName<1..2^8-1>;
- struct {
- ProtocolName protocol_name_list<2..2^16-1>
- } ProtocolNameList;
我們看本文剛開始的例子，第4行發往 github.com 的 ClientHello 中的 ALPN Extension 字段：
- Extension Header || Extention Payload (ALPN)
- ---------------------------------------------------------------------------------------------------
- ExtensionType Length || PayloadLength StringLength Protocol StringLength Protocol
- ---------------------------------------------------------------------------------------------------
- 00 10 00 0e 00 0c 02 68 32 08 68 74 74 70 2f 31 2e 31
- alpn(16) 14 || 12 2 h2 8 http/1.1
Extention 的消息體包含多個字符串(protocol_name_list)，表示客戶端支持的所有應用層協議。上面的例子中有 h2 和 http/1.1 兩個，支持 SPDY 的客戶端這里會多一個 spdy/2。服務器給出的 ServerHello 中需要選擇其中之一，本文的例子中 ServerHello 的 ALPN 字段為：
- 00 10 00 0b 00 09 08 68 74 74 70 2f 31 2e 31
- h t t p / 1 . 1
這樣 Server 和 Client 就利用 ALPN 協議達成了共識，將會在握手結束后使用 HTTP/1.1 協議進行通信。
參考和致謝
從 HTTPS 的關鍵一層 TLS 開始，介紹了一個典型的 HTTPS 交互過程。結合抓包給出的字節序列，依次介紹了 TLS、SNI、ALPN 等協議原理和主要內容。
