SSL/TLS/WTLS

轉載來自http://blog.csdn.net/fw0124/article/details/8470940

一 前言

首先要澄清一下名字的混淆：
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的基礎上作了簡化，提出了WTLS協議（Wireless Transport Layer Security），以適應無線的特殊環境。

從SSL協議所提供的服務及其工做流程能夠看出，SSL協議運行的基礎是商家對消費者信息保密的承諾，這就有利於商家而不利於消費者。在電子商務初級階段，因爲運做電子商務的企業大可能是信譽較高的大公司，所以這問題尚未充分暴露出來。但隨着電子商務的發展，各中小型公司也參與進來，這樣在電子支付過程當中的單一認證問題就愈來愈突出。雖然在SSL3.0中經過數字簽名和數字證書可實現瀏覽器和Web服務器雙方的身份驗證，可是SSL協議仍存在一些問題，好比，只能提供交易中客戶與服務器間的雙方認證，在涉及多方的電子交易中，SSL協議並不能協調各方間的安全傳輸和信任關係。在這種狀況下，Visa和MasterCard兩大信用卡公組織制定了SET協議，爲網上信用卡支付提供了全球性的標準。

咱們從各式各樣的文章中得知，SSL能夠用於保密的傳輸，這樣咱們與web server之間傳輸的消息即是「安全的」。而這種「安全」到底是怎麼實現的，最終有能實現多大程度的保密？本文但願能用通俗的語言闡明其實現原理。

二 總體結構概覽
SSL是一個介於HTTP協議與TCP之間的一個可選層，其位置大體以下：
－－－－－－－－－
| HTTP |
－－－－－－－－－
| SSL |
－－－－－－－－－
| TCP |
－－－－－－－－－
| IP |
－－－－－－－－－

若是利用SSL協議來訪問網頁，其步驟以下：
用戶：在瀏覽器的地址欄裏輸入https://www.sslserver.com
HTTP層：將用戶需求翻譯成HTTP請求，如
GET /index.htm HTTP/1.1
Host www.sslserver.com

SSL層: 藉助下層協議的的信道安全的協商出一份加密密鑰，並用此密鑰來加密HTTP請求。
TCP層：與web server的443端口創建鏈接，傳遞SSL處理後的數據。
接收端與此過程相反。

SSL在TCP之上創建了一個加密通道，經過這一層的數據通過了加密，所以達到保密的效果。

SSL協議分爲兩部分：Handshake Protocol和Record Protocol,
其較低的SSL記錄層協議位於傳輸協議TCP/IP之上,定義了傳輸的格式。SSL記錄協議用來對其上層的協議進行封裝。
握手協議就在這些被封裝的上層協議之中，它容許客戶端與服務器彼此認證對方；而且在應用協議發出或收到第一個數據以前協商加密算法和加密密鑰。


三 須要的加密方面的基礎知識
瞭解SSL原理須要一點點加密的概念，這裏把須要的概念作一下簡單闡述：

加密通常分爲三類，對稱加密，非對稱加密及單向散列函數。
對稱加密：又分分組密碼和序列密碼。
分組密碼，也叫塊加密(block cyphers)，一次加密明文中的一個塊。是將明文按必定的位長分組，明文組通過加密運算獲得密文組，密文組通過解密運算（加密運算的逆運算），還原成明文組。
序列密碼，也叫流加密(stream cyphers)，一次加密明文中的一個位。是指利用少許的密鑰（制亂元素）經過某種複雜的運算（密碼算法）產生大量的僞隨機位流，用於對明文位流的加密。
解密是指用一樣的密鑰和密碼算法及與加密相同的僞隨機位流，用以還原明文位流。

在塊加密算法中，有ECB,CBC,CFB,OFB這幾種算法模式。http://blog.csdn.net/fw0124/article/details/8472560

分組密碼的典型例子爲DES(64位數據，56位密鑰+8位奇偶校驗),AES(128位數據，128,192,256位可變密鑰),IDEA(64位數據，128位密鑰)，
RC5。
RC5是一個RC5-w/r/b家族系列，
w = word size in bits (16/32/64) ，1word=2bits
r = number of rounds (0..255)
b = number of bytes in key (0..255)
建議版本爲RC5-32/12/16, so encrypts 64-bit data blocks using 12 rounds with 16 bytes (128-bit) secret key

