CIAA網(wǎng)絡(luò)安全模型與TLS / HTTPS協(xié)議（下）

SSL/TLS

SSL（Secure Sockets Layer，安全套接層）協(xié)議最初由 Netscape（網(wǎng)景公司）在 1994 年設(shè)計(jì)并開發(fā)，為了給 HTTP 提供一個(gè)安全的傳輸層。

到 1999 年，因?yàn)?SSL 應(yīng)用廣泛，已經(jīng)成為 Internet 上的事實(shí)標(biāo)準(zhǔn)。所以 IETF（Internet Engineering Task Force，互聯(lián)網(wǎng)工程任務(wù)組）在 SSL 的基礎(chǔ)上將其標(biāo)準(zhǔn)化為 TLS（Transport Layer Security，傳輸層安全協(xié)議）協(xié)議。

目前，我們最常見的是 TLS v1.2 版本，而最新的 v1.3（2018 年，RFC8446）版本有望成為有史以來最安全，但也最復(fù)雜的 TLS 協(xié)議。 ?

TLS 1.2

TLS 協(xié)議是 CIAA 網(wǎng)絡(luò)安全模型的具體實(shí)現(xiàn)，基于混合加密方案和 PKI/CA 數(shù)字證書技術(shù)制定了一套安全通信協(xié)議標(biāo)準(zhǔn)，所以理解 TLS 協(xié)議之前需要先對(duì) CIAA 安全模型有一定的認(rèn)識(shí)。

TLS 主要由 2 個(gè)部分組成：

TLS 記錄數(shù)據(jù)（TLS Record）：是一種數(shù)據(jù)結(jié)構(gòu)，用于將應(yīng)用層協(xié)議的數(shù)據(jù)分割成多個(gè) TLS Records。數(shù)據(jù)結(jié)構(gòu)的概覽如下圖所示：

?

TLS 握手協(xié)議（TLS Handshake）：是一種協(xié)議，用于在 TLS 通信的初始階段進(jìn)行身份驗(yàn)證和協(xié)商安全參數(shù)。協(xié)議處理流程如下圖所示：

?

協(xié)議交互抓包示例如下圖所示：

client_hello

當(dāng) TCP 連接建立后，TLS 握手的第一步由 Client 發(fā)起，發(fā)送 ClientHello Msg 到 Server。

Client Hello Msg 包含以下內(nèi)容：

Client 支持的 TLS 版本。

Client 支持的 Cipher Suites（加密套件候選列表）。

Compression Methods（壓縮算法候選列表）。

Extensions（擴(kuò)展字段）。

Client Random（隨機(jī)數(shù)），用于后續(xù)的對(duì)稱密鑰協(xié)商。

可選的 Session ID，用于支持 TLS 會(huì)話恢復(fù)。如果提供了，那么 Server 會(huì)復(fù)用對(duì)應(yīng)的握手信息，避免短時(shí)間內(nèi)重復(fù)握手。

server_hello + server_certificate + sever_hello_done

Server 收到了 ClientHello Msg 后，比對(duì) Server 支持的 TLS 版本和 Cipher Suites，然會(huì)回復(fù) ServerHello Msg，以此來完成 Cipher Suites 協(xié)商階段。

Server Hello Msg 包含以下內(nèi)容：

Server 所能支持的最高 TLS 版本。

Server 選擇使用的 Cipher Suites（加密套件）。例如：Nginx 的 ssl_ciphers HIGH!MD5;配置項(xiàng)。

Server 選擇使用的 Compression Method（壓縮算法）。

Server Random（隨機(jī)數(shù)），用于后續(xù)的對(duì)稱密鑰協(xié)商。

可選的 Session ID，用于支持 TLS 會(huì)話恢復(fù)。如果提供了，則 Client 會(huì)復(fù)用當(dāng)前握手的信息，避免短時(shí)間內(nèi)重復(fù)握手。

