1 SSL(Secure Socket Layer)是netscape公司設(shè)計(jì)的主要用于web的安全傳輸協(xié)議。這種協(xié)議在WEB上獲得了廣泛的應(yīng)用。
2 IETF(www.ietf.org?)將SSL作了標(biāo)準(zhǔn)化，即RFC2246,并將其稱為TLS（Transport Layer Security），從技術(shù)上講，TLS1.0與SSL3.0的差別非常微小。由于本文中沒(méi)有涉及兩者間的細(xì)小差別，本文中這兩個(gè)名字等價(jià)。
3 在WAP的環(huán)境下，由于手機(jī)及手持設(shè)備的處理和存儲(chǔ)能力有限，wap論壇（www.wapforum.org?）在TLS的基礎(chǔ)上做了簡(jiǎn)化，提出了WTLS協(xié)議（Wireless Transport Layer Security），以適應(yīng)無(wú)線的特殊環(huán)境。

我們從各式各樣的文章中得知，SSL可以用于保密的傳輸，這樣我們與web server之間傳輸?shù)南⒈闶?#34;安全的"。而這種"安全"究竟是怎么實(shí)現(xiàn)的，最終有能實(shí)現(xiàn)多大程度的保密？本文希望能用通俗的語(yǔ)言闡明其實(shí)現(xiàn)原理。
二 .整體結(jié)構(gòu)概覽

SSL是一個(gè)介于HTTP協(xié)議與TCP之間的一個(gè)可選層，其位置大致如下：

－－－－－－－－－
| HTTP |
－－－－－－－－－
| SSL |
－－－－－－－－－
| TCP |
－－－－－－－－－
| IP |
－－－－－－－－－

如果利用SSL協(xié)議來(lái)訪問(wèn)網(wǎng)頁(yè)，其步驟如下：
用戶：在瀏覽器的地址欄里輸入https://www.sslserver.com?
HTTP層：將用戶需求翻譯成HTTP請(qǐng)求，如
GET /index.htm HTTP/1.1
Host?http://www.sslserver.com

SSL層: 借助下層協(xié)議的的信道安全的協(xié)商出一份加密密鑰，并用此密鑰來(lái)加密HTTP請(qǐng)求。TCP層：與web server的443端口建立連接，傳遞SSL處理后的數(shù)據(jù)。接收端與此過(guò)程相反。SSL在TCP之上建立了一個(gè)加密通道，通過(guò)這一層的數(shù)據(jù)經(jīng)過(guò)了加密， 因此達(dá)到保密的效果。SSL協(xié)議分為兩部分：Handshake Protocol和Record Protocol,。其中Handshake Protocol用來(lái)協(xié)商密鑰，協(xié)議的大部分內(nèi)容就是通信雙方如何利用它來(lái)安全的協(xié)商出一份密鑰。 Record Protocol則定義了傳輸?shù)母袷?

(SSL記錄協(xié)議從高層接收到數(shù)據(jù)后要經(jīng)過(guò)分段、壓縮和加密處理，最后由傳輸層發(fā)送 出去。在SSL協(xié)議中，所有的傳輸數(shù)據(jù)都被封裝在記錄中，SSL記錄協(xié)議規(guī)定了記錄頭和記錄數(shù)據(jù)的格式。每個(gè)SSL記錄包含以下信息：1.內(nèi)容類型：指 SSL的高層協(xié)議；.2.協(xié)議版本號(hào)：指所用的SSL協(xié)議版本號(hào)，目前已有2.0和3.0版本；3.長(zhǎng)度：指記錄數(shù)據(jù)的長(zhǎng)度，記錄數(shù)據(jù)的最大長(zhǎng)度為 16383個(gè)字節(jié)；4.數(shù)據(jù)有效載荷：將數(shù)據(jù)用SSL握手階段所定義的壓縮方法和加密方法進(jìn)行處理后得到的結(jié)果；5.MAC：MAC在有效數(shù)據(jù)被加密之前 計(jì)算出來(lái)并放入SSL記錄中，用于進(jìn)行數(shù)據(jù)完整性檢查，若使用MD5算法，則MAC數(shù)據(jù)長(zhǎng)度是16個(gè)字節(jié)。SSL記錄協(xié)議采用了RFC2104中關(guān)于 HMAC結(jié)構(gòu)的修正版，在HASH函數(shù)作用之前將一個(gè)序號(hào)放入消息中，以抵抗各種形式的重傳攻擊，序號(hào)是一個(gè)32位的遞增計(jì)數(shù)器.)

