SSL/TLS

資安管理 SSL/TLS (3)

教學目標

初步了解企業中針對 Windows 伺服器整合 F5 負載平衡的網路設備進行安全連線時可能會遇到的問題。

重點概念

首先企業中若有 F5 負載平衡的網路設備,則通常會將憑證設定至 F5 負載平衡的網路設備中,像是 BIG-IP 系統。同時企業中的客戶端將會自動匯入 F5 上受信任的根憑證,此時當我們開啟 Internet Explorer 瀏覽器時就會顯示安全鎖頭至瀏覽列右方中,代表伺服器的這個連線經過加密。但是企業中的伺服器通常不會匯入 F5 上受信任的根憑證,此時我們只需將 F5 上受信任的根憑證、中繼憑證和網站憑證匯出之後,直接開啟憑證檔,然後點選「一般」頁籤中的「安裝憑證」鈕按照順序安裝至伺服器中即可,建議點選存放位置為「本機電腦」,以及其中受信任的根憑證則在透過憑證匯入精靈進行憑證匯入時,針對憑證存放區則建議將憑證放入「受信任的根憑證授權單位」中,至於其它憑證則自動根據憑證類型來選取憑證存放區,當憑證正確匯入伺服器之後,此時當我們開啟 Internet Explorer 瀏覽器時就會顯示安全鎖頭至瀏覽列右方中,代表伺服器的這個連線經過加密。

接著企業通常會有從 F5 負載平衡的網路設備匯出憑證的標準流程,此時可能會發生匯出憑證格式不正確,造成無法正常將憑證匯入網站系統解決方案中。憑證主要有 Base64 編碼和二進位編碼兩種格式,當我們透過記事本開啟憑證檔時,若憑證檔內容為「——-BEGIN CERTIFICATE——- … ——-END CERTIFICATE——-」,則代表憑證檔為 Base64 編碼格式,反之為二進位編碼格式。然而若發生匯出憑證格式不正確時,則只需要直接開啟憑證檔,然後點選「詳細資料」頁籤中的「複製到檔案」鈕就能夠直接轉換 Base64 編碼或二進位編碼格式,以利解決無法正常將憑證匯入網站系統解決方案中。

再來企業中所簽發的網站憑證通常會有憑證路徑,我們僅需要直接開啟憑證檔,然後點選「憑證路徑」頁籤就能夠了解網站憑證所對應的憑證路徑,以及確認憑證狀態是否沒有問題。此外我們還能夠點選憑證路徑中的根憑證和中繼憑證之後點選「檢視憑證」鈕確認憑證資訊,其中包括發給、簽發者、有效期、… 等詳細資訊。

最後企業中若有 F5 負載平衡的網路設備,則在導入網站系統解決方案需要設定 HTTPS 安全連線時,建議以 F5 負載平衡的網路設備當成反向伺服器,直接將網站系統 HTTP 連線對應至 F5 負載平衡的網路設備的 HTTPS 安全連線,就能夠將網站系統解決方案設定為 HTTPS 安全連線,請注意並非所有網站系統解決方案皆能在設定完成 F5 負載平衡的網路設備之後,正常使用網站系統,通常還會需要進行網站系統相關設定,但是至少能夠正常透過 Internet Explorer 瀏覽器輸入 F5 負載平衡的網路設備的對應網址顯示網站系統的首頁畫面,同時在網址列右方顯示安全鎖頭,並且在點選安全鎖頭之後點選「檢視憑證」鈕之後,點選「憑證路徑」頁籤確認憑證狀態是否沒有問題。此方式將會有三大優點,分別為:

  1. 網站憑證發佈至客戶端,則直接以企業標準流程為主,確保客戶端瀏覽器開啟網站系統時顯示安全連線。
  2. 網站系統若需要增加網站伺服器時,則無需重新簽發網站憑證,以利憑證的集中進行管理。
  3. 網站系統無需進行 HTTPS 握手的安全協定,以利維持效能的同時又能夠讓使用者安心使用網站系統。

