資訊與網路安全技術：第 八章 安全性網頁系統  上一頁      下一頁

 

8-2 SSL 安全協定

 內容：

8-2-1 SSL 協定 標準

『安全性插座層』（Secure Socket Layer, SSL）是由網景（Netscape）公司所展出來，目前已修正到第三版（SSL v3.0）。網景公司將 SSL 安裝於該公司的瀏覽器（Netscape Browser）與網頁伺服器上，使它們之間可以協議出雙方可接受的安全機制並傳輸加密後訊息，如此以達到安全性需求。

該公司起初免費提供支援 SSL 的瀏覽器，無形中已大大刺激伺服器的銷售量，致使SSL 協定漸被其他瀏覽器與伺服器接受（如 Microsoft IE），支援 SSL 協定已成為網頁系統必備的條件，從此以後，其他應用系統也開始思考如何將 SSL 協定崁入其中，使成為具有 SSL 防護的 Telnet、E-mail、FTP 或 LDAP 等等。如此一來，SSL 已不再是網頁系統的專屬安全機制，漸成為通用型網路應用的安全協定，更成為安全性電子商務中不可或缺的工具。

ITEF（Internet Engineering Task Force）有感於 SSL 協定漸漸成為工業標準，且認為其安全性是可靠的，便於 1999 年發表『傳輸層安全』（Transport Layer Security, TLS）協定，並由 RFC 2246 與 RFC 3546 發佈流傳。基本上，TLS 是以 SSL v3.0 為基礎，運作程序也大致相同，唯選用的身分證演算法與訊息格式稍有不同。SSL v3.0 規格的官方網站如下：

Netscape：http://wp.netscape.com/eng/ssl3/draft302.txt

然而，TLS 規格可由 RFC 2246 中取得；讀者可以發現兩份規格大致上相同，都是利用 C 語言來描述。本章先以介紹 SSL v3.0 的相關技術為主，然後再列出 SSL 與 TLS 之間的相異點，便可完整學習兩種協定。

8-2-2 SSL 協定堆疊

SSL 是屬於『層次協定』（Layer Protocol），擁有獨立的層次介面讓各種應用系統連接，其層次堆疊如圖 8-3 所示。SSL 協定包含兩個主要層次：『SSL 握手層』（SSL Handshake Layer）與『SSL 記錄層』（SSL Record Layer），其中 SSL 握手層包含『握手協定』（Handshake Protocol）、『變更密文規格協定』（Change Cipher Specification Protocol）與『警告協定』（Alert Protocol）等三個協定；SSL 記錄層只有一個『記錄協定』（Record Protocol）。

『握手協定』是被用來認證雙方身分與協商相關安全機制，協商完成之後，再利用『記錄協定』來傳輸加密後的訊息。在握手協定運作當中，如有特殊異常狀態發生時，則利用『警告協定』通知對方。一旦協議完成，便利用『密文規格變更協定』來通知對方改變加密規格。另外，當執行『握手協定』時，其訊息也是需要經過『記錄協定』的封裝，但協議完成之後，高層應用協定（如 HTTP）便可以直接透過『記錄協定』來傳輸訊息。

圖 8-3 SSL 協定堆疊

基本上，SSL 必須架設在 TCP 協定之上，也就是說，僅能使用於連接導向的傳輸服務。但為了銜接各種應用系統，針對各系統有其專屬埠口，並以前置『安全性』（Secure）來標示與原來系統之間的不同，如表 11-1 所示。其中，HTTP over TLS 規範由 RFC 2818 制定；RFC 3207 制定 SSMTP over TLS 規格；RFC 2595 規範 POP 與 IMAP over TLS；RFC 2830 制定 LDAP over TLS；RFC 2712 將 SSL 嵌入於 Kerberos 系統內。

8-2-3 SSL 握手層

圖 8-4 為 SSL 四種協定的封裝格式。SSL 握手層包含了變更密文規格、警告與握手等三種協定，其訊息封裝格式說明如下。

【（A）變更密文規格協定封裝】

變更密文規格協定是用來通知對方改變安全套件。當雙方透過握手協定協議出安全套件之後，利用此訊息通知對方改變密文規格的時機，至於接收此訊息的另一方，則必須準備以新的密文規格和對方通訊。此訊息封裝包含下列兩個欄位（圖 11-4 (a)）：

  • Content Type（內文型態，簡化 Type）：每一個訊息封裝上都有此欄位，用來表示該訊息的內文型態。本訊息型態為 20。

  • Change Cipher Spec：一個位元組。內容為 1，表示通知對方的意思。

圖 8-4 SSL 四種協定的封包格式

【（B）警告協定封裝】

