資安管理

資安管理 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 伺服器內建的功能就能夠解決上述的問題。此外若是瀏覽器顯示未受信任的憑證或憑證錯誤的訊息時,則不會影響網站系統的運作,但是若網站系統解決方案中有需要客戶端應用程式或網站應用程式進行安全連線時,就需要將憑證匯入至伺服器中,請注意不同網站系統解決方案匯入憑證的方式皆不相同,並且可能需要按照順序匯入根憑證、中繼憑證和網站憑證,以利網路系統的所有功能正常運作。

相關資源

資安管理 OWASP Top 10 (1)

基本介紹

教學目標

初步了解 OWASP Top 10 十大資安風險。

重點概念

首先開放網站應用程式安全專案 (The Open Web Application Security Project,OWASP) 每隔幾年就會匯整出十大網路資安的風險,在 2017 年 11 月 20 日則公佈最新版本,分別為:

  1. 注入攻擊 (Injection)
  2. 無效身份認證 (Broken Authentication)
  3. 敏感資料外洩 (Sensitive Data Exposure)
  4. XML 外部處理器漏洞 (XML External Entity,XEE)
  5. 無效的存取控管 (Broken Access Control)
  6. 不安全的組織設定 (Security Misconfiguration)
  7. 跨站攻擊 (Cross-Site Script,XSS)
  8. 不安全的反序列化漏洞 (Insecure Deserialization)
  9. 使用已有漏洞的元件 (Using Components with Known Vulnerabilities)
  10. 記錄與監控不足的風險 (Insufficient Logging & Monitoring)

接著其中相較於 2013 年主要新增 XML 外部處理器漏洞、不安全的反序列化漏洞和記錄與監控不足風險三大資安風險,主要與越來越多微服務的應用有關,因此當我們在快速提供服務的過程中,更需要許多跌謹的資安驗證和授權的程序,避免因為忽略而造成敏感資料的外洩。

XML 外部處理器漏洞

XML 外部處理器漏洞,主要是因為以 XML 為基礎的網路應用程式沒有管控好權限,直接處理 XML 語法的請求或上傳,此時攻擊者僅需要加入一個惡意的 XML 文件,就能夠鎖定 XML 處理器漏洞進行攻擊,進而導致資料外洩的風險。更進一步,目前 XML 訊息主要採用簡單物件存取協定 (Simple Object Access Protocal,SOAP) 簡化網路應用程式訊息傳遞的標準格式,此時若是採用 SOAP 1.2 之前版本的訊息交換格式,則預設皆有 XML 外部處理器漏洞的風險,因此容易遭受到阻斷式服務的攻擊。所以建議採用 SOAP 1.2 版本避免因為 XML 外部處理器漏洞的風險遭受到阻斷式服務的攻擊。

不安全的反序列化漏洞

不安全的反序列化漏洞主要是針對 Java 、 Node.js、…等平台常見的攻擊方式,簡單來說,序列化主要會將執行時的變數和程序物件轉換為可以儲存或傳輸形式的過程,形式主要有 JSON、XML 或二進位格式,反序列化則是將序列化形式轉換為記憶體變數和程序物件的相反過程,此時攻擊者若可以將資料進行反序列化,那將會對記憶體中的變數和程序物件產生影響, 之後將會導致遠端程式碼執行、重播攻擊、注入攻擊、特權升級攻擊、…等攻擊方式成功。所以建議針對任何序列化的物件落實完整性的檢查,像是數位簽章,以利防止惡意物件的建立或資料被篡改。

記錄與監控不足的風險

記錄與監控不足的風險主要是因為微服務快速興起,卻沒有針對應用程式進行記錄和監控,此時因為記錄和監控的不足,所以當資安事件發生時就無法立即處理與解決問題,同時讓攻擊者有機會更進一步攻擊系統。所以建議確保所有使用者登入、存取控制失敗和伺服器端輸入驗證失敗皆進行記錄,以利識別可疑或惡意的帳戶,並且保留足夠的時間允許延遲進行數位鑑識分析。