總結企業中針對 Windows 伺服器整合 F5 負載平衡的網路設備進行安全連線時可能會遇到許多問題,包括伺服器中瀏覽器無法正常顯示正確憑證資訊、憑證匯出檔案格式不確認、憑證路徑無法正常顯示、… 等憑證問題,此時我們僅需透過 Windows 伺服器內建的功能就能夠解決上述的問題。此外若是瀏覽器顯示未受信任的憑證或憑證錯誤的訊息時,則不會影響網站系統的運作,但是若網站系統解決方案中有需要客戶端應用程式或網站應用程式進行安全連線時,就需要將憑證匯入至伺服器中,請注意不同網站系統解決方案匯入憑證的方式皆不相同,並且可能需要按照順序匯入根憑證、中繼憑證和網站憑證,以利網路系統的所有功能正常運作。

相關資源

資安管理 SSL/TLS (2)

基本介紹

教學目標

初步了解 SSL/TLS 的資安風險和金鑰產生的流程。

重點概念

目前已知 SSL/TLS 有許多弱點可能會讓駭客遠端進行攻擊,弱點主要可以分為兩大類,分別為協定本身的弱點和特定工具的弱點,其中像是 SSL 3.0 和 TLS 1.0 已經證實有嚴重實作的缺陷會導致不安全,以及 OpenSSL 被發現有 heartbleed 漏洞,請參考下表。

CVE 編號 攻擊名稱 說明 解決方式
CVE-209-3555 TLS 端點可能支援不安全重新協商,此時有網路存取權的使用者就能夠將自己的流程加在客戶端傳給伺服器的流量之前執行惡意攻擊。 將客戶端和伺服器軟體升級到最新版本。
CVE-2011-3389 BEAST 當使用 CBC 模式加密時 TLS 1.0 產生的初始向量值是可以被預測,接著注入代理程式,再來監視取得密文之後,就能夠執行惡意攻擊,找出明文資料。 強制使用 TLS 1.1 以上的版本協定。
CVE-2012-4929 CRIME 伺服器執行具有壓縮機制的 TLS 1.2 之前的版本,就會容易受到惡意攻擊 停用 TLS 壓縮功能。
CVE-2013-0169 Lucky 13 當使用 CBC 模式加密時跨頻道的惡意攻惠會造成已知位置的資料被找出明文資料。 停用 CBC 加密方式。(OpenSSL 1.0.1d)
CVE-2013-2566 RC4 RC4 演算法中有許多位元組偏移,當知道機密資料位置,接著在相同的明文加密多次,就能找出明文資料。 停用支援 RC4 加密套件。
CVE-2013-3587 BREACH 網頁應用程式使用 HTTP 壓縮,並且經由 HTML 靜態機密回傳給客戶端時,就能夠執行惡意攻擊,找出明文資料。 停用 HTTP 壓縮功能。
CVE-2014-0160 heartbleed 當收到特製的請求之後,會導致洩露堆積記憶體中的機敏資料。 將客戶端和伺服器軟體升級到最新版本。(OpenSSL 1.0.1~1.0.1f)
CVE-2014-3566 POODLE 當使用 CBC 模式加密時 SSL 3.0 容易受到 Pading oracle 的惡意攻擊,找出明文資料。 停用 SSL 3.0。
CVE-2015-0400 Logjam 當系統支援 DH 群組小於 1024 位元時,就容易受到中間人 (Man In The Middle,MITM) 惡意攻擊。 強制使用 1024 位元以上的 DH 群組之大小。

接著駭客針對 SSL/TLS 攻擊主要破解憑證內容,以及依賴客戶端瀏覽器執行 JavaScript 代理程式,以利在 SSL/TLS 上產生所需要的請求,至於針對位元組偏移的攻擊,像是 RC4 和 Lucky 13 攻擊時會產生大量資料,所以實務應用較不切實際。此時為了防止駭客進行攻擊,所以加密組合的選擇就非常的重要,在 TLS 1.2 加密組合 (Cipher Suites) 的資訊主要有金鑰交換的方法、身分驗證的方法、對稱加密演算法、金鑰長度和模式和訊息驗證碼的演算法,在 RFC 5246 的技術標準中會列出基本的加密套件,此外我們也可以透過 OpenSSL 指令查看支援的加密套件。