可選的 Session ID 會(huì)話恢復(fù)，是指在一次完整協(xié)商的連接斷開時(shí)，Client 和 Server 都會(huì)將 TLS Session 協(xié)商的安全參數(shù)保留一段時(shí)間，用于后續(xù)的會(huì)話恢復(fù)，起到類似 Cache 的功能。希望恢復(fù)會(huì)話的 Client 需要將相應(yīng)的 Session ID 放入 Client Hello Msg 發(fā)出。如果 Server 愿意恢復(fù)會(huì)話，則將相同的 Session ID 放入 Server Hello Msg 返回。

Server Certificate Msg 包含以下內(nèi)容：

Server 的 CA 證書，該證書由 CA 簽發(fā)，是一個(gè)由 CA 背書的 Server “公鑰“。

在雙向安全認(rèn)證場(chǎng)景中，Client 也需要提供它的 CA 證書，還需要包含 Client Certificate Request（客戶端證書請(qǐng)求）。

Server Hello Done Msg：向 Client 發(fā)送 Server Hello Done 表示 Hello 協(xié)商階段完成。

Certificate authentication

Client 收到 Server Hello Msg 后，會(huì)對(duì)收到的 Server CA 證書進(jìn)行合法性驗(yàn)證。只有通過驗(yàn)證才會(huì)進(jìn)行后續(xù)通信，否則根據(jù)錯(cuò)誤情況不同做出提示和操作，合法性驗(yàn)證的內(nèi)容包括：

Trusted Certificate Path（證書鏈的可信性）。

Revocation（證書是否已經(jīng)吊銷）：有 2 種方式：離線 CRL 驗(yàn)證、在線 OCSP 驗(yàn)證。不同的 Client 會(huì)采用不同的方式。

Expiry Date（有效期）：證書是否在有效時(shí)間范圍內(nèi)。

Domain（域名）：核查證書域名是否與當(dāng)前的訪問域名匹配。

client_key_exchange + change_cipher_spec + encrypted_handshake_message

Client 完成了 Server CA 證書的合法性驗(yàn)證之后，就可以從 Server CA 證書中得到了 Server Public Key，繼而開始非對(duì)稱加密行為。具體采用的非對(duì)稱加密算法由 Server 選擇的 Cipher Suites 決定，例如：ECDHE。

Client Key Exchange Msg：內(nèi)含了 Client 本地運(yùn)算生成的 Pre-Master 隨機(jī)數(shù)，并用 Server Public Key 加密，然后發(fā)送給 Server，再由 Server Private Key 解密。

此時(shí)，Client 就獲得了混合加密方案所需要的全部通信密鑰信息，包括：

在 C/S 協(xié)商階段獲得的 2 個(gè)明文隨機(jī)數(shù) random_C 和 random_S。

Client 自己生成的加密 Pre-Master 隨機(jī)數(shù)。

用于對(duì)稱加密的 Master Secret 對(duì)稱密鑰，Client 通過 Fuc(random_C, random_S, Pre-Master)計(jì)算得到。使用 3 個(gè)隨機(jī)數(shù)來計(jì)算，一方面為了防止 “random_C” 被中間人猜出，另一方也增加 Master Secret 的隨機(jī)性。

用于非對(duì)稱加密的 Server Public Key。

Change Cipher Spec Msg：Client 通知 Server 后續(xù)的通信都采用協(xié)商的通信密鑰和加密算法進(jìn)行加密通信。

Encrypted Handshake Msg / Finished Msg：TLS v1.2 采用了 MAC（Message authentication code，消息認(rèn)證碼）來確保 Handshake 流程未被篡改。具體的行為是：對(duì) Client 之前已經(jīng)發(fā)送過的所有 Msgs，再次使用協(xié)商好的 Master Secret 對(duì)稱密鑰進(jìn)行 HASH 計(jì)算得到數(shù)字摘要，最后發(fā)送給 Server 用于最后的安全握手驗(yàn)證。

change_cipher_spec + encrypted_handshake_message

Server 收到 Client Key Exchange Msg 后，使用 Server Private Key 解密得到 Client 的 Pre-Master 隨機(jī)數(shù)，并基于之前交換的兩個(gè)明文隨機(jī)數(shù) random_C 和 random_S，同樣可以計(jì)算出協(xié)商 Master Secret 對(duì)稱密鑰。