再來第一名注入攻擊,不僅只是 SQL 注入攻擊,更進一步包括作業系統、LDAP、SQL 、NoSQL 、… 等注入攻擊,當惡意程式語法輸入時,若沒有經過妥善的檢查和驗證將會造成資安的風險,所以建議使用安全的 API,或者使用參數化的介面,以及使用物件關係對應 (Object Relational Mapping,ORM) 工具。第二名無效身份認證,主要是因為網路應用程式必須進行身份認證和工作階段管理,此時若導入方式不正確,就有可能會讓攻擊者取得密碼、金鑰、工作階段存取令牌、…等暫時或永久取得使用者的身份資訊。所以建議在可能的情況下落實多因素的身份驗證機制,以利避免無效身份認證的攻擊成功。第三名敏感資料外洩,主要是因為有許多網路應用程式對於金融資訊、健康資料和個人資料的保護不足,若是被攻擊者取得,將能夠進行信用卡詐欺、身份竊取或其它犯罪行為。所以建議針對應用程式的處理、存儲或傳輸的資料進行分類,並且根據個人隱私法、監管機關的要求和業務的需求確定哪些資料是敏感性資料,以利進行額外的保護措施。

最後跨站請求偽造攻擊 (Cross-Site Request Forgery,CSRF) 沒有在 2017 年十大資安風險之一,同時許多開發框架和套裝軟體皆已經內建跨站請求偽造攻擊的風險防禦機制,但還是要特別小心僅慎,像是跨站攻擊雖然也有許多成熟的自動化掃描工具,能夠加速漏洞修補的速度,但是風險並沒有因此減少還是在十大資安風險之一。此外若是沒有針對開發框架和套件軟體進行安全的組態設定,則將會因為不安全的組態設定提高被攻擊的風險,此時必須定期做到系統更新與升,以利確保系統安全,避免攻擊者使用已有漏洞的元件進行攻擊。至於無效的存取控管,則僅能藉由嚴格的存取控管,以利避免攻擊者利用漏洞存取沒有經過授權的功能或查看敏感資料。同時授權使用者、群組和角色存取的功能也是許多套裝軟體解決方案基本的安全功能之一,所以存限控管會是資安管理的首要第一步,有完善的存限控管機制將能夠降低被攻擊的資安風險。

總結 OWASP Top 10 僅是風險框架,其會因為技術發展而持續進行變動,因為除了十大資安風險之外,針對企業和組織則還有許多更需要特別注意的資安風險,以利通透過稽核或法遵的檢查。至於下一步要如何開始進行,則可以參考「OWASP Top 10 - 2017 The Ten Most Critical Web Applications Security Risks」報告文件。

相關資源

資安管理 WebGoat (1)

基本介紹

教學目標

初步了解 WebGoat 平台有系統學習網站漏洞,以利進行後續資安管理。

重點概念

首先 WebGoat 平台主要是由 OWASP 研究開發的弱點測試平台,主要是以 J2EE 進行開發的網站,其中設計了大量的網站漏洞,同時一步一步引導使用者如何利用這些漏洞進行攻擊的方式,以利我們學習資安管理。

接著請先從 OWASP WebGoat 專案官方網站,下載「webgoat-container-7.1-exec.jar」檔案,下一步執行下述指令就能開啟 WebGoat 平台。

1
$ java -jar webgoat-container-7.1-exec.jar

再來開啟瀏覽器輸入「127.0.0.1:8080/WebGoat」網址,下一步輸入使用者帳號和密碼為「webgoat」進行登入 WebGoat 平台,此時畫面的右方為課程分類,中間為課程內容主要有顯示程式碼、解決方式、目標與目的和提示等功能。左方為 HTTP 請求的資料主要顯示 Cookies 和參數。

最後課程分類主要以攻擊方式的類別為主,總共有十六個類別,每個類別還有許多不同的攻擊手法,分別為:

  1. Access Control Flaws
  2. AJAX Security
  3. Authentication Flaws
  4. Buffer Overflows
  5. Code Quality
  6. Concurrency
  7. Cross-Site Scripting (XSS)
  8. Improper Error Handling
  9. Injection Flaws
  10. Denial of Service
  11. Insecure Communication
  12. Insecure Storage
  13. Malicious Execution
  14. Parameter Tampering
  15. Session Management Flaws
  16. Web Services

總結我們可以透過 WebGoat 平台將能夠有系統的學習利用網站漏洞進行攻擊的手法,唯有清楚知道如何駭客如何攻擊網站,才能夠進行網站防守,同時目前許多企業的解決方案皆還是以 J2EE 平台為主,此時我們要能夠因應不同的攻擊手法採取適當的設定,以利達到適當的資安管理。

相關資源

資安管理 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 更多的資安風險和除錯方式將在之後進行說明。

相關資源