查看 OpenSSL 支援的加密套件指令之範例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
c:\Apache24\bin>openssl ciphers -v
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384
DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256
DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256
ECDHE-ECDSA-AES256-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1
ECDHE-RSA-AES256-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
ECDHE-ECDSA-AES128-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1
ECDHE-RSA-AES128-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
RSA-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=RSAPSK Au=RSA Enc=AESGCM(256) Mac=AEAD
DHE-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESGCM(256) Mac=AEAD
RSA-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=RSAPSK Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
DHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=DHEPSK Au=PSK Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=ECDHEPSK Au=PSK Enc=CHACHA20/POLY1305(256) Mac=AEAD
AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
PSK-AES256-GCM-SHA384 TLSv1.2 Kx=PSK Au=PSK Enc=AESGCM(256) Mac=AEAD
PSK-CHACHA20-POLY1305 TLSv1.2 Kx=PSK Au=PSK Enc=CHACHA20/POLY1305(256) Mac=AEAD
RSA-PSK-AES128-GCM-SHA256 TLSv1.2 Kx=RSAPSK Au=RSA Enc=AESGCM(128) Mac=AEAD
DHE-PSK-AES128-GCM-SHA256 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESGCM(128) Mac=AEAD
AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD
PSK-AES128-GCM-SHA256 TLSv1.2 Kx=PSK Au=PSK Enc=AESGCM(128) Mac=AEAD
AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256
AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256
ECDHE-PSK-AES256-CBC-SHA384 TLSv1 Kx=ECDHEPSK Au=PSK Enc=AES(256) Mac=SHA384
ECDHE-PSK-AES256-CBC-SHA TLSv1 Kx=ECDHEPSK Au=PSK Enc=AES(256) Mac=SHA1
SRP-RSA-AES-256-CBC-SHA SSLv3 Kx=SRP Au=RSA Enc=AES(256) Mac=SHA1
SRP-AES-256-CBC-SHA SSLv3 Kx=SRP Au=SRP Enc=AES(256) Mac=SHA1
RSA-PSK-AES256-CBC-SHA384 TLSv1 Kx=RSAPSK Au=RSA Enc=AES(256) Mac=SHA384
DHE-PSK-AES256-CBC-SHA384 TLSv1 Kx=DHEPSK Au=PSK Enc=AES(256) Mac=SHA384
RSA-PSK-AES256-CBC-SHA SSLv3 Kx=RSAPSK Au=RSA Enc=AES(256) Mac=SHA1
DHE-PSK-AES256-CBC-SHA SSLv3 Kx=DHEPSK Au=PSK Enc=AES(256) Mac=SHA1
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
PSK-AES256-CBC-SHA384 TLSv1 Kx=PSK Au=PSK Enc=AES(256) Mac=SHA384
PSK-AES256-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(256) Mac=SHA1
ECDHE-PSK-AES128-CBC-SHA256 TLSv1 Kx=ECDHEPSK Au=PSK Enc=AES(128) Mac=SHA256
ECDHE-PSK-AES128-CBC-SHA TLSv1 Kx=ECDHEPSK Au=PSK Enc=AES(128) Mac=SHA1
SRP-RSA-AES-128-CBC-SHA SSLv3 Kx=SRP Au=RSA Enc=AES(128) Mac=SHA1
SRP-AES-128-CBC-SHA SSLv3 Kx=SRP Au=SRP Enc=AES(128) Mac=SHA1
RSA-PSK-AES128-CBC-SHA256 TLSv1 Kx=RSAPSK Au=RSA Enc=AES(128) Mac=SHA256
DHE-PSK-AES128-CBC-SHA256 TLSv1 Kx=DHEPSK Au=PSK Enc=AES(128) Mac=SHA256
RSA-PSK-AES128-CBC-SHA SSLv3 Kx=RSAPSK Au=RSA Enc=AES(128) Mac=SHA1
DHE-PSK-AES128-CBC-SHA SSLv3 Kx=DHEPSK Au=PSK Enc=AES(128) Mac=SHA1
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
PSK-AES128-CBC-SHA256 TLSv1 Kx=PSK Au=PSK Enc=AES(128) Mac=SHA256
PSK-AES128-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(128) Mac=SHA1