Server 收到 Encrypted Handshake Msg 后，同樣通過協(xié)商好的加密算法進(jìn)行解密，然后再對(duì) Server 收到的所有 Msgs 使用同樣的 Master Secret 對(duì)稱密鑰進(jìn)行一次數(shù)字摘要計(jì)算。

最后通過對(duì)比數(shù)據(jù)簽名，來最終驗(yàn)證數(shù)據(jù)的完整性。如果失敗，則觸發(fā)致命的 Alert 異常：Bad Record MAC（Message authentication code，消息認(rèn)證碼），表示安全通道建立過程中有惡意篡改行為。

Change Cipher Spec Msg：驗(yàn)證通過之后，Server 同樣發(fā)送該消息以告知 Client 后續(xù)的通信都采用協(xié)商的通信密鑰與算法進(jìn)行加密通信。

Encrypted Handshake Msg / Finished Msg：Server 也會(huì)以同樣的方式計(jì)算出數(shù)字簽名并發(fā)送給 Client。

至此，Client 和 Server 雙方都擁有了合法的 Master Secret 對(duì)成密鑰，接下來進(jìn)入到業(yè)務(wù)數(shù)據(jù)的對(duì)稱加密安全傳輸階段。整個(gè)過程通常需要幾百毫秒。

TLS 1.3

相對(duì)于 TLS v1.2 而言，v1.3 是迄今為止最大的一次改動(dòng)，主要的改進(jìn)目的如下：

更強(qiáng)的安全性：進(jìn)一步加密握手流程、改善跨協(xié)議攻擊的彈性、刪除不安全的加密算法。

更快的訪問速度：減少握手等待時(shí)間。

引入的新特性如下：

引入了新的 PSK 密鑰協(xié)商機(jī)制。

支持 0-RTT 數(shù)據(jù)傳輸，在建立連接時(shí)節(jié)省了往返時(shí)間。

廢棄了過時(shí)的 3DES、RC4、AES-CBC 等加密組件，以及 SHA1、MD5 等哈希算法。

對(duì) Server Hello Msg 之后的所有握手消息采取了加密操作，可見明文大大減少。

不再允許對(duì)加密報(bào)文進(jìn)行壓縮、不再允許雙方發(fā)起重協(xié)商。

DSA 證書不再允許使用。

目前最新的 Chrome 和 Firefox 都已支持 TLS 1.3，但需要手動(dòng)開啟。下面是各大瀏覽器的 TLS 1.3 支持情況：

更強(qiáng)的安全性

加密了整個(gè) TLS Handshake 握手流程

TLS v1.2 中的 Handshake 流程并沒有實(shí)現(xiàn)完全加密，協(xié)商加密算法類型和隨機(jī)數(shù)階段、以及握手結(jié)束（Encrypted Handshake Msg / Finished Msg）都是明文的，通過對(duì)稱 MAC（Message authentication code，消息認(rèn)證碼）來確保握手未被篡改。

這種疏忽導(dǎo)致了許多備受矚目的安全漏洞（e.g. FREAK、LogJam etc.），所以在 TLS v1.3 中，會(huì)對(duì)整個(gè)握手進(jìn)行非對(duì)稱加密。

?

以最簡(jiǎn)單的 FREAK 攻擊為例，它利用了以下 2 個(gè)漏洞：

許多瀏覽器和服務(wù)器仍然支持 20 世紀(jì) 90 年代的弱密碼（稱為 Export 密碼）。

TLS v1.2 用于協(xié)商使用哪種加密算法的握手部分沒有加密。

使得 FREAK 中間人可以篡改 Client 和 Server 最終選用的 Supported ciphers（加密套件），讓雙方都降級(jí)了加密強(qiáng)度（HIGH => LOW => EXPORT）。然后中間人就可以暴力破解 Encrypted Handshake Message 得到 3 個(gè)隨機(jī)數(shù)，并計(jì)算出 Master Secret 對(duì)稱密鑰信息 ，最終就可以偽造了彼此的 Finished Message，即 MAC 值。如下圖所示。

?

