http://windows.chinaitlab.com/server/1393.html
---------------------------SSL是如何工作的?/-------------------------
聲明：由于最近對安全加密相關技術比較感興趣，所以翻譯了這篇SSL的工作原理。這是一篇比較好的文章，深入淺出的介紹了SSL -- 安全套接層的工作原理，但是由于本人的加密知識及英語水平所限，感覺很多地方翻譯的不好，但是我相信大家還是能夠看懂的。：-）還是那句老話，本文歡迎非商業(yè)性轉(zhuǎn)載，但請保持文章完整性并注明出處！
密鑰密碼系統(tǒng)介紹
這篇文章向大家闡述了Netscape公司是如何使用RSA的公用密鑰密碼系統(tǒng)來實現(xiàn)因特網(wǎng)安全的。Netscape的安全套接層的實現(xiàn)就利用了這篇文章中所討論的技術。
RSA的公用密鑰密碼系統(tǒng)廣泛地應用于計算機工業(yè)的認證和加密方面。Netscape得到RSA數(shù)據(jù)安全公司的許可可以使用公用密鑰密碼系統(tǒng)以及其它產(chǎn)品，尤其是認證方面的產(chǎn)品。
公用密鑰加密技術使用不對稱的密鑰來加密和解密，每對密鑰包含一個公鑰和一個私鑰，公鑰是公開，而且廣泛分布的，而私鑰從來不公開，只有自己知道。
用公鑰加密的數(shù)據(jù)只有私鑰才能解密，相反的，用私鑰加密的數(shù)據(jù)只有公鑰才能解密，正是這種不對稱性才使得公用密鑰密碼系統(tǒng)那么有用。
使用公用密鑰密碼系統(tǒng)進行認證
認證是一個驗證身份的過程，目的是使一個實體能夠確信對方是他所聲稱的實體。下面的例子包括Alice和Bob，并且向我們演示了如何使用公用密鑰密碼系統(tǒng)來輕易的驗證身份。下面的 {something}key 表示something 已經(jīng)用密鑰 key 加密或解密。
假設Alice要認證Bob，Bob有一個密鑰對，即一個公鑰和一個私鑰，Bob透露給Alice他的公鑰（至于他是怎么做的將在以后討論）。然后Alice產(chǎn)生一段隨機的消息，然后把它發(fā)給Bob。
A-->B random--message
Bob用自己的私鑰來加密這段消息，然后把加密后的消息返回給Alice。
B-->A {random--message}bobs--private--key
Alice接到了這段消息，然后用Bob以前發(fā)過來的公鑰來解密。她把解密后的消息和原始的消息做比較，如果匹配的話，她就知道自己正在和Bob通信。一個入侵者應該不知道Bob的私鑰，因此就不能正確的加密那段Alice要檢查的隨機消息。
但是，等一下，還有......
除非你確切的知道你在加密什么，否則用你的私鑰加密一些東西，然后發(fā)給別人永遠不是一件好事。這是因為加密后的數(shù)據(jù)可能會背叛你（記住，只有你能加密，因為只有你才有密鑰）。
所以，我們不加密Alice發(fā)送的原始消息，取而代之的是，由Bob構造一個消息摘要，然后加密它。消息摘要是從隨機消息中以某種方式提取出來的，并且具有以下特點：
摘要很難逆轉(zhuǎn)，任何假冒Bob的人不能從摘要得到原始消息
假冒者無法找到具有相同摘要的不同消息
通過使用摘要，Bob能夠保護自己。他首先計算出Alice發(fā)給他的隨機消息的摘要并加密，然后把加密后的摘要返回給Alice，Alice可以計算出相同的摘要，通過解密Bob的消息然后對比一下就可以認證Bob的身份。
近一點......
剛才描述的技術稱為數(shù)字簽名。Bob為Alice產(chǎn)生的消息簽名，這樣做其實和加密Alice產(chǎn)生的隨機消息一樣危險。因此我們的認證協(xié)議需要一次以上的變形。部分（或者全部）的數(shù)據(jù)需要由Bob產(chǎn)生。
A-->B hello,are you bob?
B-->A Alice,This Is bob{digest[Alice,This Is Bob]}bobs-private-key
當Bob使用這個協(xié)議的時候，他知道自己發(fā)給Alice的是什么消息，并且不介意簽名。他首先發(fā)送沒有加密的消息“Alice,This Is Bob。”然后發(fā)送加密的摘要。Alice能夠輕易的判斷Bob是Bob，并且Bob沒有簽任何他不愿意簽的東西。
分發(fā)公鑰
Bob如何以一種可信賴的方式分發(fā)他的公鑰呢？我們假設認證協(xié)議是這個樣子的：
A-->B hello
B-->A Hi, I'm Bob, bobs-public-key
A-->B prove it
B-->A Alice, This Is bob{ digest[Alice, This Is Bob] } bobs-private-key
如果使用這個協(xié)議的話，任何人都可以是Bob。你需要的只是一個公鑰和私鑰，你跟Alice慌稱你是Bob，接著你用自己的公鑰代替Bob的公鑰，然后你通過用你的私鑰加密的東西來證明，這樣Alice就不能分辨出你不是Bob。
為了解決這個問題，標準化組織發(fā)明了一個叫做證書的東西，一個證書包括下面的一些內(nèi)容：
證書發(fā)行者的名字
證書發(fā)送給的團體
主題的公鑰
一些時間戳
證書是由證書發(fā)行者的私鑰簽名的，每個人都知道證書發(fā)行者的公鑰（即證書發(fā)行者有一個證書，等等）。證書是一種把公鑰綁定到名字的標準方式。
通過使用證書這種技術，每個人都可以通過檢查Bob的證書來判斷Bob是不是偽造的。假設Bob嚴格的控制著他的私鑰，并且的確是Bob得到了他的證書，那么一切都好。下面是補償協(xié)議：
A-->B hello
B-->A Hi, I'm Bob, bobs-certificate
A-->B prove it
B-->A Alice, This Is bob{ digest[Alice, This Is Bob] } bobs-private-key
當Alice收到Bob的第一條消息，她可以檢查證書，核實簽名（如上，使用摘要和公鑰加密），然后，核實主題（Bob的名字）來判斷那是不是真的Bob。這樣她就相信公鑰是Bob的公鑰，然后要求Bob證明他的身份。Bob則重新進行一次上面的相同過程，計算消息的摘要，簽名之后發(fā)給Alice，Alice可以用從證書得到的公鑰檢查Bob的消息摘要，從而判斷Bob的身份。
一個壞家伙 - 我們不妨叫他Mallet - 可以做下面的事情：
A-->M hello
M-->A Hi, I'm Bob, bobs-certificate
A-->M prove it
M-->A ????
但是Mallet在最后的消息中不能滿足Alice。Mallet沒有Bob的私鑰，所以他無法構造一條使Alice相信來自Bob的消息。
交換秘密
一旦Alice認證了Bob，她就可以做另外一件事-她能發(fā)給一條只有Bob才能解碼的消息：
A-->B {secret}bobs-public-key
發(fā)現(xiàn)這個秘密的唯一方法就是用Bob的私鑰來解密上面的消息，交換秘密是公用密鑰密碼系統(tǒng)的另一種強大的用法。即使Alice和Bob之間的通信被監(jiān)視，除了Bob，也沒有人能夠得到秘密。
這項技術加強了因特網(wǎng)的安全性，它把這個密碼當作另一個密鑰，但是這時它是對稱性密碼系統(tǒng)算法的密鑰（如DES，RC4，IDEA）。Alice知道這個秘密，因為這是自己在發(fā)送給Bob之前產(chǎn)生的。Bob知道這個秘密，因為Bob有私鑰，能夠解密Alice的消息。因為他們都知道這個秘密，所以他們就可以初始化一個對稱的密碼算法然后開始傳輸用它加密的消息。下面是訂正的協(xié)議：
A-->B hello
B-->A Hi, I'm Bob, bobs-certificate
A-->B prove it
B-->A Alice, This Is bob{ digest[Alice, This Is Bob] } bobs-private-key
A-->B ok bob, here is a secret {secret} bobs-public-key
B-->A {some message}secret-key
secret-key 的計算取決于協(xié)議的定義，但是它可以簡化成一個 secret 的副本。
你說什么？
Mallet的袋子里有很多詭計。雖然Mallet不能發(fā)現(xiàn)Alice和Bob交換的秘密，但是他可以干預并且破壞他們的對話。舉例來說，如果Mallet位于Alice和Bob，他可以選擇讓大多數(shù)的消息返回以及向前繼續(xù)傳輸沒有改變，但是破壞了特定位的消息（這對他來說很容易，因為他知道Alice和Bob之間通信的協(xié)議）。
A-->M hello
M-->B hello
B-->M Hi, I'm Bob, bobs-certificate
M-->A Hi, I'm Bob, bobs-certificate
A-->M prove it
M-->B prove it
B-->M Alice, This Is bob{ digest[Alice, This Is Bob] } bobs-private-key
M-->A Alice, This Is bob{ digest[Alice, This Is Bob] } bobs-private-key
A-->M ok bob, here is a secret {secret} bobs-public-key
M-->B ok bob, here is a secret {secret} bobs-public-key
B-->M {some message}secret-key
M-->A Garble[ {some message}secret-key ]
Mallet一直讓數(shù)據(jù)沒有改變的通過，直到Alice和Bob分享一個秘密。然后Mallet通過改變Bob發(fā)送給Alice的消息來進入這個方式中。這時候Alice是相信Bob的，因此她就可能相信這個改變的消息，然后按照它來做。注意Mallet并不知道這個秘密-他能做的所有事就是破壞用這個秘密的密鑰加密的數(shù)據(jù)。他可能不能利用這個協(xié)議制造出一條有效的消息，但是下一次，他可能幸運一點。
為了防止這種破壞，Alice和Bob在他們的協(xié)議中引入了一種消息認證碼（MAC）。MAC是根據(jù)秘密的密鑰和傳輸?shù)臄?shù)據(jù)計算出來的，上面描述的摘要算法的屬性正好可以用于構造抵抗Mallet的MAC功能。
MAC := Digest[ some message, secret ]
因為Mallet不知道這個秘密的密鑰，所以他無法計算出這個摘要的正確數(shù)值。即使Mallet隨機的改變消息，如果摘要數(shù)據(jù)很大的話，他成功的可能性也很小。舉例來說，通過使用MD5（RSA公司發(fā)明的一種很好的密碼摘要算法），Alice和Bob能和他們的消息一起發(fā)送128位的MAC值。Mallet猜中這個正確的MAC值的幾率是18,446,744,073,709,551,616 分之1-也就是從來也不會猜出來。
下面是樣本協(xié)議，又訂正了一次：
A-->B hello
B-->A Hi, I'm Bob, bobs-certificate
A-->B prove it
B-->A {digest[Alice, This Is Bob] } bobs-private-key
ok bob, here is a secret {sec
http://ciw.chinaitlab.com/tech/7336.html
-------SSL/TLS/WTLS原理---------------------
在CIW課程中雖然沒有對SSL做深入的討論，但是SSL已成為應用最廣泛的互連網(wǎng)安全協(xié)議了，有必要對其深刻理解
一 前言
首先要澄清一下名字的混淆：
1 SSL(Secure Socket Layer)是netscape公司設計的主要用于web的安全傳輸協(xié)議。這種協(xié)議在WEB上獲得了廣泛的應用。
2 IETF(www.ietf.org)將SSL作了標準化，即RFC2246,并將其稱為TLS（Transport Layer Security），從技術上講，TLS1.0與SSL3.0的差別非常微小。由于本文中沒有涉及兩者間的細小差別，本文中這兩個名字等價。
3 在WAP的環(huán)境下，由于手機及手持設備的處理和存儲能力有限，wap論壇（www.wapforum.org）在TLS的基礎上做了...S協(xié)議（Wireless Transport Layer Security），以適應無線的特殊環(huán)境。
我們從各式各樣的文章中得知，SSL可以用于保密的傳輸，這樣我們與web server之間傳輸?shù)南⒈闶?#8220;安全的”。
而這種“安全”究竟是怎么實現(xiàn)的，最終有能實現(xiàn)多大程度的保密？本文希望能用通俗的語言闡明其實現(xiàn)原理。
二 整體結(jié)構概覽
SSL是一個介于HTTP協(xié)議與TCP之間的一個可選層，其位置大致如下：
－－－－－－－－－
| HTTP |
?。?
| SSL |
?。?
| TCP |
－－－－－－－－－
| IP |
?。?
如果利用SSL協(xié)議來訪問網(wǎng)頁，其步驟如下：
用戶：在瀏覽器的地址欄里輸入https://www.sslserver.com
HTTP層：將用戶需求翻譯成HTTP請求，如
GET /index.htm HTTP/1.1
Host http://www.sslserver.com
SSL層: 借助下層協(xié)議的的信道安全的協(xié)商出一份加密密鑰，并用此密鑰來加密HTTP請求。
TCP層：與web server的443端口建立連接，傳遞SSL處理后的數(shù)據(jù)。
接收端與此過程相反。
SSL在TCP之上建立了一個加密通道，通過這一層的數(shù)據(jù)經(jīng)過了加密，因此達到保密的效果。
SSL協(xié)議分為兩部分：Handshake Protocol和Record Protocol,。其中Handshake Protocol用來協(xié)商密鑰，協(xié)議的大部分內(nèi)容就是通信雙方如何利用它來安全的協(xié)商出一份密鑰。 Record Protocol則定義了傳輸?shù)母袷健?
三 需要的加密方面的基礎知識
了解SSL原理需要一點點加密的概念，這里把需要的概念做一下簡單闡述：
加密一般分為三類，對稱加密，非對稱加密及單向散列函數(shù)。
對稱加密：又分分組密碼和序列密碼。
分組密碼是將明文按一定的位長分組，明文組經(jīng)過加密運算得到密文組，密文組經(jīng)過解密運算
?。用苓\算的逆運算），還原成明文組。
序列密碼是指利用少量的密鑰（制亂元素）通過某種復雜的運算（密碼算法）產(chǎn)生大量的偽隨機位流，用于對明文位流的加密。
解密是指用同樣的密鑰和密碼算法及與加密相同的偽隨機位流，用以還原明文位流。
CBC(Cipher Block Chaining)模式這個詞在分組密碼中經(jīng)常會用到，它是指一個明文分組在被加密之前要與前一個的密文分組進行異或運算。當加密算法用于此模式的時候除密鑰外，還需協(xié)商一個初始化向量（IV），這個IV沒有實際意義，只是在第一次計算的時候需要用到而已。采用這種模式的話安全性會有所提高。
分組密碼的典型例子為DES,RC5,IDEA。
序列密碼的典型例子為RC4。
公鑰加密：
簡單的說就是加密密鑰與解密密鑰不同，分私鑰和公鑰。這種方法大多用于密鑰交換，RSA便是一個我們熟知的例子。
還有一個常用的稱作DH，它只能用于密鑰交換，不能用來加密。
單向散列函數(shù)：
由于信道本身的干擾和人為的破壞，接受到的信息可能與原來發(fā)出的信息不同，一個通用的辦法就是加入校驗碼。
單向散列函數(shù)便可用于此用途，一個典型的例子是我們熟知的MD5,它產(chǎn)生128位的摘要，在現(xiàn)實中用的更多的是安全散列算法（SHA），SHA的早期版本存在問題，目前用的實際是SHA－1，它可以產(chǎn)生160位的摘要，因此比128位散列更能有效抵抗窮舉攻擊。
由于單向散列的算法都是公開的，所以其它人可以先改動原文，再生成另外一份摘要。解決這個問題的辦法可以通過HMAC（RFC 2104）,它包含了一個密鑰，只有擁有相同密鑰的人才能鑒別這個散列。
四 密鑰協(xié)商過程
由于對稱加密的速度比較慢，所以它一般用于密鑰交換，雙方通過公鑰算法協(xié)商出一份密鑰，然后通過對稱加密來通信，當然，為了保證數(shù)據(jù)的完整性，在加密前要先經(jīng)過HMAC的處理。
SSL缺省只進行server端的認證，客戶端的認證是可選的。以下是其流程圖（摘自TLS協(xié)議）。
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鏈接建立之后，發(fā)出一個Clienth*llo來發(fā)起握手，這個消息里面包含了自己可實現(xiàn)的算法列表和其它一些需要的消息，SSL的服務器端會回應一個Serverh*llo，這里面確定了這次通信所需要的算法，然后發(fā)過去自己的證書（里面包含了身份和自己的公鑰）。Client在收到這個消息后會生成一個秘密消息，用SSL服務器的公鑰加密后傳過去，SSL服務器端用自己的私鑰解密后，會話密鑰協(xié)商成功，雙方可以用同一份會話密鑰來通信了。
五 密鑰協(xié)商的形象化比喻
如果上面的說明不夠清晰，這里我們用個形象的比喻，我們假設A與B通信，A是SSL客戶端，B是SSL服務器端，加密后的消息放在方括號[]里，以突出明文消息的區(qū)別。雙方的處理動作的說明用圓括號（）括起。
A：我想和你安全的通話，我這里的對稱加密算法有DES,RC5,密鑰交換算法有RSA和DH，摘要算法有MD5和SHA。
B：我們用DES－RSA－SHA這對組合好了。
這是我的證書，里面有我的名字和公鑰，你拿去驗證一下我的身份（把證書發(fā)給A）。
目前沒有別的可說的了。
A：（查看證書上B的名字是否無誤，并通過手頭早已有的CA的證書驗證了B的證書的真實性，如果其中一項有誤，發(fā)出警告并斷開連接，這一步保證了B的公鑰的真實性）
?。óa(chǎn)生一份秘密消息，這份秘密消息處理后將用作加密密鑰，加密初始化向量和hmac的密鑰。將這份秘密消息-協(xié)議中稱為per_master_secret-用B的公鑰加密，封裝成稱作ClientKeyExchange的消息。由于用了B的公鑰，保證了第三方無法竊聽）
我生成了一份秘密消息，并用你的公鑰加密了，給你（把ClientKeyExchange發(fā)給B）
注意，下面我就要用加密的辦法給你發(fā)消息了！
?。▽⒚孛芟⑦M行處理，生成加密密鑰，加密初始化向量和hmac的密鑰）
[我說完了]
B：（用自己的私鑰將ClientKeyExchange中的秘密消息解密出來，然后將秘密消息進行處理，生成加密密鑰，加密初始化向量和hmac的密鑰，這時雙方已經(jīng)安全的協(xié)商出一套加密辦法了）
注意，我也要開始用加密的辦法給你發(fā)消息了！
[我說完了]
A: [我的秘密是...]
B: [其它人不會聽到的...]
六 加密的計算
上一步講了密鑰的協(xié)商，但是還沒有闡明是如何利用加密密鑰，加密初始化向量和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的結(jié)構是嚴謹?shù)?，問題一般出現(xiàn)在實際不嚴謹?shù)膽弥?。常見的攻擊就?
middle in the middle攻擊，它是指在A和B通信的同時，有第三方C處于信道的中間，可以完全
聽到A與B通信的消息，并可攔截，替換和添加這些消息。
1 SSL可以允許多種密鑰交換算法，而有些算法，如DH，沒有證書的概念，這樣A便無法驗證B的公鑰
和身份的真實性，從而C可以輕易的冒充，用自己的密鑰與雙方通信，從而竊聽到別人談話的內(nèi)容。
而為了防止middle in the middle攻擊，應該采用有證書的密鑰交換算法。
2 有了證書以后，如果C用自己的證書替換掉原有的證書之后，A的瀏覽器會彈出一個警告框進行警告，但又有多少人會注意這個警告呢？
3 由于美國密碼出口的限制，IE，netscape等瀏覽器所支持的加密強度是很弱的，如果只采用瀏覽器自帶的加密功能的話，理論上存在被破解可能。
八 代理
下面探討一下SSL的代理是怎樣工作的(可參見[6])。這可能與你開始想的不太一樣：）
當在瀏覽器里設置了https的代理，而且在瀏覽器里輸入了https://www.example.com之后，
瀏覽器會與proxy建立tcp鏈接，然后向其發(fā)出
聯(lián)系客服
