【轉】安全傳輸協議SSL和TLS及WTLS的原理

標籤：

一、首先要澄清一下名字的混淆

1.SSL(Secure Socket Layer)是Netscape公司設計的主要用於WEB的安全傳輸協議。這種協議在WEB上獲得了廣泛的應用。

2.IETF將SSL作了標準化，即RFC2246，並將其稱為TLS（Transport Layer Security），從技術上講，TLS1.0與SSL3.0的差別非常微小。由於本文中沒有涉及兩者間的細小差別，本文中這兩個名字等價。

3.在WAP的環境下，由於手機及手持功能的處理和儲存能力有限，Wap論壇在TLS的基礎上做了簡化，提出了WTLS協議（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可以通過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的代理是怎樣工作的。當在瀏覽器裡設定了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的一般不用，因為它們已經內建在你的瀏覽器中了。

十、Wtls

在WAP的環境中，也有安全加密的需求，因此wapforum參照在WWW世界裡最為流行的SSL協議設計了WTLS.從原理上說，這份協議與SSL是基本相同的，但在具體的地方作了許多改動。這些改動的大多沒有什麼技術上的需要，而是由於考慮到手持功能運算與儲存的局限而盡量做了簡化。不過我的感覺是這些改動意義實在不大，其獲得的計算和儲存上節省出來的時間和空間並不多。在硬體速度突飛猛進的時代，這種改動能獲得的好處也許並不很多（一個新的協議便需要大量新的投入，而且與原有體制並不相容）。

這裡我簡單舉一些SSL與WTLS的差別。

1.WTLS在一般udp這類不可靠通道之上工作，因此每個訊息裡要有序號，協議裡也要靠它來處理丟包，重複等情況。此外，拒絕服務的攻擊也因此變得更加容易。

2.WTLS建立的安全串連是在wap網關和手持功能之間，wap網關和web server之間如果也要保密，便要采再用SSL，即在這種模型中無法實現端到端的加密。

---------- ------------- --------- | Mobile |----------->| WAP |---------->| WEB | | Device |<-----------| Gateway |<----------|Server | | | WTLS | | SSL | | ---------- ------------- ---------

3.WTLS協議裡加了一種成為key_refresh的機制，當傳遞了一定數量資料包後，雙方通過同樣的演算法將自己的密鑰做一下更新。付出了很小的代價，安全性得以增強。

【轉】安全傳輸協議SSL和TLS及WTLS的原理