三 .需要的加密方面的基礎(chǔ)知識(shí)?
了解SSL原理需要一點(diǎn)點(diǎn)加密的概念，這里把需要的概念做一下簡(jiǎn)單闡述：加密一般分為三類，對(duì)稱加密，非對(duì)稱加密及單向散列函數(shù)。

對(duì)稱加密：?又分分組密碼和序列密碼。
分組密碼是將明文按一定的位長(zhǎng)分組，明文組經(jīng)過(guò)加密運(yùn)算得到密文組，密文組經(jīng)過(guò)解密運(yùn)算（加密運(yùn)算的逆運(yùn)算），還原成明文組。
序列密碼是指利用少量的密鑰（制亂元素）通過(guò)某種復(fù)雜的運(yùn)算（密碼算法）產(chǎn)生大量的偽隨機(jī)位流，用于對(duì)明文位流的加密。
解密是指用同樣的密鑰和密碼算法及與加密相同的偽隨機(jī)位流，用以還原明文位流。

CBC(Cipher Block Chaining)模式這個(gè)詞在分組密碼中經(jīng)常會(huì)用到，它是指一個(gè)明文分組在被加密之前要與前一個(gè)的密文分組進(jìn)行異或運(yùn)算。當(dāng)加密算法用于此模式的時(shí)候除 密鑰外，還需協(xié)商一個(gè)初始化向量（IV），這個(gè)IV沒(méi)有實(shí)際意義，只是在第一次計(jì)算的時(shí)候需要用到而已。采用這種模式的話安全性會(huì)有所提高。分組密碼的典 型例子為DES,RC5,IDEA。序列密碼的典型例子為RC4。

公鑰加密：?
簡(jiǎn)單的說(shuō)就是加密密鑰與解密密鑰不同，分私鑰和公鑰。這種方法大多用于密鑰交換，RSA便是一個(gè)我們熟知的例子。
還有一個(gè)常用的稱作DH，它只能用于密鑰交換，不能用來(lái)加密。

單向散列函數(shù)：?
由于信道本身的干擾和人為的破壞，接受到的信息可能與原來(lái)發(fā)出的信息不同，一個(gè)通用的辦法就是加入校驗(yàn)碼。
單向散列函數(shù)便可用于此用途，一個(gè)典型的例子是我們熟知的MD5,它產(chǎn)生128位的摘要，在現(xiàn)實(shí)中用的更多的是安全散列算法（SHA），SHA的早期版本存在問(wèn)題，目前用的實(shí)際是SHA－1，它可以產(chǎn)生160位的摘要，因此比128位散列更能有效抵抗窮舉攻擊。

由于單向散列的算法都是公開(kāi)的，所以其它人可以先改動(dòng)原文，再生成另外一份摘要。解決這個(gè)問(wèn)題的辦法可以通過(guò)HMAC（RFC 2104）,它包含了一個(gè)密鑰，只有擁有相同密鑰的人才能鑒別這個(gè)散列。

四 .密鑰協(xié)商過(guò)程

由于非對(duì)稱加密的速度比較慢，所以它一般用于密鑰交換，雙方通過(guò)公鑰算法協(xié)商出一份密鑰，然后通過(guò)對(duì)稱加密來(lái)通信，當(dāng)然，為了保證數(shù)據(jù)的完整性，在加密前要先經(jīng)過(guò)HMAC的處理。
SSL缺省只進(jìn)行server端的認(rèn)證，客戶端的認(rèn)證是可選的。以下是其流程圖（摘自TLS協(xié)議）。

Client <=====>Server