其中 Kx 為金鑰交換演算法、Au 為身份驗證機制,Enc 為對稱加密演算法和金鑰長度,Mac 為訊息驗證碼的演算法,像是 DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256 代表金鑰交換演算法為 DH、身份驗證機制為 RSA、對稱加密演算法為 AES、金鑰長度為 128 bits,訊息驗證碼的演算法為 SHA256。

再來 DH 金鑰交換演算法主要是允許雙方在公開通道上建立加密通道,其中 Pre-master Key 是由客戶端產生,接著由伺服器的公鑰加密之後,再來傳送給伺服器。其中 DH 公鑰,主要是由伺服器以憑證和伺服器金鑰交換訊息傳送給客戶端,其中金鑰類型又可分為靜態和短暫,所謂靜態公鑰主要是從伺服器的私鑰所衍生,因此可以在伺服器的憑證中找到,所謂短暫金鑰則是為每一個 SSL/TLS 工作階段而產生。此外因為 DH 金鑰交換演算法主要為匿名,因此無法進行身份驗證,所以我們會使用 RSA 進行身份驗證。若透過 RSA 進行協商時,客戶端和伺服器會向雙方傳送 256 bits 的亂數,其中前 32 bits 是由本機系統時間所產生,剩下的 224 bits來自虛擬亂數產器。接著客戶端會額外產生 368 bits 的亂數,再加上 16 bits 的 TLS 協定版本之後,總計 384 bits 就是 Pre-master Key ,因此 Pre-master Key 主要是使用伺服器的 RSA 公加密,再以客戶端金鑰交換訊息傳送,其中因為使用伺服器的公鑰加密代表此方法不提供轉送保密機制。當我們具備 Pre-master Key、伺服器的亂數和客戶端的亂數使用相同的虛擬亂數函數就能夠產生 Master Secret,此外雖然 Master Secret 的長度為 384 bits,但還是會透過 Master Secret、伺服器的亂數和客戶端的亂數使用相同的虛擬亂數函數產生不同大小的金鑰區塊,下一步客戶端和伺服器將會使用 Master Secret 產生工作階段金鑰進行資料的加密、解密、簽章和驗證。

最後 TLS 加密協定主要會使用 X.509 憑證進行客戶端和伺服器的驗證,通常會藉由的憑證頒發機構的根憑證和 X.509 憑證的簽章來驗證雙方的身份,其中憑證頒發機構會使用其私鑰對憑證進行簽章,接著會將對應的公鑰發佈給通訊雙方的作業系統和瀏覽器中當成受信任的根憑證。此外 X.509 憑證是可以進行串鏈,首先憑證頒發機構的根憑證主有包括根憑證名稱、根憑證公鑰、根憑證簽章、… 等資訊,接著中繼憑證和網站憑證皆包括擁有者名稱、擁有者公鑰、憑證頒發機構名稱、憑證頒發機構簽章、… 等資訊。其中憑證頒發機構的根憑證會透過根憑證公鑰驗證根憑證簽章,接著憑證頒發機構的根憑證驗證中繼憑證,以及中繼憑證驗證網站憑證。

總結本篇主要是先 SSL/TLS 的資安風險和金鑰產生的流程,至於有關 SSL/TLS 更多除錯方式將在之後進行說明。

相關資源

資安管理 SSL/TLS (1)

基本介紹

教學目標

初步了解 SSL/TLS 基本概念,尤其是 SSL Handshake 協商流程。

重點概念

SSL 的全名為 Secure Socket Layer,TLS 的全名稱 Transport Layer Security 兩者皆為加密協定主要提供網際網路中安全的通訊。SSL 主要被使用於證明內容,其將會透過加密技術在網際網路中提供端點驗證和通訊隱私,然而通常僅有伺服器被驗證,我們會使用公開金鑰基礎架構 (Public Key Infrastructure,PKI) 部署驗證資訊至客戶端,其協定允許客戶端和伺服器應用程式通訊時避免 eavesdropping、tampering 、 message forgery 、… 等問題發生。

