當前位置：
首頁 >
SSL原理
發布時間：2025/3/15
19
豆豆
一 前言
首先要澄清一下名字的混淆：
1 SSL(Secure Socket Layer)是netscape公司設計的主要用于web的安全傳輸協議。這種協議在WEB上獲得了廣泛的應用。
2 IETF(www.ietf.org)將SSL作了標準化，即RFC2246,并將其稱為TLS（Transport Layer Security），從技術上講，TLS1.0與SSL3.0的差別非常微小。由于本文中沒有涉及兩者間的細小差別，本文中這兩個名字等價。
3 在WAP的環境下，由于手機及手持設備的處理和存儲能力有限，wap論壇（www.wapforum.org）在TLS的基礎上做了...S協議（Wireless Transport Layer Security），以適應無線的特殊環境。
我們從各式各樣的文章中得知，SSL可以用于保密的傳輸，這樣我們與web server之間傳輸的消息便是“安全的”。
而這種“安全”究竟是怎么實現的，最終有能實現多大程度的保密？本文希望能用通俗的語言闡明其實現原理。
二 整體結構概覽
SSL是一個介于HTTP協議與TCP之間的一個可選層，其位置大致如下：
－－－－－－－－－
| HTTP |
－－－－－－－－－
| SSL |
－－－－－－－－－
| TCP |
－－－－－－－－－
| IP |
－－－－－－－－－
如果利用SSL協議來訪問網頁，其步驟如下：
用戶：在瀏覽器的地址欄里輸入https://www.sslserver.com
HTTP層：將用戶需求翻譯成HTTP請求，如
GET /index.htm HTTP/1.1
Host http://www.sslserver.com
SSL層: 借助下層協議的的信道安全的協商出一份加密密鑰，并用此密鑰來加密HTTP請求。
TCP層：與web server的443端口建立連接，傳遞SSL處理后的數據。
接收端與此過程相反。
SSL在TCP之上建立了一個加密通道，通過這一層的數據經過了加密，因此達到保密的效果。
SSL協議分為兩部分：Handshake Protocol和Record Protocol,。其中Handshake Protocol用來協商密鑰，協議的大部分內容就是通信雙方如何利用它來安全的協商出一份密鑰。 Record Protocol則定義了傳輸的格式。
三 需要的加密方面的基礎知識
了解SSL原理需要一點點加密的概念，這里把需要的概念做一下簡單闡述：
加密一般分為三類，對稱加密，非對稱加密及單向散列函數。
對稱加密：又分分組密碼和序列密碼。
分組密碼是將明文按一定的位長分組，明文組經過加密運算得到密文組，密文組經過解密運算
（加密運算的逆運算），還原成明文組。
序列密碼是指利用少量的密鑰（制亂元素）通過某種復雜的運算（密碼算法）產生大量的偽隨機位流，用于對明文位流的加密。
解密是指用同樣的密鑰和密碼算法及與加密相同的偽隨機位流，用以還原明文位流。
CBC(Cipher Block Chaining)模式這個詞在分組密碼中經常會用到，它是指一個明文分組在被加密之前要與前一個的密文分組進行異或運算。當加密算法用于此模式的時候除密鑰外，還需協商一個初始化向量（IV），這個IV沒有實際意義，只是在第一次計算的時候需要用到而已。采用這種模式的話安全性會有所提高。
分組密碼的典型例子為DES,RC5,IDEA。
序列密碼的典型例子為RC4。
公鑰加密：
簡單的說就是加密密鑰與解密密鑰不同，分私鑰和公鑰。這種方法大多用于密鑰交換，RSA便是一個我們熟知的例子。
還有一個常用的稱作DH，它只能用于密鑰交換，不能用來加密。
單向散列函數：
由于信道本身的干擾和人為的破壞，接受到的信息可能與原來發出的信息不同，一個通用的辦法就是加入校驗碼。
單向散列函數便可用于此用途，一個典型的例子是我們熟知的MD5,它產生128位的摘要，在現實中用的更多的是安全散列算法（SHA），SHA的早期版本存在問題，目前用的實際是SHA－1，它可以產生160位的摘要，因此比128位散列更能有效抵抗窮舉攻擊。
由于單向散列的算法都是公開的，所以其它人可以先改動原文，再生成另外一份摘要。解決這個問題的辦法可以通過HMAC（RFC 2104）,它包含了一個密鑰，只有擁有相同密鑰的人才能鑒別這個散列。
四 密鑰協商過程
由于對稱加密的速度比較慢，所以它一般用于密鑰交換，雙方通過公鑰算法協商出一份密鑰，然后通過對稱加密來通信，當然，為了保證數據的完整性，在加密前要先經過HMAC的處理。
SSL缺省只進行server端的認證，客戶端的認證是可選的。以下是其流程圖（摘自TLS協議）。
Client Server
Clienth*llo -------->
Serverh*llo
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- Serverh*lloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
簡單的說便是：SSL客戶端（也是TCP的客戶端）在TCP鏈接建立之后，發出一個Clienth*llo來發起握手，這個消息里面包含了自己可實現的算法列表和其它一些需要的消息，SSL的服務器端會回應一個Serverh*llo，這里面確定了這次通信所需要的算法，然后發過去自己的證書（里面包含了身份和自己的公鑰）。Client在收到這個消息后會生成一個秘密消息，用SSL服務器的公鑰加密后傳過去，SSL服務器端用自己的私鑰解密后，會話密鑰協商成功，雙方可以用同一份會話密鑰來通信了。
五 密鑰協商的形象化比喻
如果上面的說明不夠清晰，這里我們用個形象的比喻，我們假設A與B通信，A是SSL客戶端，B是SSL服務器端，加密后的消息放在方括號[]里，以突出明文消息的區別。雙方的處理動作的說明用圓括號（）括起。
A：我想和你安全的通話，我這里的對稱加密算法有DES,RC5,密鑰交換算法有RSA和DH，摘要算法有MD5和SHA。
B：我們用DES－RSA－SHA這對組合好了。
這是我的證書，里面有我的名字和公鑰，你拿去驗證一下我的身份（把證書發給A）。
目前沒有別的可說的了。
A：（查看證書上B的名字是否無誤，并通過手頭早已有的CA的證書驗證了B的證書的真實性，如果其中一項有誤，發出警告并斷開連接，這一步保證了B的公鑰的真實性）
（產生一份秘密消息，這份秘密消息處理后將用作加密密鑰，加密初始化向量和hmac的密鑰。將這份秘密消息-協議中稱為per_master_secret-用B的公鑰加密，封裝成稱作ClientKeyExchange的消息。由于用了B的公鑰，保證了第三方無法竊聽）
我生成了一份秘密消息，并用你的公鑰加密了，給你（把ClientKeyExchange發給B）
注意，下面我就要用加密的辦法給你發消息了！
（將秘密消息進行處理，生成加密密鑰，加密初始化向量和hmac的密鑰）
[我說完了]
B：（用自己的私鑰將ClientKeyExchange中的秘密消息解密出來，然后將秘密消息進行處理，生成加密密鑰，加密初始化向量和hmac的密鑰，這時雙方已經安全的協商出一套加密辦法了）
注意，我也要開始用加密的辦法給你發消息了！
[我說完了]
A: [我的秘密是...]
B: [其它人不會聽到的...]
六 加密的計算
上一步講了密鑰的協商，但是還沒有闡明是如何利用加密密鑰，加密初始化向量和hmac的密鑰來加密消息的。
其實其過程不過如此：
1 借助hmac的密鑰，對明文的消息做安全的摘要處理，然后和明文放到一起。
2 借助加密密鑰，加密初始化向量加密上面的消息。
七 安全性
SecurityPortal在2000年底有一份文章《The End of SSL and SSH?》激起了很多的討論，
目前也有一些成熟的工具如dsniff（http://www.monkey.org/~dugsong/dsniff/）可以
通過man in the middle攻擊來截獲https的消息。
從上面的原理可知，SSL的結構是嚴謹的，問題一般出現在實際不嚴謹的應用中。常見的攻擊就是
middle in the middle攻擊，它是指在A和B通信的同時，有第三方C處于信道的中間，可以完全
聽到A與B通信的消息，并可攔截，替換和添加這些消息。
1 SSL可以允許多種密鑰交換算法，而有些算法，如DH，沒有證書的概念，這樣A便無法驗證B的公鑰
和身份的真實性，從而C可以輕易的冒充，用自己的密鑰與雙方通信，從而竊聽到別人談話的內容。
而為了防止middle in the middle攻擊，應該采用有證書的密鑰交換算法。
2 有了證書以后，如果C用自己的證書替換掉原有的證書之后，A的瀏覽器會彈出一個警告框進行警告，但又有多少人會注意這個警告呢？
3 由于美國密碼出口的限制，IE，netscape等瀏覽器所支持的加密強度是很弱的，如果只采用瀏覽器自帶的加密功能的話，理論上存在被破解可能。
八 代理
下面探討一下SSL的代理是怎樣工作的(可參見[6])。這可能與你開始想的不太一樣：）
當在瀏覽器里設置了https的代理，而且在瀏覽器里輸入了https://www.example.com之后，
瀏覽器會與proxy建立tcp鏈接，然后向其發出這么一段消息：
CONNECT server.example.com:443 HTTP/1.1
Host: server.example.com:443
然后proxy會向webserver端建立tcp連接,之后，這個代理便完全成了個內容轉發裝置。瀏覽器
與web server會建立一個安全通道，因此這個安全通道是端到端的，盡管所有的信息流過了proxy,
但其內容proxy是無法解密和改動的（當然要由證書的支持，否則這個地方便是個man in the middle攻擊的好場所，見上面的討論）。
九 關于證書
注意，如果對于一般的應用，管理員只需生成“證書請求”（后綴大多為.csr），它包含你的名字和公鑰，然后把這份請求交給諸如verisign等有CA服務公司（當然，連同幾百美金），
你的證書請求經驗證后，CA用它的私鑰簽名，形成正式的證書發還給你。管理員再在web server上導入這個證書就行了。如果你不想花那筆錢，或者想了解一下原理，可以自己做CA。
從ca的角度講，你需要CA的私鑰和公鑰。從想要證書的服務器角度將，需要把服務器的證書請求交給CA.
如果你要自己做CA，別忘了客戶端需要導入CA的證書（CA的證書是自簽名的，導入它意味著你“信任”這個CA簽署的證書）。
而商業CA的一般不用，因為它們已經內置在你的瀏覽器中了。
首先要澄清一下名字的混淆：
1 SSL(Secure Socket Layer)是netscape公司設計的主要用于web的安全傳輸協議。這種協議在WEB上獲得了廣泛的應用。
2 IETF(www.ietf.org)將SSL作了標準化，即RFC2246,并將其稱為TLS（Transport Layer Security），從技術上講，TLS1.0與SSL3.0的差別非常微小。由于本文中沒有涉及兩者間的細小差別，本文中這兩個名字等價。
3 在WAP的環境下，由于手機及手持設備的處理和存儲能力有限，wap論壇（www.wapforum.org）在TLS的基礎上做了...S協議（Wireless Transport Layer Security），以適應無線的特殊環境。
我們從各式各樣的文章中得知，SSL可以用于保密的傳輸，這樣我們與web server之間傳輸的消息便是“安全的”。
而這種“安全”究竟是怎么實現的，最終有能實現多大程度的保密？本文希望能用通俗的語言闡明其實現原理。
二 整體結構概覽
SSL是一個介于HTTP協議與TCP之間的一個可選層，其位置大致如下：
－－－－－－－－－
| HTTP |
－－－－－－－－－
| SSL |
－－－－－－－－－
| TCP |
－－－－－－－－－
| IP |
－－－－－－－－－
如果利用SSL協議來訪問網頁，其步驟如下：
用戶：在瀏覽器的地址欄里輸入https://www.sslserver.com
HTTP層：將用戶需求翻譯成HTTP請求，如
GET /index.htm HTTP/1.1
Host http://www.sslserver.com
SSL層: 借助下層協議的的信道安全的協商出一份加密密鑰，并用此密鑰來加密HTTP請求。
TCP層：與web server的443端口建立連接，傳遞SSL處理后的數據。
接收端與此過程相反。
SSL在TCP之上建立了一個加密通道，通過這一層的數據經過了加密，因此達到保密的效果。
SSL協議分為兩部分：Handshake Protocol和Record Protocol,。其中Handshake Protocol用來協商密鑰，協議的大部分內容就是通信雙方如何利用它來安全的協商出一份密鑰。 Record Protocol則定義了傳輸的格式。
三 需要的加密方面的基礎知識
了解SSL原理需要一點點加密的概念，這里把需要的概念做一下簡單闡述：
加密一般分為三類，對稱加密，非對稱加密及單向散列函數。
對稱加密：又分分組密碼和序列密碼。
分組密碼是將明文按一定的位長分組，明文組經過加密運算得到密文組，密文組經過解密運算
（加密運算的逆運算），還原成明文組。
序列密碼是指利用少量的密鑰（制亂元素）通過某種復雜的運算（密碼算法）產生大量的偽隨機位流，用于對明文位流的加密。
解密是指用同樣的密鑰和密碼算法及與加密相同的偽隨機位流，用以還原明文位流。
CBC(Cipher Block Chaining)模式這個詞在分組密碼中經常會用到，它是指一個明文分組在被加密之前要與前一個的密文分組進行異或運算。當加密算法用于此模式的時候除密鑰外，還需協商一個初始化向量（IV），這個IV沒有實際意義，只是在第一次計算的時候需要用到而已。采用這種模式的話安全性會有所提高。
分組密碼的典型例子為DES,RC5,IDEA。
序列密碼的典型例子為RC4。
公鑰加密：
簡單的說就是加密密鑰與解密密鑰不同，分私鑰和公鑰。這種方法大多用于密鑰交換，RSA便是一個我們熟知的例子。
還有一個常用的稱作DH，它只能用于密鑰交換，不能用來加密。
單向散列函數：
由于信道本身的干擾和人為的破壞，接受到的信息可能與原來發出的信息不同，一個通用的辦法就是加入校驗碼。
單向散列函數便可用于此用途，一個典型的例子是我們熟知的MD5,它產生128位的摘要，在現實中用的更多的是安全散列算法（SHA），SHA的早期版本存在問題，目前用的實際是SHA－1，它可以產生160位的摘要，因此比128位散列更能有效抵抗窮舉攻擊。
由于單向散列的算法都是公開的，所以其它人可以先改動原文，再生成另外一份摘要。解決這個問題的辦法可以通過HMAC（RFC 2104）,它包含了一個密鑰，只有擁有相同密鑰的人才能鑒別這個散列。
四 密鑰協商過程
由于對稱加密的速度比較慢，所以它一般用于密鑰交換，雙方通過公鑰算法協商出一份密鑰，然后通過對稱加密來通信，當然，為了保證數據的完整性，在加密前要先經過HMAC的處理。
SSL缺省只進行server端的認證，客戶端的認證是可選的。以下是其流程圖（摘自TLS協議）。
Client Server
Clienth*llo -------->
Serverh*llo
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- Serverh*lloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
簡單的說便是：SSL客戶端（也是TCP的客戶端）在TCP鏈接建立之后，發出一個Clienth*llo來發起握手，這個消息里面包含了自己可實現的算法列表和其它一些需要的消息，SSL的服務器端會回應一個Serverh*llo，這里面確定了這次通信所需要的算法，然后發過去自己的證書（里面包含了身份和自己的公鑰）。Client在收到這個消息后會生成一個秘密消息，用SSL服務器的公鑰加密后傳過去，SSL服務器端用自己的私鑰解密后，會話密鑰協商成功，雙方可以用同一份會話密鑰來通信了。
五 密鑰協商的形象化比喻
如果上面的說明不夠清晰，這里我們用個形象的比喻，我們假設A與B通信，A是SSL客戶端，B是SSL服務器端，加密后的消息放在方括號[]里，以突出明文消息的區別。雙方的處理動作的說明用圓括號（）括起。
A：我想和你安全的通話，我這里的對稱加密算法有DES,RC5,密鑰交換算法有RSA和DH，摘要算法有MD5和SHA。
B：我們用DES－RSA－SHA這對組合好了。
這是我的證書，里面有我的名字和公鑰，你拿去驗證一下我的身份（把證書發給A）。
目前沒有別的可說的了。
A：（查看證書上B的名字是否無誤，并通過手頭早已有的CA的證書驗證了B的證書的真實性，如果其中一項有誤，發出警告并斷開連接，這一步保證了B的公鑰的真實性）
（產生一份秘密消息，這份秘密消息處理后將用作加密密鑰，加密初始化向量和hmac的密鑰。將這份秘密消息-協議中稱為per_master_secret-用B的公鑰加密，封裝成稱作ClientKeyExchange的消息。由于用了B的公鑰，保證了第三方無法竊聽）
我生成了一份秘密消息，并用你的公鑰加密了，給你（把ClientKeyExchange發給B）
注意，下面我就要用加密的辦法給你發消息了！
（將秘密消息進行處理，生成加密密鑰，加密初始化向量和hmac的密鑰）
[我說完了]
B：（用自己的私鑰將ClientKeyExchange中的秘密消息解密出來，然后將秘密消息進行處理，生成加密密鑰，加密初始化向量和hmac的密鑰，這時雙方已經安全的協商出一套加密辦法了）
注意，我也要開始用加密的辦法給你發消息了！
[我說完了]
A: [我的秘密是...]
B: [其它人不會聽到的...]
六 加密的計算
上一步講了密鑰的協商，但是還沒有闡明是如何利用加密密鑰，加密初始化向量和hmac的密鑰來加密消息的。
其實其過程不過如此：
1 借助hmac的密鑰，對明文的消息做安全的摘要處理，然后和明文放到一起。
2 借助加密密鑰，加密初始化向量加密上面的消息。
七 安全性
SecurityPortal在2000年底有一份文章《The End of SSL and SSH?》激起了很多的討論，
目前也有一些成熟的工具如dsniff（http://www.monkey.org/~dugsong/dsniff/）可以
通過man in the middle攻擊來截獲https的消息。
從上面的原理可知，SSL的結構是嚴謹的，問題一般出現在實際不嚴謹的應用中。常見的攻擊就是
middle in the middle攻擊，它是指在A和B通信的同時，有第三方C處于信道的中間，可以完全
聽到A與B通信的消息，并可攔截，替換和添加這些消息。
1 SSL可以允許多種密鑰交換算法，而有些算法，如DH，沒有證書的概念，這樣A便無法驗證B的公鑰
和身份的真實性，從而C可以輕易的冒充，用自己的密鑰與雙方通信，從而竊聽到別人談話的內容。
而為了防止middle in the middle攻擊，應該采用有證書的密鑰交換算法。
2 有了證書以后，如果C用自己的證書替換掉原有的證書之后，A的瀏覽器會彈出一個警告框進行警告，但又有多少人會注意這個警告呢？
3 由于美國密碼出口的限制，IE，netscape等瀏覽器所支持的加密強度是很弱的，如果只采用瀏覽器自帶的加密功能的話，理論上存在被破解可能。
八 代理
下面探討一下SSL的代理是怎樣工作的(可參見[6])。這可能與你開始想的不太一樣：）
當在瀏覽器里設置了https的代理，而且在瀏覽器里輸入了https://www.example.com之后，
瀏覽器會與proxy建立tcp鏈接，然后向其發出這么一段消息：
CONNECT server.example.com:443 HTTP/1.1
Host: server.example.com:443
然后proxy會向webserver端建立tcp連接,之后，這個代理便完全成了個內容轉發裝置。瀏覽器
與web server會建立一個安全通道，因此這個安全通道是端到端的，盡管所有的信息流過了proxy,
但其內容proxy是無法解密和改動的（當然要由證書的支持，否則這個地方便是個man in the middle攻擊的好場所，見上面的討論）。
九 關于證書
注意，如果對于一般的應用，管理員只需生成“證書請求”（后綴大多為.csr），它包含你的名字和公鑰，然后把這份請求交給諸如verisign等有CA服務公司（當然，連同幾百美金），
你的證書請求經驗證后，CA用它的私鑰簽名，形成正式的證書發還給你。管理員再在web server上導入這個證書就行了。如果你不想花那筆錢，或者想了解一下原理，可以自己做CA。
從ca的角度講，你需要CA的私鑰和公鑰。從想要證書的服務器角度將，需要把服務器的證書請求交給CA.
如果你要自己做CA，別忘了客戶端需要導入CA的證書（CA的證書是自簽名的，導入它意味著你“信任”這個CA簽署的證書）。
而商業CA的一般不用，因為它們已經內置在你的瀏覽器中了。
=======
| ||||||||
一．協議的起源 隨著計算機網絡技術向整個經濟社會各層次延伸，整個社會表現對Internet、Intranet 、Extranet等使用的更大的依賴性。隨著企業間信息交互的不斷增加，任何一種網絡應用和增值服務的使用程度將取決于所使用網絡的信息安全有無保障，網絡安全已成為現代計算機網絡應用的最大障礙，也是急需解決的難題之一。 由于Web上有時要傳輸重要或敏感的數據，因此Netscape公司在推出Web瀏覽器首版的同時，提出了安全通信協議SSL(Secure Socket Layer),目前已有2.0和3.0版本。SSL采用公開密鑰技術。其目標是保證兩個應用間通信的保密性和可靠性,可在服務器和客戶機兩端同時實現支持。目前，利用公開密鑰技術的SSL協議，并已成為Internet上保密通訊的工業標準?，F行Web瀏覽器普遍將HTTP和SSL相結合，從而實現安全通信。 二．協議概述 安全套接層協議(SSL)是在Internet基礎上提供的一種保證私密性的安全協議。它能使客戶/服務器應用之間的通信不被攻擊者竊聽，并且始終對服務器進行認證，還可選擇對客戶進行認證。SSL協議要求建立在可靠的傳輸層協議(例如：TCP)之上。SSL協議的優勢在于它是與應用層協議獨立無關的。高層的應用層協議(例如：HTTP，FTP，TELNET。。。 。。。)能透明的建立于SSL協議之上。SSL協議在應用層協議通信之前就已經完成加密算法、通信密鑰的協商以及服務器認證工作。在此之后應用層協議所傳送的數據都會被加密，從而保證通信的私密性。 通過以上敘述，SSL協議提供的安全信道有以下三個特性： ? 私密性。因為在握手協議定義了會話密鑰后，所有的消息都被加密。 ? 確認性。因為盡管會話的客戶端認證是可選的，但是服務器端始終是被認證的。 ? 可靠性。因為傳送的消息包括消息完整性檢查(使用MAC)。 三．協議規范 SSL協議由SSL記錄協議和SSL握手協議兩部分組成。 1. SSL記錄協議： 在SSL協議中，所有的傳輸數據都被封裝在記錄中。記錄是由記錄頭和長度不為0的記錄數據組成的。所有的SSL通信包括握手消息、安全空白記錄和應用數據都使用SSL記錄層。SSL記錄協議包括了記錄頭和記錄數據格式的規定。 1) SSL記錄頭格式： SSL的記錄頭可以是兩個或三個字節長的編碼。SSL記錄頭的包含的信息包括：記錄頭的 長度、記錄數據的長度、記錄數據中是否有粘貼數據。其中粘貼數據是在使用塊加密算 法時，填充實際數據，使其長度恰好是塊的整數倍。最高位為1時，不含有粘貼數據，記 錄頭的長度為兩個字節，記錄數據的最大長度為32767個字節；最高位為0時，含有粘貼 數據，記錄頭的長度為三個字節，記錄數據的最大長度為16383個字節。 當數據頭長度是三個字節時，次高位有特殊的含義。次高位為1時，標識所傳輸的記錄是 普通的數據記錄；次高位為0時，標識所傳輸的記錄是安全空白記錄(被保留用于將來協 議的擴展）。 記錄頭中數據長度編碼不包括數據頭所占用的字節長度。記錄頭長度為兩個字節的記錄長度的計算公式：記錄長度＝((byte[0] ; 0x7f) <;<; 8)) | byte[1]。其中byte[0]、byte[1]分別表示傳輸的第一個、第二個字節。記錄頭長度為三個字節的記錄長度的計算公式：記錄長度＝((byte[0] ; 0x3f) <;<; 8)) | byte[1]。其中byte[0]、byte[1]的含義同上。判斷是否是安全空白記錄的計算公式：(byte[0] ; 0x40) != 0。粘貼數據的長度為傳輸的第三個字節。 2) SSL記錄數據的格式： SSL的記錄數據包含三個部分：MAC數據、實際數據和粘貼數據。 MAC數據用于數據完整性檢查。計算MAC所用的散列函數由握手協議中的CIPHER－CHOICE消息確定。若使用MD2和MD5算法，則MAC數據長度是16個字節。MAC的計算公式：MAC數據＝HASH[密鑰，實際數據，粘貼數據，序號]。當會話的客戶端發送數據時，密鑰是客戶的寫密鑰(服務器用讀密鑰來驗證MAC數據)；而當會話的客戶端接收數據時，密鑰是客戶的讀密鑰(服務器用寫密鑰來產生MAC數據)。序號是一個可以被發送和接收雙方遞增的計數器。每個通信方向都會建立一對計數器，分別被發送者和接收者擁有。計數器有32位，計數值循環使用，每發送一個記錄計數值遞增一次，序號的初始值為0。 2. SSL握手協議： SSL握手協議包含兩個階段，第一個階段用于建立私密性通信信道，第二個階段用于客戶認證。 1) 第一階段： 第一階段是通信的初始化階段，通信雙方都發出HELLO消息。當雙方都接收到HELLO消息時，就有足夠的信息確定是否需要一個新的密鑰。若不需要新的密鑰，雙方立即進入握手協議的第二階段。否則，此時服務器方的SERVER－HELLO消息將包含足夠的信息使客戶方產生一個新的密鑰。這些信息包括服務器所持有的證書、加密規約和連接標識。若密鑰產生成功，客戶方發出CLIENT－MASTER－KEY消息，否則發出錯誤消息。最終當密鑰確定以后，服務器方向客戶方發出SERVER－VERIFY消息。因為只有擁有合適的公鑰的服務器才能解開密鑰。下圖為第一階段的流程： 需要注意的一點是每一通信方向上都需要一對密鑰，所以一個連接需要四個密鑰，分別為客戶方的讀密鑰、客戶方的寫密鑰、服務器方的讀密鑰、服務器方的寫密鑰。 2) 第二階段： 第二階段的主要任務是對客戶進行認證，此時服務器已經被認證了。服務器方向客戶發出認證請求消息：REQUEST－CERTIFICATE。當客戶收到服務器方的認證請求消息，發出 自己的證書，并且監聽對方回送的認證結果。而當服務器收到客戶的認證，認證成功返回SERVER－FINISH消息，否則返回錯誤消息。到此為止，握手協議全部結束。 3. 典型的協議消息流程： 消息名 方向 內容 不需要新密鑰 CLIENT－HELLO C－>;S challenge, session_id, cipher_specs SERVER－HELLO S－>;C connection-id, session_id_hit CLIENT－FINISH C－>;S Eclient_write_key[connection-id] SERVER-VERIFY S－>;C Eserver_write_key[challenge] SERVER－FINISH S－>;C Eserver_write_key[session_id] 需要新密鑰 CLIENT－HELLO C－>;S challenge, cipher_specs SERVER－HELLO S－>;C connection-id,server_certificate,cipher_specs CLIENT－MASTER－KEY C－>;S Eserver_public_key[master_key] CLIENT－FINISH C－>;S Eclient_write_key[connection-id] SERVER－VERIFY S－>;C Eserver_write_key[challenge] SERVER－FINISH S－>;C Eserver_write_key[new_session_id] 需要客戶認證 CLIENT－HELLO C－>;S challenge, session_id, cipher_specs SERVER－HELLO S－>;C connection-id, session_id_hit CLIENT－FINISH C－>;S Eclient_write_key[connection-id] SERVER-VERIFY S－>;C Eserver_write_key[challenge] REQUEST－CERTIFICATE S－>;C Eserver_write_key[auth_type,challenge'] CLIENT－CERTIFICATE C－>;S Eclient_write_key[cert_type,client_cert,response_data] SERVER－FINISH S－>;C Eserver_write_key[session_id] 四．相關技術： 1. 加密算法和會話密鑰： 如前所述，加密算法和會話密鑰是在握手協議中協商并有CIPHER－CHOICE指定的?，F有的SSL版本中所用到的加密算法包括：RC4、RC2、IDEA和DES，而加密算法所用的密鑰由消息散列函數MD5產生。RC4、RC2是由RSA定義的，其中RC2適用于塊加密，RC4適用于流加密。下述為CIPHER－CHIOCE的可能取值和會話密鑰的計算： SSL_CK_RC4_128_WITH_MD5 SSL_CK_RC4_128_EXPORT40_WITH_MD5 SSL_CK_RC2_128_CBC_WITH_MD5 SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5 SSL_CK_IDEA_128_CBC_WITH_MD5 KEY-MATERIAL-0 = MD5[ MASTER-KEY, ";0";, CHALLENGE, CONNECTION-ID ] KEY-MATERIAL-1 = MD5[ MASTER-KEY, ";1";, CHALLENGE, CONNECTION-ID ] CLIENT-READ-KEY = KEY-MATERIAL-0[0-15] CLIENT-WRITE-KEY = KEY-MATERIAL-1[0-15] SSL_CK_DES_64_CBC_WITH_MD5 KEY-MATERIAL-0 = MD5[ MASTER-KEY, CHALLENGE, CONNECTION-ID ] CLIENT-READ-KEY = KEY-MATERIAL-0[0-7] CLIENT-WRITE-KEY = KEY-MATERIAL-0[8-15] SSL_CK_DES_192_EDE3_CBC_WITH_MD5 KEY-MATERIAL-0 = MD5[ MASTER-KEY, ";0";, CHALLENGE, CONNECTION-ID ] KEY-MATERIAL-1 = MD5[ MASTER-KEY, ";1";, CHALLENGE, CONNECTION-ID ] KEY-MATERIAL-2 = MD5[ MASTER-KEY, ";2";, CHALLENGE, CONNECTION-ID ] CLIENT-READ-KEY-0 = KEY-MATERIAL-0[0-7] CLIENT-READ-KEY-1 = KEY-MATERIAL-0[8-15] CLIENT-READ-KEY-2 = KEY-MATERIAL-1[0-7] CLIENT-WRITE-KEY-0 = KEY-MATERIAL-1[8-15] CLIENT-WRITE-KEY-1 = KEY-MATERIAL-2[0-7] CLIENT-WRITE-KEY-2 = KEY-MATERIAL-2[8-15]其中KEY-MATERIAL-0[0-15]表示KEY-MATERIAL-0中的16個字節，KEY-MATERIAL-0[0-7]表示KEY-MATERIAL-0中的頭8個字節，KEY-MATERIAL-1[8-15]表示KEY-MATERIAL-0中的第9個字節到第15個字節。其他類似形式有相同的含義。";0";、";1";表示數字0、1的ASCII碼0x30、0x31。 2. 認證算法： 認證算法采用X。509電子證書標準，通過使用RSA算法進行數字簽名來實現的。 1) 服務器的認證： 在上述的兩對密鑰中，服務器方的寫密鑰和客戶方的讀密鑰、客戶方的寫密鑰和服務器方的讀密鑰分別是一對私有、公有密鑰。對服務器進行認證時，只有用正確的服務器方寫密鑰加密CLIENT-HELLO消息形成的數字簽名才能被客戶正確的解密，從而驗證服務器的身分。 若通信雙方不需要新的密鑰，則它們各自所擁有的密鑰已經符合上述條件。若通信雙方需要新的密鑰。首先服務器方在SERVER-HELLO消息中的服務器證書中提供了服務器的公 有密鑰，服務器用其私有密鑰才能正確的解密由客戶方使用服務器的公有密鑰加密的MASTER-KEY |
轉載于:https://www.cnblogs.com/evlon/articles/360047.html
總結
- 上一篇： python 动态编译代码,Python
- 下一篇： 按文件类型获取其图标