Clienthello ——–>?
Serverhello?
Certificate?
ServerKeyExchange?
CertificateRequest?
<——– ServerhelloDone?
Certificate?
ClientKeyExchange?
CertificateVerify?
[ChangeCipherSpec]?
Finished ——–>?
[ChangeCipherSpec]?
<——– Finished?
Application Data <——-> Application Data

簡(jiǎn)單的說(shuō)便是：SSL客戶端（也是TCP的客戶端）在TCP鏈接建立之后，發(fā)出一個(gè)Clienthello來(lái)發(fā)起握手，這個(gè)消息里面包含了自己可實(shí) 現(xiàn)的算法列表和其它一些需要的消息，SSL的服務(wù)器端會(huì)回應(yīng)一個(gè)Serverhello，這里面確定了這次通信所需要的算法，然后發(fā)過(guò)去自己的證書(shū)（里面 包含了身份和自己的公鑰）。Client在收到這個(gè)消息后會(huì)生成一個(gè)秘密消息，用SSL服務(wù)器的公鑰加密后傳過(guò)去，SSL服務(wù)器端用自己的私鑰解密后，會(huì) 話密鑰協(xié)商成功，雙方可以用同一份會(huì)話密鑰來(lái)通信了。

協(xié)商分為四個(gè)階段說(shuō)明與圖示

1.初始化邏輯連接，客戶方先發(fā)出ClientHello消息，服務(wù)器方也應(yīng)返回一個(gè)ServerHello消息，這兩個(gè)消息用來(lái)協(xié)商雙方的安全能力，包括協(xié)議版本、隨機(jī)參數(shù)、會(huì)話ID、交換密鑰算法、對(duì)稱加密算法、壓縮算法等。

? ?

2.服務(wù)器方應(yīng)發(fā)送服務(wù)器證書(shū)Certificate（包含了服務(wù)器的公鑰等）和服務(wù)端會(huì)話密鑰(Serverkeyexchange)，如果服務(wù)器要求驗(yàn)證客戶方，則要發(fā)送CertificateRequest消息。最后服務(wù)器方發(fā)送 ServerHelloDone消息，表示hello階段結(jié)束，服務(wù)器等待客戶方的響應(yīng)。

3.如果服務(wù)器要求驗(yàn)證客戶方，則客戶方先發(fā)送客戶端證書(shū)Certificate消息，然后產(chǎn)生客戶端會(huì)話密鑰，并用服務(wù)器的公鑰加密，封裝在ClientKeyExchange消息中，如果客戶方發(fā)送了自己的證書(shū)，則再發(fā)送一個(gè)數(shù)字簽名CertificateVerify來(lái)對(duì)證書(shū)進(jìn)行校驗(yàn)。

? ?

4.客戶方發(fā)送一個(gè)ChangeCipherSpec消息，通知服務(wù)器以后發(fā)送的消息將采用先前協(xié)商好的安全參數(shù)加密，最后再發(fā)送一個(gè)加密后的Finished消息。服務(wù)器在收到上述兩個(gè)消息后，也發(fā)送自己的 ChangeCipherSpec消息和Finished消息。至此，握手全部完成，雙方可以開(kāi)始傳輸應(yīng)用數(shù)據(jù)。

五.密鑰協(xié)商的形象化比喻

如果上面的說(shuō)明不夠清晰，這里我們用個(gè)形象的比喻，我們假設(shè)A與B通信，A是SSL客戶端，B是SSL服務(wù)器端，加密后的消息放在方括號(hào)[]里，以突出明文消息的區(qū)別。雙方的處理動(dòng)作的說(shuō)明用圓括號(hào)（）括起。

A：我想和你安全的通話，我這里的對(duì)稱加密算法有DES,RC5,密鑰交換算法有RSA和DH，摘要算法有MD5和SHA。

B：我們用DES－RSA－SHA這對(duì)組合好了。
這是我的證書(shū)，里面有我的名字和公鑰，你拿去驗(yàn)證一下我的身份（把證書(shū)發(fā)給A）。
目前沒(méi)有別的可說(shuō)的了。

