SSL握手協議
出自 MBA智库百科(https://wiki.mbalib.com/)
- SSL握手協議(SSL Handshake Protocol)
目錄 |
什麼是SSL握手協議[1]
SSL握手協議指在SSL協議中，客戶端和伺服器首先通過握手過程來獲得密鑰，此後在記錄集協議中使用這個密鑰來加密客戶端和伺服器間的通信信息。握手過程首先採用非對稱加密的方法來交換信息，使得伺服器獲得客戶端提供的對稱加密的密鑰(pre_master_secret)，然後伺服器和客戶端使用這個pre_master_secret來產生會話密鑰。
SSL握手協議的階段[2]
Handshake由一些客戶與伺服器交換的消息所構成，每一個消息都含有以下三個欄位。
(1)類型(Type)，1個位元組：表示消息的類型，總共有十種。 (2)長度(Length)，3個位元組：消息的位組長度。
(3)內容(Content)，大於或等於1個位元組，與此消息有關的參數。
下圖說明客戶端與伺服器要產生一條新連接時，所要進行的初始交換過程。這個交換過程可以視為四個階段，即建立安全能力、伺服器認證與密鑰交換、客戶端認證與密鑰交換、完成。
- 1．建立安全能力
這個階段的主要工作是要建立一條邏輯連接，以及與這個連接有關的安全功能。整個交換過程由客戶端送出一個client_hello消息來開啟，這個消息含有下麵幾個參數。
(1)Version(版本)：客戶端能夠用的SSL最高版本。
(2)Random(隨機值)：一個由客戶端產生的隨機結構，包含一個32位長的時間戳，以及一個由隨機數產生器所產生的28位元組長的數字。
(3)Session ID(會話標識符)：不定長度的session識別碼。如果Session ID欄位填上任何非零的數值，就表示客戶端想繼續使用上一個SSL連接，並且更新此連接的參數，或者在目前的session產生一個新的連接。如果此欄位的值為零，則表示客戶端希望重新建立一個新的session，並且產生一個新的連接。
(4)CipherSuit(密碼套件)：客戶端能夠支持的加密演算法列表，這個列表會根據使用優先順序由大到小排列。在這列表上的每一個密碼套件都會定義其使用的密鑰交換演算法以及加密演算法。
(5)Compression Methods(壓縮演算法)：客戶端能夠支持的壓縮演算法列表。
當客戶端送出client_hello消息後，會等待伺服器響應一個server_hello消息。這個消息所包含的參數與client_hello消息夾帶的參數相同。對於server_hello消息來說，每個欄位用法如下。
(1)Version：伺服器允許客戶端使用的SSL版本。這個版本為客戶端以及伺服器雙方都能支持的最高版本。
(2)Random：由伺服器所產生的隨機結構。與客戶端所產生的隨機結構類似，但彼此獨立。
(3)Session ID：假如客戶端傳送過來的Session ID欄位為非零的數值，那麼伺服器會將這個欄位的值設定成客戶端所指定的Session ID。否則伺服器將會提供客戶端新的會話，併為此欄位填上代表這個新會話的標識符。
(4)CipherSuit：伺服器從客戶端所提供的密碼套件列表中挑出的加密演算法組合。
(5)Compression Method：伺服器從客戶端所提供的壓縮方法列表中挑出的方法。密碼套件參數所包含的第一個元素為密鑰交換的演算法(傳統加密以及計算消息認證碼時所會用到的密鑰的交換方式)。有以下幾種提供的密鑰交換演算法。
(1)RSA：由接收端的公開密鑰來將密鑰加密起來。為了事先得知接收端的公開密鑰，其公開密鑰的證書必須要能讓發送端取得。
(2)Fixed Diffie-Hellman：Diffie-Hellman密鑰交換法。伺服器的證書中會包含經認證機構簽署過的Diffie-Hellman公開密鑰參數。假如需要對客戶端做認證，則客戶端會將Diffie-Hellman公開密鑰參數包含在證書內，否則客戶端會將這些參數放在密鑰交換的消息中。由這個方法，使用固定的公開密鑰經過Diffie-Hellman演算法計算後，雙方會建立起一個固定的密鑰。
(3)Ephemeral Diffie-Hellman：這個方法是用來產生短暫的(Ephemeral)密鑰。Diffie-Hellman公開密鑰會利用傳送者私人RSA密鑰或者是DSS密鑰來做簽署，並且互相交換。而接收者隨後便能使用對應的公開密鑰來核對這個簽名。除此之外，接收者也能利用證書來確認公開密鑰的真實性，這將會是Diffie_Hellman三種選擇方式中最安全的一種，因為它所產生的是一把短暫並且經過驗證的密鑰。
(4)Anonymous Diffie-Hellman：基本上使用Diffie-Hellman演算法，但是不經過認證。也就是說，雙方都會將自己的Diffie-Hellman公開參數在沒有經過認證的程式下，直接傳送給對方。這個方式很有可能受到中間人攻擊(man-in-the-middle attack)，攻擊者可以向雙方發起匿名的Diffie-Hellman交換攻擊。
(5)Fortezza：在Fortezza架構中所定義的方法。
CipherSpec參數包含以下這些欄位。
(1)CipherAlgorithm：加密演算法。如RC4，RC2，DES，3DES，DES40，IDEA，Fortezza。
(2)MACAlgorithm：消息認證演算法。MD5或是SHA-l。
(3)CipherType：加密類型。串流式或區塊式。
(4)IsExportable：真或偽。
(5)HashSize：Hash值長度。16位元組(使用MD5時)或20位元組(使用SHA-1時)。
(6)KeyMaterial：用來產生寫入密鑰的數據。
(7)IVsize：CBC加密模式中，初始向量的長度。
- 2．伺服器認證與密鑰交換
當伺服器送出server_hello消息後，或客戶端需要驗證伺服器的身份時，伺服器可以將其證書資料傳送給客戶端，它可能是單一(同一領域)或者是一連串的(跨領域)X．509證書。除了使用匿名Diffie-Hellman密鑰交換演算法，任何一種密鑰交換程式都需要一個證書消息(Certificate Message)。請註意，假如使用fixed Diffie-Hellman法，則這個證書消息的功能就如同伺服器的密鑰交換消息，因為此消息包含了伺服器的Diffie-Hellman公開參數值。
接著，假如有需要的話，伺服器會送出server_key_exchange消息。在下麵的兩種情況下，伺服器不需要送出這個消息：伺服器已經送出包含fixed Diffie-Hellman參數的證書；使用RSA密鑰交換演算法。
- 3．客戶端認證與密鑰交換
當客戶端收到伺服器送出的server_done消息後，首先，假如有需要的話，客戶端應該核對伺服器提供的證書是否正確，接著再確認server_done消息中所攜帶的參數是否能夠接受。如果這些都能滿足的話，則客戶端會響應一個或多個消息給伺服器。如果之前伺服器發出certificate_request消息，要求客戶端送出自己的證書，那麼客戶端就得先響應一個certificate消息給伺服器。如果客戶端沒有適當的證書可以提供，則會改送一個no_certificate消息給伺服器。
接著，下一個交換的消息是client_key_exchange消息。在第三階段中，一定要送出這個消息，至於其內容則要看客戶端所選定的公開密鑰演算法類型而定，如：
(1)RSA：客戶端先產生一個48B長的pre-mastersecret。然後，若伺服器提供其他的證書，則利用此證書內的公開密鑰將此密鑰加密，不然就用server_key_exchange消息中攜帶的暫時性RSA密鑰來加密。這個“預先的”密鑰能夠用來產生master secret。
(2)Ephemeral或Anonymous Diffie-Hellman：若使用這兩種演算法，則客戶端傳送自己的公開Diffie-Hellman參數。
(3)Fixed Diffie-Hellman：若使用這種演算法，則之前客戶端在傳送證書消息時，就已經包含了自己的公開Diffie-Hellman參數。所以client_key_exchange消息這時內容就會是空的。
(4)Fortezza：客戶端傳送自己的Fortezza參數。若之前客戶端需要傳送自己的證書，則在這個階段的最後，它也會連帶送出一個certificate—verify消息給伺服器，以便提供此證書的明確證明，而這個證明就是一個根據之前消息所計算出的Hash值。這個消息只有客戶端證書擁有簽名能力時(除了那些包含fixed Diffie-Hellman參數的證書以外的所有證書)，才會跟著送出。因此消息會對此Hash值做簽名，定義如下：
CertificateVerify．signature．md5_hash
MD5(master_secret||pad_2||MD5(handshake_messages || master-secret||pad_1))；
Certificate．signature．sha+_hash
SHA(master_secret||pad_2||SHA(handshake_messages||master-secret||pad_1))；
其中，pad_l與pad_2就是之前為MAC所定義的值。從client_hello消息開始後，所有通過Handshake協議所傳送或接收的消息都屬於handshake_messages。master_secret是一個經過計算的密鑰。假如使用者的數字簽名是DSS，則這個密鑰將會被用來加密SHA-1 Hash值串接後的結果。不管哪一種情形，其目的都是希望利用客戶端的證書來核對客戶端是否擁有正確的私鑰。就算有人濫用客戶端的證書，因為他沒有正確的客戶端私鑰，所以也沒有辦法送出這個certificate_verify消息。
- 4．完成
這個階段完成了建立一條安全連接所應該做的設定工作。客戶端會送出個change_cipher_spec消息，並且將目前的密碼套件狀態更新成即將要使用的密碼套件狀態。請註意，這個消息並不屬於Handshake協議的一部分，而是利用加密演算法修正協議所送出的消息。緊接著，客戶端利用之前與伺服器協議而得到的演算法、密鑰，來傳送最後的finished消息。這個消息用來證明密鑰交換以及認證的過程已經順利完成，其內容包含兩個Hash值：
MB5(master_secret||pad_2||MD5(handshake_messages||Sender||master-secret||pad1))；
SHA(master_secret||pad_2||SHA(handshake_messages||Sender||master-secret||pad_1))；
其中，Sender是一個代碼，用來表示此消息為客戶端所發出。除了這個finished消息以外，handshake_messages包含所有經由handshake消息所傳送的數據。
為了響應這兩個消息，伺服器會傳送自己的change_cipher_spec消息，並且將目前的密碼套件狀態更新為即將要使用密碼套件狀態，最後再送出finished消息。當這些handshake的步驟都完成後，客戶端與伺服器就能開始傳送應用層的數據了。
牛