在 TLS v1.3 中，這種類型的安全降級(jí)攻擊是不可能的，因?yàn)檎麄€(gè)握手流程都進(jìn)行了加密，同時(shí) v1.3 還刪除了那些不安全的加密算法，包括：

? RSA 密鑰傳輸：不支持前向安全性。

? CBC 模式密碼：易受 BEAST 和 Lucky 13 攻擊。

? RC4 流密碼：在 HTTPS 中使用并不安全。

? SHA-1 哈希函數(shù)：建議以 SHA-2 取而代之。

?任意 Diffie-Hellman 組：CVE-2016-0701 漏洞。

?輸出密碼：易受 FREAK 和 LogJam 攻擊。

?等等。

使用支持向前保密的臨時(shí) Diffie-Hellman 替代 RSA 加密算法

RSA 非對(duì)稱加密算法是由 Rivest，Shamir 和 Adelman 在 1977 年發(fā)現(xiàn)的，一直都被視為是密碼學(xué)領(lǐng)域的重大成就之一。但現(xiàn)在看來，RSA 存在不滿足前向保密（Forward Secret）的嚴(yán)重缺陷。即：如果中間人記錄存儲(chǔ)了加密對(duì)話數(shù)據(jù)，后面假如某一天中間人通過 Heartbleed（心臟出血）之類的技術(shù)竊取了 Server 的 RSA Private Key，那么中間人依然可以將對(duì)話解密。

因此，TLS 1.3 移除了 RSA，而僅采用了臨時(shí) Diffie-Hellman 作為唯一的秘鑰交換機(jī)制。

臨時(shí) Diffie-Hellman 由 Diffie 和 Hellman 在 1976 年發(fā)明，要求 Client 和 Server 都創(chuàng)建一對(duì)非對(duì)稱密鑰，并且都交換彼此的 Public Key，一旦收到了對(duì)方的 Public Key，那么就會(huì)與自己的 Private Key 進(jìn)行組合，最后以相同的 Pre-Master Secret 值作為結(jié)尾。

所謂 “臨時(shí)”，指的是在每個(gè) TLS 會(huì)話中，協(xié)商密鑰所使用的 Pre-Master Secret 參數(shù)都是臨時(shí)生成的，可以實(shí)現(xiàn)每個(gè)會(huì)話的密鑰唯一。因此，即使在以后的時(shí)間里，攻擊者獲得了以前的臨時(shí)密鑰，也無法利用這些密鑰來破解之前或之后的會(huì)話。即使一個(gè)密鑰被泄漏，也不會(huì)影響其他會(huì)話的安全性。

更快的訪問速度

在 Web 領(lǐng)域，傳輸延遲（Transmission Latency）是重要的性能指標(biāo)之一，低延遲意味著更流暢的頁(yè)面加載以及更快的 API 響應(yīng)速度。而一個(gè)完整的 HTTPS 連接的建立大概需要以下 4 步：

DNS 查詢

TCP 握手（1 RTT）

TLS v1.2 握手 （2 RTT）

建立 HTTP 連接（1 RTT）

可見在 TLS v1.2 中，新建一個(gè)完整的 HTTPS 連接最少需要 4 個(gè) RTT（Round-Trip Time 往返時(shí)延），而重連則可以通過 TLS 的會(huì)話恢復(fù)機(jī)制節(jié)省 1 個(gè) RTT。

? TLS v1.2 新建連接握手流程：

?

? TLS v1.2 會(huì)話恢復(fù)流程（指定了 Hello Msg 的 Session ID）：

?

在 TLS v1.3 中，由于僅支持向前保密的臨時(shí) Diffie-Hellman 對(duì)稱加密算法，所以 Client 可以在一條 Msg 中就完成 Diffie-Hellman 密鑰共享，即：只需要一次往返（ 1-RTT ）就可以完成握手。

? TLS v1.3 新建連接握手流程：