序列密碼的典型例子爲RC4。

公鑰加密：
簡單的說就是加密密鑰與解密密鑰不一樣，分私鑰和公鑰。這種方法大多用於密鑰交換，RSA即是一個咱們熟知的例子。
還有一個經常使用的稱做DH(http://blog.csdn.net/fw0124/article/details/8462373)，它只能用於密鑰交換，不能用來加密。

單向散列函數：
因爲信道自己的干擾和人爲的破壞，接受到的信息可能與原來發出的信息不一樣，一個通用的辦法就是加入校驗碼。
單向散列函數即可用於此用途，一個典型的例子是咱們熟知的MD5,它產生128位的摘要，在現實中用的更多的是安全散列算法（SHA），SHA的早期版本存在問題，目前用的實際是SHA－1，它能夠產生160位的摘要，所以比128位散列更能有效抵抗窮舉攻擊。
因爲單向散列的算法都是公開的，因此其它人能夠先改動原文，再生成另一份摘要。解決這個問題的辦法能夠經過HMAC（RFC 2104）,它包含了一個密鑰，只有擁有相同密鑰的人才能鑑別這個散列。

四 密鑰協商過程
因爲非對稱加密的速度比較慢，因此它通常用於密鑰交換，雙方經過公鑰算法協商出一份密鑰，而後經過對稱加密來通訊，固然，爲了保證數據的完整性，在加密前要先通過HMAC的處理。

SSL缺省只進行server端的認證，客戶端的認證是可選的。如下是其流程圖（摘自TLS協議）。

Client	Server
Client Hello
	Server Hello certificate server_key_exchange certificate_request server_hello_done
certificate client_key_exchange certifiate_verify change_cypher_spec finished
	change_cypher_spec finished

① 客戶端的瀏覽器向服務器傳送客戶端SSL協議的版本號、加密算法的種類、產生的隨機數，以及其餘服務器和客戶端之間通訊所須要的各類信息。
SSL支持如下一些密鑰交換方法：
+RSA，要求服務器提供一個RSA證書
+DH(Diffie-Hellman)，要求服務器的證書中包含了由CA簽名的DH公開參數。客戶或者在證書中提供DH公開參數，或者在密鑰交換消息中提供此參數

② Server回答ServerHello。服務器向客戶端傳送SSL協議的版本號、加密算法的種類、隨機數及其餘相關信息，
同時，服務器還將向客戶端傳送本身的證書和密鑰交換信息(可選的，有些狀況下能夠不須要。只有當服務器的證書沒有包含必需的數據的時候才發送此消息)。

③ 客戶利用服務器傳過來的信息驗證服務器的合法性。服務器的合法性包括：
證書是否過時，
發行服務器證書的CA是否可靠，
發行者證書的公鑰可否正確解開服務器證書的「發行者的數字簽名」，
服務器證書上的域名是否和服務器的實際域名相匹配。
若是合法性驗證沒有經過，則通訊將斷開；若是合法性驗證經過，則將繼續進行第④步。

④ 客戶端隨機產生一個用於後面通訊的「對稱密碼」(pre_master_secret)，而後用服務器的公鑰（從步驟②中服務器的證書中得到）對其加密，再將加密後的「預主密碼」傳給服務器。

⑤ 若是服務器要求客戶的身份認證（在握手過程當中爲可選），用戶則能夠創建一個隨機數，而後對其進行數字簽名，將這個含有簽名的隨機數和客戶本身的證書，以及加密過的「預主密碼」一塊兒傳給服務器。
若客戶沒有證書，則發送一個no_certificate警告，這種狀況用於單向認證，即客戶端不裝有證書；

⑥ 若是服務器要求客戶的身份認證，服務器則必須檢驗客戶證書和簽名隨機數的合法性。具體的合法性驗證包括：
客戶的證書使用日期是否有效，
爲客戶提供證書的CA是否可靠，
發行CA的公鑰可否正確解開客戶證書的發行CA的數字簽名，
檢查客戶的證書是否在證書撤銷列表（CRL）中。
檢驗若是沒有經過，則通訊馬上中斷；
若是驗證經過，則服務器將用本身的私鑰解開加密的「預主密碼」，
而後執行一系列步驟來產生主通訊密碼（客戶端也將經過一樣的方法產生相同的主通訊密碼）。

⑦ 服務器和客戶端用相同的主密碼，即「通話密碼」，一個對稱密鑰用於SSL協議的安全數據通訊的加/解密通訊。
同時，在SSL通訊過程當中還要完成數據通訊的完整性，以防止數據通訊中的任何變化。

⑧ 客戶端向服務器端發出信息，指明後面的數據通訊將使用步驟⑦中的主密碼爲對稱密鑰，同時通知服務器客戶端的握手過程結束。

⑨ 服務器向客戶端發出信息，指明後面的數據通訊將使用步驟⑦中的主密碼爲對稱密鑰，同時通知客戶端服務器端的握手過程結束。

⑩ SSL的握手部分結束，SSL安全通道的數據通訊開始，客戶和服務器開始
使用相同的對稱密鑰進行數據通訊，同時進行通訊完整性的檢驗。

簡單的說即是：
SSL客戶端（也是TCP的客戶端）在TCP連接創建以後，
發出一個ClientHello來發起握手，
這個消息裏面包含了本身可實現的算法列表和其它一些須要的消息，
SSL的服務器端會迴應一個ServerHello，這裏面肯定了此次通訊所須要的算法，
而後發過去本身的證書（裏面包含了身份和本身的公鑰）。
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 藉助加密密鑰，加密初始化向量加密上面的消息。

七 安全性
1）鑑別機制。
公開密鑰技術和數字證書能夠實現客戶端和服務器端的身份鑑別。ClientHello和ServerHello發過去本身的證書(裏面包含了身份和本身的公鑰)。
2）加密機制。
混合密碼體制的使用提供了會話和數據傳輸的加密性保護。雙方使用非對稱密碼體制協商出本次將要使用的會話密鑰，並選擇一種對稱加密算法。
3）完整性機制。
定義了共享的、能夠用來造成報文鑑別碼MAC的密鑰。數據進行分片壓縮後，使用單向散列函數產生一個MAC，加密後置於數據包的後部，而且再一次和數據一塊兒被加密,而後加上SSL首部進行網絡傳輸。
這樣，若是數據被修改，其散列值就沒法和原來的MAC相匹配，從而保證了數據的完整性。 
4）抗重放攻擊。
SSL使用序列號來保護通訊方免受報文重放攻擊。這個序列號被加密後做爲數據包的負載。
在整個SSL握手中，都有一個惟一的隨機數來標記這個SSL握手，這樣重放便無機可乘。

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的通常不用，由於它們已經內置在你的瀏覽器中了。

十 wtls
在WAP的環境中，也有安全加密的需求，所以wapforum參照在WWW世界裏最爲流行的SSL協議設計了WTLS.從原理上說，這份協議與SSL是基本相同的，但在具體的地方做了許多改動。這些改動的大多沒有什麼技術上的須要，而是因爲考慮到手持設備運算與存儲的侷限而儘可能作了簡化。不過個人感受是這些改動意義實在不大，其得到的
計算和存儲上節省出來的時間和空間並很少。在硬件速度日新月異的時代，這種改動能得到的好處也許並不不少（一個新的協議便須要大量新的投入，並且與原有體制並不兼容，關於這點有文章[7]作了精彩闡述，可參看）。

這裏我簡單舉一些SSL與WTLS的差異。

1 WTLS在通常udp這類不可靠信道之上工做，所以每一個消息裏要有序列號，協議裏也要靠它來處理丟包，重複等狀況。
此外，拒絕服務攻擊也所以變得更加容易。
2 WTLS創建的安全鏈接是在wap網關和手持設備之間，wap網關和web server之間若是也要保密，便要採再用SSL，即在這種模型中沒法實現端到端的加密。

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

3 WTLS協議里加了一種成爲key_refresh的機制,當傳遞了必定數量數據包後，雙方經過一樣的算法將本身的密鑰作一下更新。付出了很小的代價，安全性得以加強。