大部份網站會透過網頁瀏覽器交換機密的使用者資訊,此時透過 SSL 加密協定就能夠保護其工作階段中的機敏資訊,為了方便識別我們會將網址中的 HTTP 以 HTTPS 取代之後,該網址連線至的網站使用 SSL 加密協定,也就是所謂 HTTPS 安全協定,SSL 主要使用非對稱金鑰交換在客戶端與伺服器進行協商,所有主流網頁瀏覽器皆會支援 SSL 加密協定,其中 SSL Handshake 就是在客戶端與伺服器建立初始安全通訊的工作階段。

SSL Handshake 協定組成主要有兩個階段,分別為必要的第一階段伺服器驗證和非必要的第二階段客戶端驗證。在第一個階段伺服器在回應給客戶端的請求中會傳送憑證和 Cipher 相關屬性,接著客戶端會產生主要的金鑰,主要是用於加密伺服器的公開金鑰和傳送被加密的主要金鑰至伺服器。伺服器透過主要金鑰驗證訊息,並且再透過主要金鑰返回被驗證的訊息,接著會再透過主要的金鑰衍生出金鑰持續針對通訊的資料進行加密和驗證。第二個階段伺服器傳送 Challenge 的訊息給客戶端,客戶端會進行驗證同時傳送客戶端包括公開金鑰的數位憑證,至於 SSL 資訊交換的流程主要有八個步驟:

  1. 客戶端傳送 SSL 相關資訊給伺服器,像是版本號碼、Cipher 設定、隨機產生資料、…等需要與伺服器進行 SSL 安全通訊的資訊。
  2. 伺服器傳送 SSL 相關資訊給客戶端,像是版本號碼、Cipher 設定、隨機產生資料、…等需要與客戶端進行 SSL 安全通訊的資訊。同時伺服器也會傳送所擁有的憑證,以及若客戶端請求伺服器資源時則會需要客戶端驗證的相關數位憑證。
  3. 客戶端使用與伺服器相同的資訊驗證伺服器,若是伺服器無法被驗證,則連線就無法被建立,代表 SSL Handshake 協商發生錯誤。
  4. 客戶端使用在 SSL Handshake 中所有被產生的資料建立工作階段的 Parameter Secret,接著會透過伺服器公開金鑰進行加密,之後傳送被加密的 Parameter Secret 給伺服器。
    若是伺服器已經請求客戶端驗證,則客戶端也會簽署此次 SSL Handshake 僅有伺服器和客戶端知道的資料,之後會傳送被簽署的資料、憑證和被加密的 Parameter Secret 至伺服器。
    若是伺服器已經請求客戶端驗證,則伺服器會嘗試驗證客戶端,若是客戶端無法被驗證,則工作階段就會被終止,接著伺服器會使用私密金鑰解密 Parameter Secret,然後執行接下來的步驟產生 Master Secret。
  5. 伺服器和客戶端會使用 Master Secret 產生工作階段金鑰,主要為被使用於加密和解密在 SSL 工作階段資訊交換的對稱金鑰,以及驗證完整性,同時還會偵測 SSL 安全連線之間的任何資料改變情況。
  6. 客戶端透過工作階段金鑰加密訊息傳送給伺服器,同時讓伺服器知道客戶端 SSL Handshake 已結束。
  7. 伺服器透過工作階段金鑰加密訊息傳送給客戶端,同時讓客戶端知道伺服器 SSL Handshake 已結束。
  8. 當客戶端和伺服器 SSL Handshake 皆已結果,就完成 SSL Handshake ,接著代表 SSL 工作階段開始,客戶端和伺服器將會使用工作階段金鑰加密和解密傳送的資料,同時驗證資料的完整性。