另外，TLS v1.3 在會(huì)話恢復(fù)時(shí)，Client 會(huì)將 Server 發(fā)送過來的 Session Ticket 進(jìn)行計(jì)算，組成一個(gè)新的 PSK （PreSharedKey，預(yù)共享密鑰）。Client 將 PSK 緩存在本地。會(huì)話恢復(fù)時(shí)，在 Client Hello Msg 帶上 PSK 擴(kuò)展，同時(shí)通過之前 Client 發(fā)送的 Finished Msg 計(jì)算出 Resumption Secret（恢復(fù)密鑰）。通過該密鑰加密數(shù)據(jù)發(fā)送給 Server，然后 Server 就會(huì)從 Session Ticket 中算出 PSK，使用它來解密剛才發(fā)過來的加密數(shù)據(jù)。至此完成了該 0-RTT 會(huì)話恢復(fù)的過程。

? TLS v1.3 0-RTT 會(huì)話恢復(fù)流程：

升級(jí) OpenSSL 1.1.1 支持 TLS 1.3

并非所有的 Client 和 Server 都支持相同版本的 TLS，因此大多數(shù) Server 都會(huì)同時(shí)支持多個(gè)版本，并且進(jìn)行協(xié)商。TLS 的版本協(xié)商非常簡(jiǎn)單。Client 會(huì)通知 Server 它支持的協(xié)議的最新版本，Server 則會(huì)回復(fù)支持的協(xié)議版本，如果存在交集則協(xié)商成功。否則，連接失敗。雖然版本協(xié)商的過程很簡(jiǎn)單，但事實(shí)證明，很多連接場(chǎng)景并未能正確地實(shí)現(xiàn)這一功能，從而導(dǎo)致安全事故。

OpenSSL 最新的 1.1.1 版本提供了 TLS 1.3 的支持，而且和 1.1.0 版本完全兼容。在特定的 Linux 發(fā)行版中，可能需要手動(dòng)安裝。

以 CentOS7 為例，檢查是否開啟了 TLS 1.3：

$openssl s_client --help｜ grep tls1_3

如果沒有，則需要手動(dòng)安裝：

下載 OpenSSL 1.1.1 版本

$cd /opt
$wget https://github.com/openssl/openssl/archive/OpenSSL_1_1_1-stable.zip
$unzip OpenSSL_1_1_1-stable.zip

編譯安裝

$./config enable-tls1_3 --prefix=/usr/local/openssl
$make &&makeinstall

配置

$mv /usr/bin/openssl /usr/bin/openssl.old
$mv /usr/lib64/openssl /usr/lib64/openssl.old
$mv /usr/lib64/libssl.so /usr/lib64/libssl.so.old
$ln -s/usr/local/openssl/bin/openssl /usr/bin/openssl
$ln -s/usr/local/openssl/include/openssl /usr/include/openssl
$ln -s/usr/local/openssl/lib/libssl.so /usr/lib64/libssl.so
$echo "/usr/local/openssl/lib">>/etc/ld.so.conf
$ldconfig -v

查看版本并驗(yàn)證

$openssl version
$openssl s_client --help|greptls1_3

HTTPS

HTTPS 就是 HTTP 與 TLS 的組合，本質(zhì)為 HTTP over SSL/TLS。在以往的文章中，我們已經(jīng)分別介紹了 HTTP 和 TLS 協(xié)議，所以在這里主要關(guān)注 HTTPS 的 2 種安全認(rèn)證方式，并梳理 HTTPS 連接建立流程。

測(cè)試網(wǎng)站是否開啟了 TLS 1.3：

$git clone --depth1 https://github.com/drwetter/testssl.sh.git
$cd testssl.sh
$./testssl.sh -p

Testingprotocols via sockets except NPN+ALPN

SSLv2not offered (OK)
SSLv3not offered (OK)
TLS1 offered
TLS1.1 offered
TLS1.2 offered (OK)
TLS1.3 offered (OK):draft 28, draft 27, draft 26
NPN/SPDYh2, spdy/3.1, http/1.1 (advertised)
ALPN/HTTP2h2, spdy/3.1, http/1.1 (offered)

HTTPS 單向認(rèn)證

Client 向 Server 發(fā)送 TLS 協(xié)議版本號(hào)、加密算法種類、隨機(jī)數(shù)等信息。

