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

 

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 防護的 TelnetE-mailFTP LDAP 等等。如此一來,SSL 已不再是網頁系統的專屬安全機制,漸成為通用型網路應用的安全協定,更成為安全性電子商務中不可或缺的工具。

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

Netscapehttp://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 LayerSSL 記錄層』(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 TLSRFC 2830 制定 LDAP over TLSRFC 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_helloSSL 是屬於主從式架構,所有連線都是由客戶端主動提出,再由伺服端回應客戶端的要求。然而 client_hello 是啟動協商一個 Session 的命令,再依照安全機制的強度如何,client_hello 訊息內也許會包含不同的參數,譬如,交換鑰匙所需的亂數、加密套件、以及壓縮方法。一個加密套件裡可能包含所欲協商的加密演算法、訊息認證碼(MAC)等的演算法代號(IANA 指定)。

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

    • certificateX.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

雜湊值

 

主講人:粘添壽博士

 

資訊與網路安全技術