可是上述的流程有點太多技術名詞,是否能夠更簡單的說明流程呢? 請參考下述說明流程。

  1. 客戶端會傳送訊息至伺服器,訊息內容為:「嗨,請您設定加密工作階段,這有我們將會使用的 Chiper 組合列表和 SSL/TLS 的版本。」。
  2. 伺服器會回應訊息至客戶端,訊息內容為:「嗨,請使用這個來自於您列表中特別的 Chiper 組合,我也已經確認,並且我會使用 1.2 版本的 TLS 協定,此外這有我的憑證主要包括公開金鑰。」。
  3. 客戶端驗證伺服器憑證,然後取得公開金鑰,接著客戶端會使用公開金鑰的憑證加密全新的 Pre-master Key 給伺服器。
  4. 伺服器會使用私密金鑰解密 Pre-master Key,也就是 Parameter Secret。
  5. 客戶端和伺服器現在皆使用前置主金鑰運算將被分享的秘密金鑰,稱為 Shared Secret,也就是 Master Secret。
  6. 客戶端會傳送已被加密訊息至伺服器,訊息內容為:「嗨,這有一個被加密的訊息,請嘗試解密訊息和驗證訊息是否符合規格,同時之後我將會傳送以 Shared Secret 加密的訊息。」。
  7. 伺服器會解密和驗證訊息,若是正常運作則伺服器會回傳訊息至客戶端,訊息內容為:「嗨,您的加密訊息確認無誤,現在我傳送一個被加密的訊息,請嘗試解密訊息和驗證訊息是否符合規格,同時之後我將會傳送以 Shared Secret 加密的訊息。」。
  8. 客戶端和伺服器現在皆使用 Shared Secret 加密和保護它們接下來工作階段的所有通訊內容。

但是流程有八個步驟太複雜了,是否能夠更簡化為階段流程呢? 請參考下述三個主要階段流程說明。

  1. 伺服器在傳送其包含公開金鑰的憑證之後就完成部份的 SSL Handshake 協商。(細節請參考第 1 步驟至第 4 步驟)
  2. 客戶端在傳送已完成的訊息,代表已經確認 Shared Secret 交換和驗證流程已順利成功。(細節請參考第 5 步驟至第 7 步驟)
  3. 客戶端開始傳送應用程式的資料,以利進行安全的操作。(細節請參考第 8 步驟)

最後在實務應用中我們經常會碰到 SSL Handshke Failures 的錯誤訊息導致網頁應用程式無法正常使用,此時最有可能會發生在初始協商第一個階段,客戶端和伺服器可能無法進行驗證,原因可能是通訊協定版本和 Cipher 不相同所造成,當然也有可能是重新協商的安全選項或客戶端憑證請求。至於要如何確認 SSL/TLS 連線和相關資訊進行分析,則可以透過下述指令。