Server 給 Client 返回 TLS 協(xié)議版本號(hào)、加密算法種類、隨機(jī)數(shù)等信息，同時(shí)也返回 Server 的 CA 證書。

Client 使用 Server 返回的信息驗(yàn)證 CA 證書的合法性，包括：

–證書是否過期。

–簽發(fā)證書的 CA 機(jī)構(gòu)是否可靠。

–安裝的 CA 公鑰證書是否能正確解開 CA 證書并返回?cái)?shù)字簽名。

– CA 證書上的 DN（域名）是否和 Server 的實(shí)際域名相匹配。

–驗(yàn)證通過后，將繼續(xù)進(jìn)行通信，否則，終止通信。

Client 向 Server 發(fā)送自己所能支持的對(duì)稱加密算法，供 Server 進(jìn)行選擇。

Server 端在 Client 提供的加密方案中選擇加密程度最高的方式。

Server 將選擇好的加密方案通過明文方式返回給 Client。

Client 接收到 Server 返回的加密方式后，使用該加密方式生成產(chǎn)生 Pre-Master 隨機(jī)碼，使用 Server Public Key 進(jìn)行加密，并發(fā)送至 Server。

Server 收到 Client 發(fā)來的加密信息后，使用自己的 Private Key 進(jìn)行解密，獲取 Pre-Master 隨機(jī)碼，并計(jì)算出 Master 對(duì)稱密鑰。

在接下來的會(huì)話中，Server 和 Client 將會(huì)使用 Master 對(duì)稱密鑰進(jìn)行對(duì)稱加密，保證通信過程中信息的安全。

HTTPS 雙向認(rèn)證

雙向認(rèn)證和單向認(rèn)證類似，主要是額外增加了 Server 對(duì) Client 的認(rèn)證。如下圖紅色部分。

?

TLS 的 SNI 擴(kuò)展

SNI

早期的 SSLv2 根據(jù)經(jīng)典的 PKI 標(biāo)準(zhǔn)進(jìn)行設(shè)計(jì)，它默認(rèn)認(rèn)為一臺(tái) HTTP Server（或者說一個(gè) IP 地址）只會(huì)提供一個(gè)服務(wù)（只有一個(gè) Domain Name），所以在 SSL 握手時(shí)，Client 無需指明具體的 Domain Name，Server 就會(huì)把默認(rèn)的 CA 證書返回。

然而在 Apache 等 HTTP Server 中應(yīng)用了 VirtualHosts 之后，就出現(xiàn)了一個(gè) IP 會(huì)對(duì)應(yīng)多個(gè) Domain Name 的情況。為了支持 VirtualHosts，HTTP/1.1 Header 協(xié)議增加了 Host 字段，相應(yīng)的 TLS 也需要類似的手段，否則會(huì)出現(xiàn) “公共名稱不匹配錯(cuò)誤（Unable to communicate securely with peer: requested domain name does not match the server's certificate.）”。即：雖然 Client 到達(dá)了 HTTP Server 的正確 IP 地址，但由于 CA 證書上的 Domain Name 與 Web 的 Domain Name 不匹配導(dǎo)致無法建立安全連接。

為了解決這個(gè)問題，TLS 在 v1.0 版本中增加了 SNI（Server Name Indication，服務(wù)器名稱指示，RFC 4366）擴(kuò)展，它包含在 TLS Hello 握手流程中，以確保 Client 能夠指定要訪問的 Domain Name被托管在相同的 HTTP Server 中，通過基于 Hostname 的 VirtualHosts 對(duì)外提供服務(wù)。此時(shí)。，如果 TLS 的 SNI 擴(kuò)展指定為 https://www.example.com，那么 HTTP Server 就會(huì)返回 https://www.example.com 的 CA 證書，繼而建立正確的安全連接。

?發(fā)出 SNI：

SSLKEYLOGFILE=ssl_log.txt curl
--cacert ~/ca_01.pem
--resolve www.app1.com172.18.22.68
-X GET "https://www.app1.com:443/"
-H 'Content-type: application/json'
-H 'Accept: application/json'
-H 'host: www.app1.com'

