CIAA網絡安全模型與TLS / HTTPS協議（下）

SSL/TLS

SSL（Secure Sockets Layer，安全套接層）協議最初由 Netscape（網景公司）在 1994 年設計并開發，為了給 HTTP 提供一個安全的傳輸層。

到 1999 年，因為 SSL 應用廣泛，已經成為 Internet 上的事實標準。所以 IETF（Internet Engineering Task Force，互聯網工程任務組）在 SSL 的基礎上將其標準化為 TLS（Transport Layer Security，傳輸層安全協議）協議。

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

TLS 1.2

TLS 協議是 CIAA 網絡安全模型的具體實現，基于混合加密方案和 PKI/CA 數字證書技術制定了一套安全通信協議標準，所以理解 TLS 協議之前需要先對 CIAA 安全模型有一定的認識。

TLS 主要由 2 個部分組成：

TLS 記錄數據（TLS Record）：是一種數據結構，用于將應用層協議的數據分割成多個 TLS Records。數據結構的概覽如下圖所示：

?

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

?

協議交互抓包示例如下圖所示：

client_hello

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

Client Hello Msg 包含以下內容：

Client 支持的 TLS 版本。

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

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

Extensions（擴展字段）。

Client Random（隨機數），用于后續的對稱密鑰協商。

可選的 Session ID，用于支持 TLS 會話恢復。如果提供了，那么 Server 會復用對應的握手信息，避免短時間內重復握手。

server_hello + server_certificate + sever_hello_done

Server 收到了 ClientHello Msg 后，比對 Server 支持的 TLS 版本和 Cipher Suites，然會回復 ServerHello Msg，以此來完成 Cipher Suites 協商階段。

Server Hello Msg 包含以下內容：

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

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

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

Server Random（隨機數），用于后續的對稱密鑰協商。

可選的 Session ID，用于支持 TLS 會話恢復。如果提供了，則 Client 會復用當前握手的信息，避免短時間內重復握手。

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

Server Certificate Msg 包含以下內容：

Server 的 CA 證書，該證書由 CA 簽發，是一個由 CA 背書的 Server “公鑰“。

在雙向安全認證場景中，Client 也需要提供它的 CA 證書，還需要包含 Client Certificate Request（客戶端證書請求）。

Server Hello Done Msg：向 Client 發送 Server Hello Done 表示 Hello 協商階段完成。

Certificate authentication

Client 收到 Server Hello Msg 后，會對收到的 Server CA 證書進行合法性驗證。只有通過驗證才會進行后續通信，否則根據錯誤情況不同做出提示和操作，合法性驗證的內容包括：

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

Revocation（證書是否已經吊銷）：有 2 種方式：離線 CRL 驗證、在線 OCSP 驗證。不同的 Client 會采用不同的方式。

Expiry Date（有效期）：證書是否在有效時間范圍內。

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

client_key_exchange + change_cipher_spec + encrypted_handshake_message

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

Client Key Exchange Msg：內含了 Client 本地運算生成的 Pre-Master 隨機數，并用 Server Public Key 加密，然后發送給 Server，再由 Server Private Key 解密。

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

在 C/S 協商階段獲得的 2 個明文隨機數 random_C 和 random_S。

Client 自己生成的加密 Pre-Master 隨機數。

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

用于非對稱加密的 Server Public Key。

Change Cipher Spec Msg：Client 通知 Server 后續的通信都采用協商的通信密鑰和加密算法進行加密通信。

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

change_cipher_spec + encrypted_handshake_message

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

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

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

Change Cipher Spec Msg：驗證通過之后，Server 同樣發送該消息以告知 Client 后續的通信都采用協商的通信密鑰與算法進行加密通信。

Encrypted Handshake Msg / Finished Msg：Server 也會以同樣的方式計算出數字簽名并發送給 Client。

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

TLS 1.3

相對于 TLS v1.2 而言，v1.3 是迄今為止最大的一次改動，主要的改進目的如下：

更強的安全性：進一步加密握手流程、改善跨協議攻擊的彈性、刪除不安全的加密算法。

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

引入的新特性如下：

引入了新的 PSK 密鑰協商機制。

支持 0-RTT 數據傳輸，在建立連接時節省了往返時間。

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

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

不再允許對加密報文進行壓縮、不再允許雙方發起重協商。

DSA 證書不再允許使用。

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

更強的安全性

加密了整個 TLS Handshake 握手流程

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

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

?

以最簡單的 FREAK 攻擊為例，它利用了以下 2 個漏洞：

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

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

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

?

在 TLS v1.3 中，這種類型的安全降級攻擊是不可能的，因為整個握手流程都進行了加密，同時 v1.3 還刪除了那些不安全的加密算法，包括：

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

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

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

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

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

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

?等等。

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

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

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

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

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

更快的訪問速度

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

DNS 查詢

TCP 握手（1 RTT）

TLS v1.2 握手 （2 RTT）

建立 HTTP 連接（1 RTT）

可見在 TLS v1.2 中，新建一個完整的 HTTPS 連接最少需要 4 個 RTT（Round-Trip Time 往返時延），而重連則可以通過 TLS 的會話恢復機制節省 1 個 RTT。

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

?

? TLS v1.2 會話恢復流程（指定了 Hello Msg 的 Session ID）：

?

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

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



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

? TLS v1.3 0-RTT 會話恢復流程：