測試 SSL 連線指令之範例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
c:\Apache24\bin>openssl s_client -connect leoyeh.me:443
CONNECTED(00000158)
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify error:num=20:unable to get local issuer certificate
---
Certificate chain
0 s:/CN=www.leoyeh.me
i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFCDCCA/CgAwIBAgISA3OASIRpV7eLLmq/wHnuCKs1MA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xNzA4MTMwMDE1MDBaFw0x
NzExMTEwMDE1MDBaMBgxFjAUBgNVBAMTDXd3dy5sZW95ZWgubWUwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDDhPPRlDV858i61vNclVmg6C6nC9fi2SLJ
sHDeLZRMfGd+7+dkJL4PNk5PiBfsZPS8oXDSviSwHcE/bWVTHSuaMXMvvYVpnQu/
K03UJaSGLvSbKofVH+56OYIbyGJ18PT8Aj4eWiVI5+gS6fmVx6jv5ASISRBJdMze
R057PXE63zXumu/IeYzwz8jDGQd4yFuyXIlQP1HKJTS65zHHX+hO2N8KheSN4t7Q
twG6h+YXKv90ufTv5SXijEJuM406brxEMutz+y6Mkn5JvLAhuwEB38RgxuLOR8qF
QxOX9q+xo8v7/lgdNnLwBpCbsrG7WZaE105VJEN4CMAs7Zp35Q3rAgMBAAGjggIY
MIICFDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUF
BwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFNnw6L8lvnlIq/Ys9uKcgU1tZuYj
MB8GA1UdIwQYMBaAFKhKamMEfd265tE5t6ZFZe/zqOyhMG8GCCsGAQUFBwEBBGMw
YTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AuaW50LXgzLmxldHNlbmNyeXB0Lm9y
ZzAvBggrBgEFBQcwAoYjaHR0cDovL2NlcnQuaW50LXgzLmxldHNlbmNyeXB0Lm9y
Zy8wIwYDVR0RBBwwGoIJbGVveWVoLm1lgg13d3cubGVveWVoLm1lMIH+BgNVHSAE
gfYwgfMwCAYGZ4EMAQIBMIHmBgsrBgEEAYLfEwEBATCB1jAmBggrBgEFBQcCARYa
aHR0cDovL2Nwcy5sZXRzZW5jcnlwdC5vcmcwgasGCCsGAQUFBwICMIGeDIGbVGhp
cyBDZXJ0aWZpY2F0ZSBtYXkgb25seSBiZSByZWxpZWQgdXBvbiBieSBSZWx5aW5n
IFBhcnRpZXMgYW5kIG9ubHkgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBDZXJ0aWZp
Y2F0ZSBQb2xpY3kgZm91bmQgYXQgaHR0cHM6Ly9sZXRzZW5jcnlwdC5vcmcvcmVw
b3NpdG9yeS8wDQYJKoZIhvcNAQELBQADggEBAHTJepxm+oj1irBJXYmqiAcsPUm2
BQmeD+rWffwVl4U2QrX/ddTsnD7PANHJpOS+PB1XHxMGvRekWp8/Kq+tcTDujQTq
i6gd5tWI/lEpiYlVOMw9GBPbvgr2EBXfEbcYX9Zhdr/g9q8A10gFPlvdiFFQc57Q
HieDVJN0M1T/4A1i5ajS7iuRDmxxZCTX390zXZ5ZAULSLJX4u2Q3CFy2Gjlj/XbN
NzoMAETvx62n8XvkbyT4OeOjpYgTpV26437pzyX1Ks9lzB0nqoT59FWAPbq0Qskj
WZARXHeQPMPIARHj2RLX83LkXPo814D+Tjl18UIY10Gx0dBeZx9jkNuU4xo=
-----END CERTIFICATE-----
subject=/CN=www.leoyeh.me
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3155 bytes and written 302 bytes
Verification error: unable to get local issuer certificate
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 57C8C964E802FDE202E1B7219A73E5339377872D605B7CB11F77DDB609F1A110
Session-ID-ctx:
Master-Key: 953F9FC02F91B3592C98B00908959626B0D6643836F102762F07BA90A53168D2CCF2BC70CCCE823AC7A5858637AE740D
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - ba b6 f2 21 e4 08 8c 67-04 95 04 3b 3e b0 1f 8e ...!...g...;>...
0010 - 04 89 d8 00 14 d6 2a a2-2f 50 bb 97 76 6f 1e b4 ......*./P..vo..
0020 - 3e 2f 6e c0 6f 48 c8 82-52 41 fa e8 52 59 de c3 >/n.oH..RA..RY..
0030 - c8 5f e8 08 67 ce c3 77-22 56 5c cc 57 8c 72 e0 ._..g..w"V\.W.r.
0040 - 0c 60 32 6d 60 6e 86 09-ed a3 14 ab 4a 2a 39 db .`2m`n......J*9.
0050 - 18 09 81 5b 0a 88 1d fd-a7 01 aa 89 dd 2b 54 73 ...[.........+Ts
0060 - 03 fa 21 9c 0b 98 19 a2-c4 7b ee 9a 81 54 8b 5a ..!......{...T.Z
0070 - c7 c3 e7 2a 19 71 c8 99-09 77 ae a1 33 e7 39 45 ...*.q...w..3.9E
0080 - 81 43 22 e0 f1 a9 d3 6b-64 5b 7c 67 4e da 01 54 .C"....kd[|gN..T

0090 - 18 3a d7 e1 e4 46 d1 0f-48 1c 05 3a e5 6a 8c 76 .:...F..H..:.j.v
00a0 - ab d4 9b 6f 6e 1c 01 2a-49 a4 c7 79 57 45 0b a4 ...on..*I..yWE..
00b0 - 2c 7b 49 c0 cb bc bd 89-d2 4a 4d 0b 4d ff 0a 54 ,{I......JM.M..T


Start Time: 1504939264
Timeout : 7200 (sec)
Verify return code: 20 (unable to get local issuer certificate)
Extended master secret: no
---

總結本篇主要是先了解 SSL/TLS 基本概念,尤其是 SSL Handshake 流程,至於有關 SSL/TLS 更多的資安風險和除錯方式將在之後進行說明。

相關資源