?抓包示例：

?

? Client Hello 的 SNI Extensions：

ESNI（加密的 SNI）

SNI 作為 TLS Client Hello Msg 的 擴(kuò)展字段，這意味著在 TLS v1.2 中，SNI 是明文的。也就是說，任何監(jiān)視 Client 和 Server 之間連接的攻擊者都可以讀取到 SNI 信息，并以此了解到 Client 正在與哪個(gè) Domain Name 建立 HTTPS 連接，即便攻擊者無法解密進(jìn)一步的通信內(nèi)容，但攻擊者仍然可以利用 SNI 信息，例如：建立一個(gè)釣魚網(wǎng)站來欺騙用戶。

由此，就提出了 ESNI（加密的 SNI），通過加密 client_hello 消息的 SNI 部分（僅此部分），來保護(hù) SNI 的私密性，確保攻擊者無法監(jiān)視到 SNI 明文信息。另外，ESNI 的加密密鑰必須以其他方式進(jìn)行傳輸。

具體而言，HTTP Server 會(huì)在其 DNS 記錄中添加一個(gè)用于 ESNI 的 Public Key。這樣，當(dāng) Client 查找到正確的 HTTP Server IP 地址時(shí)，同時(shí)也能得到對(duì)應(yīng)的 Public Key。

瀏覽器向 DNS Server 發(fā)送 Domain Name 查詢，以查詢 HTTP Server 的 IP 地址。

DNS 響應(yīng) HTTP Server IP 地址以及 ESNI Public Key。

瀏覽器向指定的 IP 地址發(fā)送 TLS client_hello 消息，并使用 ESNI Public Key 對(duì) SNI 部分進(jìn)行加密。

HTTP Server 根據(jù) SNI 指示返回指定的 CA 證書。

TLS 握手繼續(xù)進(jìn)行。

但需要注意的是，即表如此 ESNI 也并非是絕對(duì)安全的，因?yàn)槌Ｒ?guī)的 DNS 通信未加密，存在 “地址簿偽裝“ 攻擊風(fēng)險(xiǎn)。即使安裝了 ESNI，攻擊者仍然可以查看用戶正在查詢的 DNS 記錄，并確定他們正在訪問哪些網(wǎng)站。

所以更進(jìn)一步的，還可能需要安全的 DNS 方案，常見的有：

?基于 TLS 的 DNS；

?基于 HTTPS 的 DNS；

? DNSSEC；

?等等

升級(jí) curl 支持 HTTP2 與 TLS 1.3

編譯安裝

安裝編譯環(huán)境：

$yum -ygroupinstall "Development Tools"
$yum -yinstall libev libev-devel zlib zlib-devel openssl openssl-devel git

安裝 OpenSSL：

$mkdir /var/tmp
$cd /var/tmp
$wget https://openssl.org/source/openssl-1.0.2.tar.gz
$tar -zxfopenssl-1.0.2.tar.gz
$cd openssl-1.0.2
$mkdir /opt/openssl
$./config --prefix=/opt/openssl
$make
$make test
$make install

安裝 nghttp2：

$git clone https://github.com/tatsuhiro-t/nghttp2.git
$cd nghttp2
$autoreconf -i
$automake
$autoconf
$./configure
$make
$make install
$echo '/usr/local/lib'>/etc/ld.so.conf.d/custom-libs.conf
$ldconfig
$ldconfig -p|greplibnghttp2

安裝 curl：

$cd /var/tmp
$git clone https://github.com/bagder/curl.git
$cd curl
$./buildconf
$./configure --with-ssl=/opt/openssl --with-nghttp2=/usr/local --disable-file--without-pic--disable-shared
$make

驗(yàn)證：

$/var/tmp/curl/src/curl --version
curl7.70.0-DEV (x86_64-unknown-linux-gnu)libcurl/7.70.0-DEVOpenSSL/1.0.2o nghttp2/1.41.0-DEV
Release-Date:[unreleased]
Protocols:dict ftp ftps gopher http https imap imaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features:AsynchDNS HTTP2 HTTPS-proxy IPv6 Largefile NTLM NTLM_WB SSL TLS-SRP UnixSockets