雙方利用 SSL 協定通訊的情況下，當某一方發現有異常障礙時，便利用警告協定通知對方。譬如，利用握手協定來協商加密套件，當某一方不能接受對方所提出的加密規格時，可利用警告協定通知對方，並註明不能接受的原因。此訊息封裝包含三個欄位（如圖 11-4 (b) 所示），如下：

  • Content Type：警告協定的內文型態為 21。

  • Alter Level：警告層次。此欄位表示異常狀態的嚴重性，可分為兩個層次：Warning（警報性，1）與 Fatal（致命性，2），前者為警示而已，後者表示發生嚴重異常狀態。

  • Alter Description：警告描述。此欄位以數值描述發生警告的狀況，有下列發生原因。

【（C）握手協定封裝】

握手協定的功能是認證雙方憑證與協商安全套件，其封裝訊息包含一連串的客戶端與伺服端之間的交換訊息。圖 11-4 (c) 為握手協定的封包格式，包含三個欄位，各欄位功能如下：

  • 內文型態（Content Type）：握手協定的內文型態為 22。

  • 握手型態（Handshake Type）：表示該封包所承載的訊息格式，在 SSL 協定中，共定義十種訊息（或稱命令）格式，如表 11-2 所示。各種命令功能如下：

    • hello_request：伺服端隨時都有可能發送此訊息給客戶端，此訊息為簡化的通知訊息，用來要求客戶端重新傳送 Hello 訊息，作為協議雙方的安全機制。

    • client_hello：SSL 是屬於主從式架構，所有連線都是由客戶端主動提出，再由伺服端回應客戶端的要求。然而 client_hello 是啟動協商一個 Session 的命令，再依照安全機制的強度如何，client_hello 訊息內也許會包含不同的參數，譬如，交換鑰匙所需的亂數、加密套件、以及壓縮方法。一個加密套件裡可能包含所欲協商的加密演算法、訊息認證碼（MAC）等的演算法代號（IANA 指定）。

    • server_hello：伺服端收到 Client_hello 之後，選擇可以接受的安全參數，再封裝在該訊息的承載內容，回應給客戶端。client_hello 與 server_hello 兩訊息除了啟動雙方協議一個 Session 外，也直接協議雙方可以接受的安全機制。

    • certificate：X.509v3 憑證的內容。當對方要求憑證（certificate_request）作為身分證明時，則必須傳送此訊息證明之。憑證的內容必須包含交換鑰匙的加密套件，以及相對應的交換鑰匙演算法。

    • server_key_exchange：當伺服端傳送憑證給客戶端之後，必須立即發送此訊息來達成雙方的密鑰交換。交換鑰匙過程中的所有訊息都藉由憑證內指定的加密套件保護；經過雙方鑰匙交換（與 client_key_exchange）之後，會建立一個 SSL/TLS 通訊連線所需的主密鑰（Master Secret），而此主密鑰就是被利用於 SSL 記錄協定中加密鑰匙的依據。

    • certificate_request：一個非匿名的伺服器可能會發送此訊息，作為要求客戶端傳送憑證以證明他自己的身分。如果選擇此類型的加密套件，在此訊息之後，必須緊接著鑰匙交換訊息來決定主秘鑰。

    • server_hello_done：伺服端 Hello 訊息傳送完畢，接著會等待客戶端傳送 Hello 訊息。意味著，伺服端已經將相關安全機制的參數全部傳送給客戶端了。

    • certificate_verify：此訊息被使用於證實客戶憑證的正確性，它必須接在憑證訊息之後傳送，並攜帶著一個數位簽章作為要求對方確認憑證的內容。

    • client_key_exchange：客戶端鑰匙交換訊息，其中包含有協議建立主密鑰的相關參數，以及數位簽章。

    • finished：協議完成訊息，一般都接在『變更密文協定』訊息之後傳送，來證實已成功的協議加密套件與認證完成。本訊息是協議完成演算法、主鑰匙、以及相關安全機制之後，通知對方的第一個訊息；首先客戶端將這些資料經由某一種演算法計算出一個雜湊值，並將其包裝在 finished 訊息內發送給伺服端，伺服端收到此訊息後，也使用同樣的演算法計算出一個雜湊值，如果兩者相同，則表示雙方所擁有的安全套件是一樣的。

  • 長度（Length）：三個位元長度。表示後面訊息內容（Content）欄位的長度。

  • 內容（Content）：此欄位存放所攜帶訊息，長度不定。各種訊息格式（命令）所需要的參數都不相同，如表 11-2 中參數欄位所示。

表 8-2 SSL/TLS 握手協定的訊息型態

訊息（命令）型態

參數（內容）

hello_request

無

client_hello

版本、亂數、會議 ID、加密套件、壓縮方法

server_hello

版本、亂數、會議 ID、加密套件、壓縮方法

certificate

一連串的 X.509v3 憑證內容

server_key_exchange

鑰匙材料、數位簽章

certificate_request

憑證型態、認證中心

server_done

無

certificate_verify

數位簽章

client_key_exchange

鑰匙材料、數位簽章

finished

雜湊值

翻轉工作室：粘添壽

 

 

資訊與網路安全技術

 

 

翻轉電子書系列：