SSL與TLS的區別

SSL(Secure Socket Layer 安全套接層)是基於HTTPS下的一個協議加密層，最初是由網景公司(Netscape)研發，後被IETF(The Internet Engineering Task Force - 互聯網工程任務組)標準化後寫入(RFCRequest For Comments 請求註釋)，RFC裏包含了不少互聯網技術的規範!

起初是由於HTTP在傳輸數據時使用的是明文(雖說POST提交的數據時放在報體裏看不到的，可是仍是能夠經過抓包工具竊取到)是不安全的，爲了解決這一隱患網景公司推出了SSL安全套接字協議層，SSL是基於HTTP之下TCP之上的一個協議層，是基於HTTP標準並對TCP傳輸數據時進行加密，因此HPPTS是HTTP+SSL/TCP的簡稱。

因爲HTTPS的推出受到了不少人的歡迎，在SSL更新到3.0時，IETF對SSL3.0進行了標準化，並添加了少數機制(可是幾乎和SSL3.0無差別)，標準化後的IETF改名爲TLS1.0(Transport Layer Security 安全傳輸層協議)，能夠說TLS就是SSL的新版本3.1，並同時發佈「RFC2246-TLS加密協議詳解」，若是想更深層次的瞭解TLS的工做原理能夠去RFC的官方網站：www.rfc-editor.org，搜索RFC2246便可找到RFC文檔!

SSL鏈接過程

SSL在通訊時會先發送一段內容：

(1)客戶端能夠支持的SSL最高版本號

(2)用於生成主祕密的32字節的隨機數

(3)肯定會話的會話ID

(4)客戶端能夠支持的密碼套件列表

密碼套件格式：每一個套件都以「SSL」開頭，緊跟着的是密鑰交換算法。用「With」這個詞把密鑰交換算法、加密算法、散列算法分開，例如：SSL_DHE_RSA_WITH_DES_CBC_SHA,表示把DHE_RSA(帶有RSA數字簽名的定義爲Diffie-HellMan)密鑰交換算法;把DES_CBC定義爲加密算法;把SHA定義爲散列算法。

(5)客戶端能夠支持的壓縮算法列表

選擇密鑰過程：