curl 從 7.52.0 版本開始也已經(jīng)支持 TLS 1.3 了，curl 7.61.0 及以上在 TLS 握手過程中協(xié)商 TLS 版本時(shí)，curl 默認(rèn)使用 TLS 1.3，但也取決于 curl 正在使用的 TLS 庫(kù)及其版本，例如：要求 OpenSSL 1.1.1 版本以上。

curl 常用選項(xiàng)

curl[options] [URL...]

?-A/--user-agent：設(shè)置用戶代理發(fā)送給服務(wù)器。

?-e/--referer：來源網(wǎng)址。

?--cacert：CA 證書（SSL）。

?-k/--insecure：允許忽略證書進(jìn)行 SSL 連接。

?--compressed：要求返回是壓縮的格式。

?-H/--header：自定義首部信息傳遞給服務(wù)器。

?-i：顯示頁(yè)面內(nèi)容，包括報(bào)文首部信息。

?-I/--head：只顯示響應(yīng)報(bào)文首部信息。

?-D/--dump-header：將 URL 的 header 信息存放在指定文件中。

?--basic：使用 HTTP 基本認(rèn)證。

?-u/--user user[:password]：設(shè)置服務(wù)器的用戶和密碼。

?-L：如果有 3xx 響應(yīng)碼，重新發(fā)請(qǐng)求到新位置。

?-O：使用 URL 中默認(rèn)的文件名保存文件到本地。

?-o：將網(wǎng)絡(luò)文件保存為指定的文件中。

?--limit-rate：設(shè)置傳輸速度。

?-0/--http1.0：數(shù)字 0，使用 HTTP 1.0。

?-v/--verbose：更詳細(xì)。

?-C：選項(xiàng)可對(duì)文件使用斷點(diǎn)續(xù)傳功能。

?-c/--cookie-jar：將 URL 中 Cookie 存放在指定文件中。

?-x/--proxy proxyhost[:port]：指定代理服務(wù)器地址。

?-X/--request：向服務(wù)器發(fā)送指定請(qǐng)求方法。

?-U/--proxy-user ：代理服務(wù)器用戶和密碼。

?-T：選項(xiàng)可將指定的本地文件上傳到 FTP 服務(wù)器上。

?--data/-d：方式指定使用 POST 方式傳遞數(shù)據(jù)。

?-b name=data：從服務(wù)器響應(yīng) set-cookie 得到值，返回給服務(wù)器。

curl 指令使用 SNI

由上文可知，沒有 SNI 的情況下，服務(wù)器無法預(yù)知客戶端到底請(qǐng)求的是哪一個(gè)域名的服務(wù)。SNI 的 TLS 擴(kuò)展通過發(fā)送虛擬域名做為 TLS 協(xié)商的一部分修正了這個(gè)問題，在 Client Hello 階段，通過 SNI 擴(kuò)展，將域名信息提前告訴服務(wù)器，服務(wù)器根據(jù)域名取得對(duì)應(yīng)的證書返回給客戶端已完成校驗(yàn)過程。 curl 7.18.1+ & openssl 0.9.8j+ 的組合就可以支持 SNI 了：

curl
--cacert /root/CA/nginx1.com/cacert.pem
-X GET "https://webserver.com:8443/"
-H 'Content-type: application/json'
-H 'Accept: application/json'
-H 'host: nginx1.com'

如果沒有配置 DNS 解析的話可以使用 curl 7.21.3 支持的 --resolve 參數(shù)：

curl
--cacert /root/CA/nginx1.com/cacert.pem
--resolve webserver.com127.0.0.1
-X GET "https://webserver.com:8443/"
-H 'Content-type: application/json'
-H 'Accept: application/json'
-H 'host: nginx1.com'

--resolve 主要用于直接定位到 IP 地址進(jìn)行訪問，對(duì)于一個(gè) Domain Name 有多個(gè)服務(wù)器（多個(gè)不同的 IP）的服務(wù)來說，這個(gè)參數(shù)可以指定的訪問某個(gè)設(shè)備。

審核編輯：劉清