升級 OpenSSL 1.1.1 支持 TLS 1.3

并非所有的 Client 和 Server 都支持相同版本的 TLS，因此大多數 Server 都會同時支持多個版本，并且進行協商。TLS 的版本協商非常簡單。Client 會通知 Server 它支持的協議的最新版本，Server 則會回復支持的協議版本，如果存在交集則協商成功。否則，連接失敗。雖然版本協商的過程很簡單，但事實證明，很多連接場景并未能正確地實現這一功能，從而導致安全事故。

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

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

$openssl s_client --help｜ grep tls1_3

如果沒有，則需要手動安裝：

下載 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

查看版本并驗證

$openssl version
$openssl s_client --help|greptls1_3

HTTPS

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

測試網站是否開啟了 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 單向認證

Client 向 Server 發送 TLS 協議版本號、加密算法種類、隨機數等信息。

Server 給 Client 返回 TLS 協議版本號、加密算法種類、隨機數等信息，同時也返回 Server 的 CA 證書。

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

–證書是否過期。

–簽發證書的 CA 機構是否可靠。

–安裝的 CA 公鑰證書是否能正確解開 CA 證書并返回數字簽名。

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

–驗證通過后，將繼續進行通信，否則，終止通信。

Client 向 Server 發送自己所能支持的對稱加密算法，供 Server 進行選擇。

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

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

Client 接收到 Server 返回的加密方式后，使用該加密方式生成產生 Pre-Master 隨機碼，使用 Server Public Key 進行加密，并發送至 Server。

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

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

HTTPS 雙向認證

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

?

TLS 的 SNI 擴展

SNI

早期的 SSLv2 根據經典的 PKI 標準進行設計，它默認認為一臺 HTTP Server（或者說一個 IP 地址）只會提供一個服務（只有一個 Domain Name），所以在 SSL 握手時，Client 無需指明具體的 Domain Name，Server 就會把默認的 CA 證書返回。

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

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

?發出 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 的 擴展字段，這意味著在 TLS v1.2 中，SNI 是明文的。也就是說，任何監視 Client 和 Server 之間連接的攻擊者都可以讀取到 SNI 信息，并以此了解到 Client 正在與哪個 Domain Name 建立 HTTPS 連接，即便攻擊者無法解密進一步的通信內容，但攻擊者仍然可以利用 SNI 信息，例如：建立一個釣魚網站來欺騙用戶。

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

具體而言，HTTP Server 會在其 DNS 記錄中添加一個用于 ESNI 的 Public Key。這樣，當 Client 查找到正確的 HTTP Server IP 地址時，同時也能得到對應的 Public Key。

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

DNS 響應 HTTP Server IP 地址以及 ESNI Public Key。

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

HTTP Server 根據 SNI 指示返回指定的 CA 證書。

TLS 握手繼續進行。

但需要注意的是，即表如此 ESNI 也并非是絕對安全的，因為常規的 DNS 通信未加密，存在 “地址簿偽裝“ 攻擊風險。即使安裝了 ESNI，攻擊者仍然可以查看用戶正在查詢的 DNS 記錄，并確定他們正在訪問哪些網站。

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

?基于 TLS 的 DNS；

?基于 HTTPS 的 DNS；

? DNSSEC；

?等等

升級 curl 支持 HTTP2 與 TLS 1.3

編譯安裝

安裝編譯環境：

$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

驗證：

$/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 版本開始也已經支持 TLS 1.3 了，curl 7.61.0 及以上在 TLS 握手過程中協商 TLS 版本時，curl 默認使用 TLS 1.3，但也取決于 curl 正在使用的 TLS 庫及其版本，例如：要求 OpenSSL 1.1.1 版本以上。

curl 常用選項

curl[options] [URL...]

?-A/--user-agent：設置用戶代理發送給服務器。

?-e/--referer：來源網址。

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

?-k/--insecure：允許忽略證書進行 SSL 連接。

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

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

?-i：顯示頁面內容，包括報文首部信息。

?-I/--head：只顯示響應報文首部信息。

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

?--basic：使用 HTTP 基本認證。

?-u/--user user[:password]：設置服務器的用戶和密碼。

?-L：如果有 3xx 響應碼，重新發請求到新位置。

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

?-o：將網絡文件保存為指定的文件中。

?--limit-rate：設置傳輸速度。

?-0/--http1.0：數字 0，使用 HTTP 1.0。

?-v/--verbose：更詳細。

?-C：選項可對文件使用斷點續傳功能。

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

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

?-X/--request：向服務器發送指定請求方法。

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

?-T：選項可將指定的本地文件上傳到 FTP 服務器上。

?--data/-d：方式指定使用 POST 方式傳遞數據。

?-b name=data：從服務器響應 set-cookie 得到值，返回給服務器。

curl 指令使用 SNI

由上文可知，沒有 SNI 的情況下，服務器無法預知客戶端到底請求的是哪一個域名的服務。SNI 的 TLS 擴展通過發送虛擬域名做為 TLS 協商的一部分修正了這個問題，在 Client Hello 階段，通過 SNI 擴展，將域名信息提前告訴服務器，服務器根據域名取得對應的證書返回給客戶端已完成校驗過程。 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 參數：

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 地址進行訪問，對于一個 Domain Name 有多個服務器（多個不同的 IP）的服務來說，這個參數可以指定的訪問某個設備。

審核編輯：劉清