|
|
|
8-5 SSL 握手協定
8-5-1 SSL 握手協定運作 『握手協定』（Handshake Protocol）是整個 SSL 協定的運作核心，客戶端與伺服器之間利用握手協定確認雙方身份，並協議出雙方可接受的安全機制，下列是握手協定的運作程序中，所必須完成工作的步驟：
圖 8-6 為 SSL 握手協定的運作程序，利用四個協商階段完成上述的工作，概略說明如下：由客戶端啟動第一階段協商，採用 Hello 訊息來協商所能接受的安全套件，並建立『前置主密鑰』（Pre-master Secret）作為保護爾後交換鑰匙的訊息；第二階段與第三階段的功能是，雙方互相認證對方憑證與交換鑰匙材料，並建立『主密鑰』以作為傳輸資料所用；第四階段的功能是，雙方確認所建立的安全套件（主密鑰與 MAC 演算法）無誤之後，依照安全套件與主密鑰計算出相關安全參數，然後啟動變更密文規格協定，並通知對方以完成協議。
圖 8-6 SSL/TLS 握手協定的運作程序 值得注意的是，並非每一個 Session 的安全機制都如同圖 11-6 般的完善，也許會有不同的選擇。譬如，若伺服端不需要認證客戶端的憑證，便不用送出 certificate_request 訊號，客戶端也不會傳送憑證給伺服端。因此，在圖 11-6 中的訊號如果有加上星號（*）記號，表示該訊息是選項項目，需依照安全機制的強度選擇使用，以下分別敘述各階段的運作程序與命令格式。 8-5-2 第一階段：協商安全套件 第一階段裡包含兩個 Hello 訊息（圖 8-3 訊號 (1) 與訊號 (2)），主要用來交換亂數與協議雙方可以接受的安全套件，每一訊息（client_hello 與 server_hello）包含下列參數：
經過第一階段協商之後，必須能協商出雙方可以接受的安全套件與壓縮方法。如果伺服端無法接受客戶端所建議的安全套件時，伺服端會發送 hello_request 訊息，要求客戶端重新建議新的方案。 在 SSL 規範裡，安全套件可以區分為：『鑰匙交換』（Key Exchange）與『加密規格』（Cipher Specification）兩部份，前者的功能是雙方以交換鑰匙材料方式製作共享的『前置主密鑰』（之後再計算成主密鑰）；後者是協商加密系統的相關參數。SSL 鑰匙交換協定是以 RSA、Diffie-Hellman 與 Fortezza 等三種密碼系統為基礎，其中 Diffie-Hellman 密碼系統又可區分為三種模式；共計有五種協定可供協商，分別敘述如下：
除了協議鑰匙交換協定之外，在 Hello 訊息內也包含加密規格可供雙方協議使用，加密規格有下列協商項目：
8-5-3 第二階段：伺服器確認與鑰匙交換 經過第一階段協商後，雙方已協議出鑰匙交換協定與加密套件，第二階段利用協議出的鑰匙交換協定，互相交換雙方的鑰匙材料，並從事伺服端身份的確認，運作程序如圖 8-3 中訊號 (3) ~ (6)。如果第一階段協議當中需要伺服端憑證時，伺服端會傳送自己的憑證資料（X.509v3）給客戶端。譬如，採用固定的 Diffie-Hellman 演算法時，便需要伺服端的憑證，這是因為憑證中有簽署過的鑰匙材料（亂數）。接著，是否需要傳送 server_key_exchange 訊息的條件，完全決定於第一階段所協議的安全套件，一般若無需交換訊息建立秘密鑰匙，就不需要此訊息，如匿名的 Diffie-Hellman 演算法，因為用來計算秘密鑰匙的亂數是固定數值，所以不需要雙方交換亂數；或者是採用 RSA 鑰匙交換。 接下來，certificate_request 訊息也是選項項目，如果雙方協議的安全套件需要認證客戶端，或者需要客戶憑證上所簽署的亂數時，可發送此訊息要求客戶端傳送憑證資料。最後伺服端以 server_done 表示已完成相關訊息的傳送，之後伺服端就進入等待狀態，預備接收客戶端的安全訊息。 8-5-4 第三階段：客戶端確認與鑰匙交換 當客戶端受到 sever_done 訊息後便進入第三階段的協商（圖 11-6 (7) ~ (9)）。如果安全套件裡需要客戶端的憑證時，則客戶端會傳送憑證相關訊息給伺服端（certificate），接下來的『客戶鑰匙交換』（client_key_exchange）訊息是不可以或缺的，但內容是隨鑰匙交換協定而異：
最後，如果客戶端有傳送憑證給伺服端，則必須送出『憑證驗證』（certificate_verify）訊息，來驗證客戶端憑證。此訊息內攜帶著客戶端憑證內資料的雜湊值，並經過客戶端私有鑰匙簽署過。伺服端利用相對應的公開鑰匙將此簽章解密，並驗證所接收憑證資料的雜湊值是否與 certificate_verify 內的雜湊值相同。 8-5-5 第四階段：完成 雙方協商完成之後，亦即已完成建立一個會議（Session）連結。如圖 11-6 (10) ~(13) 所示，客戶端送出『變更密文規格』訊息來要求伺服端正式改變安全協定，此訊息並非握手協定所有，而是利用密文變更規格協定來完成；相同的，伺服端也會發送此訊息給客戶端。收到變更密文規格訊號之後，雙方會將新的安全機制複製到現有的加密規格內。另外，『完成』（finished）訊息就較為複雜，除了驗證雙方協議是否成功之外，還必須完成下列安全參數設定：（產生方式容後介紹）
值得注意的是，雖然客戶端與伺服端所使用的加密鑰匙、MAC 鑰匙與起始向量並不相同，但雙方都擁有這些安全參數，祇不過各自採用不同的安全參數來增加破解的困難度。例如，當伺服端收到客戶端所傳送的加密訊息，則利用客戶端的加密鑰匙來解密，反之亦然；如果攻擊者破解出客戶端的加密鑰匙，無法知曉伺服端的加密鑰匙。 8-5-6 簡化的協議方式 並非每一次 SSL 連線都需要經由上述四個階段的協商過程，始能建立雙方的安全機制。記得前面說過，一個已協商成功的安全機制稱之為『會議』（Session）連結，並且給予一個唯一的識別碼，稱為 Session ID，此外，當新的連線啟動時，也可以引用已協商完成的 Session。如圖 8-7 所示，客戶端啟動握手協定時，在 client_hello 訊息內指定使用哪一個 Session ID 的安全機制，只要伺服端同意，並將該 Session ID 置於 server_hello 訊息內，雙方便成功協議使用該 Session ID。接下來，便可直接用 change_cipher_spec 來啟動新的安全機制。
圖 8-7 簡化的握手協定 |
翻轉工作室：粘添壽
資訊與網路安全技術
翻轉電子書系列：
|