A：（查看證書(shū)上B的名字是否無(wú)誤，并通過(guò)手頭早已有的CA的證書(shū)驗(yàn)證了B的證書(shū)的真實(shí)性，如果其中一項(xiàng)有誤，發(fā)出警告并斷開(kāi)連接，這一步保證了B的公鑰的真實(shí)性）
（產(chǎn)生一份秘密消息，這份秘密消息處理后將用作加密密鑰，加密初始化向量和hmac的密鑰。將這份秘密消息-協(xié)議中稱為per_master_secret-用B的公鑰加密，封裝成稱作ClientKeyExchange的消息。由于用了B的公鑰，保證了第三方無(wú)法知道）
我生成了一份秘密消息，并用你的公鑰加密了，給你（把ClientKeyExchange發(fā)給B）
注意，下面我就要用加密的辦法給你發(fā)消息了！
（將秘密消息進(jìn)行處理，生成加密密鑰，加密初始化向量和hmac的密鑰）
[我說(shuō)完了]

B：（用自己的私鑰將ClientKeyExchange中的秘密消息解密出來(lái)，然后將秘密消息進(jìn)行處理，生成加密密鑰，加密初始化向量和hmac的密鑰，這時(shí)雙方已經(jīng)安全的協(xié)商出一套加密辦法了）
注意，我也要開(kāi)始用加密的辦法給你發(fā)消息了！
[我說(shuō)完了]

A: [我的秘密是...]

B: [其它人不會(huì)聽(tīng)到的...]
六 .加密的計(jì)算?
上一步講了密鑰的協(xié)商，但是還沒(méi)有闡明是如何利用加密密鑰，加密初始化向量和hmac的密鑰來(lái)加密消息的。其實(shí)其過(guò)程不過(guò)如此：
1 借助hmac的密鑰，對(duì)明文的消息做安全的摘要處理，然后和明文放到一起。
2 借助加密密鑰，加密初始化向量加密上面的消息。
七. 安全性?
SecurityPortal在2000年底有一份文章《The End of SSL and SSH?》激起了很多的討論，目前也有一些成熟的工具如dsniff（http://www.monkey.org/~dugsong/dsniff/）可以通過(guò)man in the middle攻擊來(lái)截獲https的消息。

從上面的原理可知，SSL的結(jié)構(gòu)是嚴(yán)謹(jǐn)?shù)?#xff0c;問(wèn)題一般出現(xiàn)在實(shí)際不嚴(yán)謹(jǐn)?shù)膽?yīng)用中。常見(jiàn)的攻擊就是middle in the middle攻擊，它是指在A和B通信的同時(shí)，有第三方C處于信道的中間，可以完全聽(tīng)到A與B通信的消息，并可攔截，替換和添加這些消息。

1 SSL可以允許多種密鑰交換算法，而有些算法，如DH，沒(méi)有證書(shū)的概念，這樣A便無(wú)法驗(yàn)證B的公鑰和身份的真實(shí)性，從而C可以輕易的冒充，用自己的密鑰與 雙方通信，從而知道到別人談話的內(nèi)容。而為了防止middle in the middle攻擊，應(yīng)該采用有證書(shū)的密鑰交換算法。
2 有了證書(shū)以后，如果C用自己的證書(shū)替換掉原有的證書(shū)之后，A的瀏覽器會(huì)彈出一個(gè)警告框進(jìn)行警告，但又有多少人會(huì)注意這個(gè)警告呢？
3 由于美國(guó)密碼出口的限制，IE，netscape等瀏覽器所支持的加密強(qiáng)度是很弱的，如果只采用瀏覽器自帶的加密功能的話，理論上存在被破解可能。
八. 代理?
下面探討一下SSL的代理是怎樣工作的(可參見(jiàn)[6])。這可能與你開(kāi)始想的不太一樣：）
當(dāng)在瀏覽器里設(shè)置了https的代理，而且在瀏覽器里輸入了https://www.example.com之后，
瀏覽器會(huì)與proxy建立tcp鏈接，然后向其發(fā)出這么一段消息：
CONNECT server.example.com:443 HTTP/1.1
Host: server.example.com:443