SSL客戶端(也是TCP的客戶端)在TCP鏈接創建以後，發出一個ClientHello來發起握手，這個消息裏面包含了本身可實現的算法列表和其它一些須要的消息，SSL的服務器端會迴應一個ServerHello，這裏面肯定了此次通訊所須要的算法，而後發過去本身的證書(裏面包含了身份和本身的公鑰)。Client在收到這個消息後會生成一個祕密消息，用SSL服務器的公鑰加密後傳過去，SSL服務器端用本身的私鑰解密後，會話密鑰協商成功，雙方能夠用同一份會話密鑰來通訊了。(轉自：http://blog.csdn.net/misslong/article/details/9698657)

當服務器收到客戶端發來的請求通訊消息後會做出迴應消息

迴應消息以下

(1)一個SSL版本號。取客戶端支持的最高版本號和服務端支持的最高版本號中的較低者。

(2)一個用於生成主祕密的32字節的隨機數。(客戶端一個、服務端一個)

(3)會話ID

(4)從客戶端的密碼套件列表中選擇的一個密碼套件

(5)從客戶端的壓縮方法的列表中選擇的壓縮方法

這個階段以後，客戶端服務端知道了下列內容：

(1)SSL版本

(2)密鑰交換、信息驗證和加密算法

(3)壓縮方法

(4)有關密鑰生成的兩個隨機數。

(5)頒發證書機構，過時時間!

隨機數是用來驗證通訊雙方在鏈接過程當中的準確性!

以上SSL鏈接過程轉自：http://www.cnblogs.com/zhuqil/archive/2012/10/06/2712768.html

TLS與SSL鏈接過程無任何差別

SSL與TLS二者所使用的算法是不一樣的，SSL使用的是MAC哈希算法，TLS使用的是RFC-2104定義的HMAC算法，二者差別是在填充字節與密鑰之間一個使用的是鏈接運算，一個使用的是異或運算，MAC和HMAC在取值範圍也是不一樣的，可是安全度是相同的!

SSL能夠分爲兩個協議，SSL記錄協議(SSL Record Protocol)爲TCP協議在通訊提交數據時提供數據封裝、壓縮、加密等基本操做!

SSL握手協議(SSL Handshake Protocol)它創建在SSL記錄協議之上，用於在實際的數據傳輸開始前，通信雙方進行身份認證、協商加密算法、交換加密密鑰等。

TLS與SSL的兩個協議工做方式與SSL同樣!

SSL所使用的版本爲3.0，版本號也爲3.0.x(x表明未知數由於SSL還在更新)，而TLS版本爲1.0，但版本號卻爲SSL3.1.0!

TLS增長了許多新的報警代碼，好比解密失敗(decryption_failed)、記錄溢出(record_overflow)、未知CA(unknown_ca)、拒絕訪問(access_denied)等，但同時也支持SSL協議上全部的報警代碼!

TLS和SSL不能共用，由於在認證證書時TLS指定必須與TLS之間交換證書，由於TLS與SSL所使用的加密算法是不一樣的，因此不能把TLS與SSL一併使用!

在加密數據前會額外填充一部分在SSL中，填充後的數據長度要達到密文塊長度的最小整數倍，而在TLS中，填充後的數據長度能夠是密文塊長度的任意整數倍(但填充的最大長度爲255字節)，並和公開密鑰拼接，隨後在跟着密文，這種方式能夠防止基於對報文長度進行分析的攻擊!

TLS對隨機數算法也進行了加強，TLS所使用的隨機數算法是HMAC中定義的PRF來完成的，PRF使用兩種散列算法保證其安全性。若是任一算法暴露了，只要第二種算法未暴露，則數據仍然是安全的，而SSL則使用的是MAC算法生成的隨機只是用了一種散列算法!

使用與不使用SSL/TLS加密會帶來的威脅與好處(轉自：http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html)

不使用SSL與TLS加密會帶來的威脅：

(1) 竊聽風險(eavesdropping)：第三方能夠獲知通訊內容。

(2) 篡改風險(tampering)：第三方能夠修改通訊內容。

(3) 冒充風險(pretending)：第三方能夠冒充他人身份參與通訊。

使用SS;和TLS加密所帶來的好處

(1) 全部信息都是加密傳播，第三方沒法竊聽。

(2) 具備校驗機制，一旦被篡改，通訊雙方會馬上發現。

(3) 配備身份證書，防止身份被冒充。

下面來解釋一下加密中「對稱加密」和「非對稱加密」的區別

對稱加密：

在對稱加密中，數據發送方將明文(原始數據)和加密密鑰一塊兒通過特殊加密算法處理後，使其變成複雜的加密密文發送出去。接收方收到密文後，若想解讀原文，則須要使用加密密鑰及相同算法的逆算法對密文進行解密，才能使其恢復成可讀明文。在對稱加密算法中，使用的密鑰只有一個，發收信雙方都使用這個密鑰對數據進行加密和解密，也能夠不使用算法加密!

非對稱加密：

甲方生成一對密鑰並將其中的一把做爲公用密鑰向其它方公開;獲得該公用密鑰的乙方使用該密鑰對機密信息進行加密後再發送給甲方;甲方再用本身保存的另外一把專用密鑰對加密後的信息進行解密

另外一方面，甲方可使用乙方的公鑰對機密信息進行加密後在發送給乙方;乙方在使用本身的四要對數據進行解密在驗證!

甲/乙方只能用其專用密鑰解密由其公用密鑰加密後的任何信息。 非對稱加密算法的保密性比較好，它消除了最終用戶交換密鑰的須要。

客戶端/服務器在交換密鑰時能夠從中所使用的兩把密鑰中隨便選擇一把做爲公鑰發送給目標方!

雙方優勢：

對稱加密不須要通過過多的數學計算，不會影響速率，而非對稱加密須要通過複雜的數學計算，須要CPU ALT運算單元進行大量算數運算，會提升耗電量，下降性能，影響速率，下降網頁訪問速率，不過根據如今的電腦配置這些問題都不算什麼，因此爲何在使用HTTP和HTTPS時感受沒用差異同樣!

可是服務器只承載一個HTTPS的網站還好若是承載過多的話再好的配置也會吃不消，正所謂三個臭皮匠 賽過諸葛亮，因此不是全部網站都要用HTTPS，僅個別須要提交敏感類數據時才建議使用!