然后proxy會(huì)向webserver端建立tcp連接,之后，這個(gè)代理便完全成了個(gè)內(nèi)容轉(zhuǎn)發(fā)裝置。瀏覽器與web server會(huì)建立一個(gè)安全通道，因此這個(gè)安全通道是端到端的，盡管所有的信息流過(guò)了proxy,但其內(nèi)容proxy是無(wú)法解密和改動(dòng)的（當(dāng)然要由證書(shū)的 支持，否則這個(gè)地方便是個(gè)man in the middle攻擊的好場(chǎng)所，見(jiàn)上面的討論）。
九 .關(guān)于證書(shū)

注意，如果對(duì)于一般的應(yīng)用，管理員只需生成"證書(shū)請(qǐng)求"（后綴大多為.csr），它包含你的名字和公鑰，然后把這份請(qǐng)求交給諸如verisign等 有CA服務(wù)公司（當(dāng)然，連同幾百美金），你的證書(shū)請(qǐng)求經(jīng)驗(yàn)證后，CA用它的私鑰簽名，形成正式的證書(shū)發(fā)還給你。管理員再在web server上導(dǎo)入這個(gè)證書(shū)就行了。如果你不想花那筆錢，或者想了解一下原理，可以自己做CA。從ca的角度講，你需要CA的私鑰和公鑰。從想要證書(shū)的服 務(wù)器角度將，需要把服務(wù)器的證書(shū)請(qǐng)求交給CA.

如果你要自己做CA，別忘了客戶端需要導(dǎo)入CA的證書(shū)（CA的證書(shū)是自簽名的，導(dǎo)入它意味著你"信任"這個(gè)CA簽署的證書(shū)）。而商業(yè)CA的一般不用，因?yàn)樗鼈円呀?jīng)內(nèi)置在你的瀏覽器中了。
十. WTLS

在WAP的環(huán)境中，也有安全加密的需求，因此wapforum參照在WWW世界里最為流行的SSL協(xié)議設(shè)計(jì)了WTLS.從原理上說(shuō)，這份協(xié)議與 SSL是基本相同的，但在具體的地方作了許多改動(dòng)。這些改動(dòng)的大多沒(méi)有什么技術(shù)上的需要，而是由于考慮到手持設(shè)備運(yùn)算與存儲(chǔ)的局限而盡量做了簡(jiǎn)化。不過(guò)我 的感覺(jué)是這些改動(dòng)意義實(shí)在不大，其獲得的計(jì)算和存儲(chǔ)上節(jié)省出來(lái)的時(shí)間和空間并不多。在硬件速度突飛猛進(jìn)的時(shí)代，這種改動(dòng)能獲得的好處也許并不很多（一個(gè)新 的協(xié)議便需要大量新的投入，而且與原有體制并不兼容，關(guān)于這點(diǎn)有文章[7]做了精彩闡述，可參看）。

這里我簡(jiǎn)單舉一些SSL與WTLS的差別。

1 WTLS在一般udp這類不可靠信道之上工作，因此每個(gè)消息里要有序列號(hào)，協(xié)議里也要靠它來(lái)處理丟包，重復(fù)等情況。此外，拒絕服務(wù)攻擊也因此變得更加容易。
2 WTLS建立的安全連接是在wap網(wǎng)關(guān)和手持設(shè)備之間，wap網(wǎng)關(guān)和web server之間如果也要保密，便要采再用SSL，即在這種模型中無(wú)法實(shí)現(xiàn)端到端的加密。

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

3 WTLS協(xié)議里加了一種成為key_refresh的機(jī)制,當(dāng)傳遞了一定數(shù)量數(shù)據(jù)包后，雙方通過(guò)同樣的算法將自己的密鑰做一下更新。付出了很小的代價(jià)，安全性得以增強(qiáng)。

轉(zhuǎn)載于:https://www.cnblogs.com/luolizhi/p/5363015.html

總結(jié)

以上是生活随笔為你收集整理的【转】SSL/TLS/WTLS协议原理的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。