實(shí)現(xiàn)HTTPS系列第四彈之【TLS，SSL概念理解】-創(chuàng)新互聯(lián)

博文說明【前言】：

成都創(chuàng)新互聯(lián)IDC提供業(yè)務(wù):內(nèi)江機(jī)房主機(jī)托管,成都服務(wù)器租用,內(nèi)江機(jī)房主機(jī)托管,重慶服務(wù)器租用等四川省內(nèi)主機(jī)托管與主機(jī)租用業(yè)務(wù);數(shù)據(jù)中心含:雙線機(jī)房,BGP機(jī)房,電信機(jī)房,移動機(jī)房,聯(lián)通機(jī)房。

  本文將通過個人口吻介紹TLS ，SSL等相關(guān)知識，在目前時間點(diǎn)【2017年5月21號】下，所掌握的技術(shù)水平有限，可能會存在不少知識理解不夠深入或全面，望大家指出問題共同交流，在后續(xù)工作及學(xué)習(xí)中如發(fā)現(xiàn)本文內(nèi)容與實(shí)際情況有所偏差，將會完善該博文內(nèi)容。

1、第一彈：實(shí)現(xiàn)HTTPS系列第一彈之【http,https,www,web等概念簡介】

博文鏈接：http://watchmen.blog.51cto.com/6091957/1922919

2、第二彈：實(shí)現(xiàn)HTTPS系列第二彈之【非對稱加密，公鑰私鑰，數(shù)字簽名，OpenSSL及HTTPS等概念簡介】

博文鏈接：http://watchmen.blog.51cto.com/6091957/1923426

3、第三彈：實(shí)現(xiàn)HTTPS系列第三彈之【數(shù)字簽名，數(shù)字證書，CA認(rèn)證等概念理解】

博文鏈接：http://watchmen.blog.51cto.com/6091957/1924747

本文參考文獻(xiàn)引用鏈接及其他資料：

1、https://www.openssl.org/docs/

2、https://www.feistyduck.com/?【經(jīng)典，強(qiáng)烈推薦，TLS/SSL技術(shù)文檔網(wǎng)站】

3、https://www.ssllabs.com 【經(jīng)典，強(qiáng)烈推薦,在線檢測網(wǎng)站SSL/TLS安全強(qiáng)度】

該網(wǎng)站屬于qualys公司，qualiy's ssl labs，這是一家云安全公司，網(wǎng)址：www.qualys.com

4、推薦圖書：《Bulletproof SSL and TLS》-作者Ivan Ristic，資料我已上傳，可從站內(nèi)搜索下載

下載路徑：http://down.51cto.com/data/2306452

5、http://www.techug.com/post/https-ssl-tls.html【必讀】

6、http://kb.cnblogs.com/page/197396/

7、http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html【必讀】

8、https://technet.microsoft.com/en-us/library/cc784450(v=ws.10).aspx

正文：

  首先，HTTP 是一個網(wǎng)絡(luò)協(xié)議，是專門用來傳輸 Web 內(nèi)容。關(guān)于這個協(xié)議，就算你不了解，至少也聽說過，比如你訪問百度的主頁，瀏覽器地址欄會出現(xiàn)如下的網(wǎng)址http://www.baidu.com/，

這就是指通過HTTP 協(xié)議訪問該百度的web服務(wù)器的內(nèi)容。在Internet發(fā)展前期，大部分網(wǎng)站都是通過 HTTP 協(xié)議來傳輸 Web 頁面以及 Web 頁面上包含的各種東西（圖片、CSS 樣式、JS 腳本等）。這部分內(nèi)容可以查看的我的第一彈博文簡單了解，好，基礎(chǔ)知識介紹完畢，故事開始。

一：SSL/TLS是什么？:

SSL（Security Socket Layer，安全套接層），它是在上世紀(jì)90年代中期，由網(wǎng)景公司設(shè)計的。（網(wǎng)景公司不光發(fā)明了 SSL，還發(fā)明了很多 Web 的基礎(chǔ)設(shè)施，比如“CSS 樣式表”和“JS 腳本”）

TLS（Transport Layer Security，傳輸層安全協(xié)議）是SSL的后繼版本，在SSL的基礎(chǔ)上發(fā)展優(yōu)化。

TLS的主要目標(biāo)是使SSL更安全，并使協(xié)議的規(guī)范更精確和完善，因此TLS 在SSL v3.0 的基礎(chǔ)上，提供了一些增強(qiáng)功能（包括更安全的MAC算法，更嚴(yán)密的警報，“灰色區(qū)域”規(guī)范的更明確的定義等等）

TLS允許協(xié)商失敗的時候降級使用SSLv3，但是由于出現(xiàn)漏洞，目前大部分廠商的瀏覽器已經(jīng)禁用該功能。也即現(xiàn)在主流是使用TLS，但是由于歷史遺留問題，仍然有部分服務(wù)器在使用SSL

在當(dāng)時，不使用SSL/TLS的HTTP通信，就是不加密的通信。所有信息通過明文傳播，帶來了三大風(fēng)險。

（1） 竊聽風(fēng)險（eavesdropping）：第三方可以獲知通信內(nèi)容。

（2） 篡改風(fēng)險（tampering）：第三方可以修改通信內(nèi)容。

（3） 冒充風(fēng)險（pretending）：第三方可以冒充他人身份參與通信。

SSL/TLS協(xié)議是為了解決這三大風(fēng)險而設(shè)計的，達(dá)到：

（1）認(rèn)證用戶和服務(wù)器，確保數(shù)據(jù)發(fā)送到正確的客戶機(jī)和服務(wù)器，防止身份被冒充。

（2）加密數(shù)據(jù)以防止數(shù)據(jù)中途被竊取，所有信息都是加密傳播，第三方無法竊聽

（3）維護(hù)數(shù)據(jù)的完整性，確保數(shù)據(jù)在傳輸過程中不被改變，具有校驗(yàn)機(jī)制，一旦被篡改，通信雙方會立刻發(fā)現(xiàn)。。

  咱們通常所說的 HTTPS 協(xié)議，其實(shí)就是“HTTP 協(xié)議”和“SSL/TLS 協(xié)議”的組合。你可以進(jìn)行因式分解，把 HTTPS 理解為是HTTP over SSL”或“HTTP over TLS”

總結(jié)1：SSL/TLS是在互聯(lián)網(wǎng)中實(shí)現(xiàn)通信安全的一個網(wǎng)絡(luò)協(xié)議。

二：SSL/TLS的發(fā)展歷史:

1994年，NetScape公司設(shè)計了SSL協(xié)議（Secure Sockets Layer）的1.0版，但是未發(fā)布。

1995年，NetScape公司發(fā)布SSL 2.0版，很快發(fā)現(xiàn)有嚴(yán)重漏洞。

1996年，SSL 3.0版問世，得到大規(guī)模應(yīng)用。

1999年，互聯(lián)網(wǎng)標(biāo)準(zhǔn)化組織ISOC接替NetScape公司，發(fā)布了SSL的升級版TLS 1.0版。

2006年和2008年，TLS進(jìn)行了兩次升級，分別為TLS 1.1版和TLS 1.2版。最新的變動是2011年TLS 1.2的修訂版。

目前，應(yīng)用最廣泛的是TLS 1.2/TLS1.3，接下來是SSL 3.0。目前主流瀏覽器都已經(jīng)實(shí)現(xiàn)了TLS 1.2的支持。對老玩家來說，TLS 1.0通常被標(biāo)示為SSL 3.1，TLS 1.1為SSL 3.2，TLS 1.2為SSL 3.3。

三：SSL/TLS協(xié)議實(shí)現(xiàn)簡介？

應(yīng)用層（HTTP,SMTP,IMAP）           應(yīng)用層（HTTP,SMTP,IMAP）

  |                                                      |

表示層（SSL,TLS）  <-------------> 表示層（SSL,TLS）

  |                                                        |

會話層（-）                                      會話層（-）

  |                                                        |

傳輸層（TCP,UDP）                         傳輸層（TCP,UDP）

  |                                                        |

網(wǎng)絡(luò)層（IP,IPSec）                            網(wǎng)絡(luò)層（IP,IPSec）

  |                                                        |

數(shù)據(jù)鏈路層（Ethernet）                    數(shù)據(jù)鏈路層（Ethernet）

  |                                                         |

物理層(CAT5)                                    物理層(CAT5)

從上面我們可以看出，SSL和TLS都是工作在第6層，也就是表示層（presentation），在實(shí)際的數(shù)據(jù)走向時，OSI中的層數(shù)是邏輯可變的，如果不需要可以刪除，因此如果HTTP需要加密實(shí)現(xiàn)HTTPS，那么我們就會加上表示層，因?yàn)镠TTP所在層為應(yīng)用層，可以控制下層的層數(shù)，那么這個時候我們的數(shù)據(jù)流是：應(yīng)用層--->TLS--->TCP-->IP-->物理層--->對端物理層-->......-->對端應(yīng)用層，也即通過TLS再連接到TCP如果我們只是需要HTTP，那么我們舍棄表示層，HTTP直接發(fā)送數(shù)據(jù)到TCP，也就是7層到4層。

從上面我們可以簡單地看出，TCP 協(xié)議是 HTTP 協(xié)議的基石---HTTP 協(xié)議需要依靠 TCP 協(xié)議來傳輸數(shù)據(jù)。因此，你在配置了https的服務(wù)器，查看加密端口對應(yīng)的PID，你會發(fā)現(xiàn)就是80對應(yīng)的PID，這是因?yàn)榧用苁浅休d的http的基礎(chǔ)之上的。也就是，數(shù)據(jù)先到80，然后80到443，443把80包裹起來把數(shù)據(jù)傳下去。

總結(jié)2：

1、考慮到HTTP的兼容性問題（這里所說的兼容性包括很多方面比如已有的 Web 應(yīng)用要盡可能無縫地遷移到 HTTPS；比如對瀏覽器廠商而言，改動要盡可能?。虼?nbsp;HTTPS 還是要基于 TCP 來傳輸（如果改為 UDP 作傳輸層，無論是 Web 服務(wù)端還是瀏覽器客戶端，都需要大改）

2、實(shí)現(xiàn)過程是單獨(dú)使用一個新的協(xié)議，把 HTTP 協(xié)議包裹起來（所謂的“HTTP over SSL”，實(shí)際上是在原有的 HTTP 數(shù)據(jù)外面加了一層 SSL 的封裝。HTTP 協(xié)議原有的 GET、POST 之類的機(jī)制，基本上原封不動）

例如：如果原來的 HTTP 是塑料水管，容易被戳破；那么如今新設(shè)計的 HTTPS 就像是在原有的塑料水管之外，再包一層金屬水管。一來，原有的塑料水管照樣運(yùn)行；二來，用金屬加固了之后，不容易被戳破。

注意：前面說了，HTTPS 相當(dāng)于是“HTTP over SSL”，SSL 這個協(xié)議在“可擴(kuò)展性”方面的設(shè)計也足夠牛逼，它除了能跟 HTTP 搭配，還能夠跟其它的應(yīng)用層協(xié)議搭配。如今的 SSL/TLS 可以跟很多常用的應(yīng)用層協(xié)議（比如：FTP、SMTP、POP、Telnet）搭配，來強(qiáng)化這些應(yīng)用層協(xié)議的安全性。

再說一句：其實(shí)SSL和TLS協(xié)議都是由2個子協(xié)議組成的

SSL協(xié)議可分為兩層：

SSL記錄協(xié)議（SSL Record Protocol）：它建立在可靠的傳輸協(xié)議（如TCP）之上，為高層協(xié)議提供數(shù)據(jù)封裝、壓縮、加密等基本功能的支持。

SSL握手協(xié)議（SSL Handshake Protocol）：它建立在SSL記錄協(xié)議之上，用于在實(shí)際的數(shù)據(jù)傳輸開始前，通訊雙方進(jìn)行身份認(rèn)證、協(xié)商加密算法、交換加密密鑰等。

TLS也分為兩層：

TLS 記錄協(xié)議（TLS Record）：用于封裝各種高層協(xié)議。記錄協(xié)議支持信息傳輸、將數(shù)據(jù)分段到可處理塊、壓縮數(shù)據(jù)、應(yīng)用MAC 、加密以及傳輸結(jié)果等。對接收到的數(shù)據(jù)進(jìn)行解密、校驗(yàn)、解壓縮、重組等，然后將它們傳送到高層客戶機(jī)。TLS記錄協(xié)議是一種分層協(xié)議。每一層中的信息可能包含長度、描述和內(nèi)容等字段。

TLS 握手協(xié)議（TLS Handshake）：允許服務(wù)器與客戶機(jī)在應(yīng)用程序協(xié)議傳輸和接收其第一個數(shù)據(jù)字節(jié)前彼此之間相互認(rèn)證，協(xié)商加密算法和加密密鑰。

四：SSL/TLS實(shí)現(xiàn)過程？

SSL/TLS協(xié)議的基本思路是采用公鑰加密法，也就是說，客戶端先向服務(wù)器端索要公鑰，然后用公鑰加密信息，服務(wù)器收到密文后，用自己的私鑰解密。

但是，這里有兩個問題。

（1）如何保證公鑰不被篡改？

解決方法：將公鑰放在數(shù)字證書中。只要證書是可信的，公鑰就是可信的。

（2）公鑰加密計算量太大，如何減少耗用的時間？

解決方法：每一次對話（session），客戶端和服務(wù)器端都生成一個"對話密鑰"（session key），用它來加密信息。由于"對話密鑰"是對稱加密，所以運(yùn)算速度非?？?，而服務(wù)器公鑰只用于加密"對話密鑰"本身，這樣就減少了加密運(yùn)算的消耗時間。

因此，SSL/TLS協(xié)議的基本過程是這樣的：

（1） 客戶端向服務(wù)器端索要并驗(yàn)證公鑰。

（2） 雙方協(xié)商生成"對話密鑰"。

（3） 雙方采用"對話密鑰"進(jìn)行加密通信。

上面過程的前兩步，又稱為"握手階段"（handshake）。

握手階段的詳細(xì)過程

實(shí)現(xiàn)HTTPS系列第四彈之【TLS ，SSL概念理解】

"握手階段"涉及四次通信，我們一個個來看。需要注意的是，"握手階段"的所有通信都是明文的。

1、客戶端發(fā)出請求（ClientHello）

首先，客戶端（通常是瀏覽器）先向服務(wù)器發(fā)出加密通信的請求，這被叫做ClientHello請求。

在這一步，客戶端主要向服務(wù)器提供以下信息。

（1） 客戶端支持的協(xié)議版本，比如TLS 1.0版。

（2） 一個客戶端生成的隨機(jī)數(shù)（第1個隨機(jī)數(shù)），稍后用于生成"對話密鑰"。

（3） 支持的加密方法，比如RSA公鑰加密。

（4） 支持的壓縮方法。

這里需要注意的是，客戶端發(fā)送的信息之中不包括服務(wù)器的域名。也就是說，理論上服務(wù)器只能包含一個網(wǎng)站，否則會分不清應(yīng)該向客戶端提供哪一個網(wǎng)站的數(shù)字證書。這就是為什么通常一臺服務(wù)器只能有一張數(shù)字證書的原因。

對于虛擬主機(jī)的用戶來說，這當(dāng)然很不方便。2006年，TLS協(xié)議加入了一個Server Name Indication擴(kuò)展，允許客戶端向服務(wù)器提供它所請求的域名。

2、服務(wù)器回應(yīng)（SeverHello）

服務(wù)器收到客戶端請求后，向客戶端發(fā)出回應(yīng)，這叫做SeverHello。服務(wù)器的回應(yīng)包含以下內(nèi)容。

（1） 確認(rèn)使用的加密通信協(xié)議版本，比如TLS 1.0版本。如果瀏覽器與服務(wù)器支持的版本不一致，服務(wù)器關(guān)閉加密通信。

（2） 一個服務(wù)器生成的隨機(jī)數(shù)（第2個隨機(jī)數(shù)），稍后用于生成"對話密鑰"。

（3） 確認(rèn)使用的加密方法，比如RSA公鑰加密。

（4） 服務(wù)器證書。

除了上面這些信息，如果服務(wù)器需要確認(rèn)客戶端的身份，就會再包含一項(xiàng)請求，要求客戶端提供"客戶端證書"。比如，金融機(jī)構(gòu)往往只允許認(rèn)證客戶連入自己的網(wǎng)絡(luò)，就會向正式客戶提供USB密鑰，里面就包含了一張客戶端證書。

注意：此處還會涉及數(shù)字簽名，也即數(shù)字簽名的驗(yàn)證只在TLS協(xié)議的握手過程中使用，握手結(jié)束的時候，這個數(shù)字簽名就失效了。

3、客戶端回應(yīng)

客戶端收到服務(wù)器回應(yīng)以后，首先驗(yàn)證服務(wù)器證書。如果證書不是可信機(jī)構(gòu)頒布、或者證書中的域名與實(shí)際域名不一致、或者證書已經(jīng)過期，就會向訪問者顯示一個警告，由其選擇是否還要繼續(xù)通信。

如果證書沒有問題，客戶端就會從證書中取出服務(wù)器的公鑰。然后，向服務(wù)器發(fā)送下面三項(xiàng)信息。

（1） 一個隨機(jī)數(shù)（第3個隨機(jī)數(shù)）。該隨機(jī)數(shù)用服務(wù)器公鑰加密，防止被竊聽。

（2） 編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送。

（3） 客戶端握手結(jié)束通知，表示客戶端的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時也是前面發(fā)送的所有內(nèi)容的hash值，用來供服務(wù)器校驗(yàn)。

上面第一項(xiàng)的隨機(jī)數(shù)，是整個握手階段出現(xiàn)的第三個隨機(jī)數(shù)，又稱"pre-master key"。有了它以后，客戶端和服務(wù)器就同時有了三個隨機(jī)數(shù)，接著雙方就用事先商定的加密方法，各自生成本次會話所用的同一把"會話密鑰"。

為什么一定要用三個隨機(jī)數(shù)，來生成"會話密鑰"？

解釋："不管是客戶端還是服務(wù)器，都需要隨機(jī)數(shù)，這樣生成的密鑰才不會每次都一樣。由于SSL協(xié)議中證書是靜態(tài)的，因此十分有必要引入一種隨機(jī)因素來保證協(xié)商出來的密鑰的隨機(jī)性。

對于RSA密鑰交換算法來說，pre-master-key本身就是一個隨機(jī)數(shù)，再加上hello消息中的隨機(jī)，三個隨機(jī)數(shù)通過一個密鑰導(dǎo)出器最終導(dǎo)出一個對稱密鑰。

pre master的存在在于SSL協(xié)議不信任每個主機(jī)都能產(chǎn)生完全隨機(jī)的隨機(jī)數(shù)，如果隨機(jī)數(shù)不隨機(jī)，那么pre master secret就有可能被猜出來，那么僅適用pre master secret作為密鑰就不合適了，因此必須引入新的隨機(jī)因素，那么客戶端和服務(wù)器加上pre master secret三個隨機(jī)數(shù)一同生成的密鑰就不容易被猜出了，一個偽隨機(jī)可能完全不隨機(jī)，可是是三個偽隨機(jī)就十分接近隨機(jī)了，每增加一個自由度，隨機(jī)性增加的可不是一。"

此外，如果前一步，服務(wù)器要求客戶端證書，客戶端會在這一步發(fā)送證書及相關(guān)信息。

4、服務(wù)器的最后回應(yīng)

服務(wù)器收到客戶端的第三個隨機(jī)數(shù)pre-master key之后，計算生成本次會話所用的"會話密鑰"。然后，向客戶端最后發(fā)送下面信息。

（1）編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送。

（2）服務(wù)器握手結(jié)束通知，表示服務(wù)器的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時也是前面發(fā)送的所有內(nèi)容的hash值，用來供客戶端校驗(yàn)。

至此，整個握手階段全部結(jié)束。接下來，客戶端與服務(wù)器進(jìn)入加密通信，就完全是使用普通的HTTP協(xié)議，只不過用"會話密鑰"加密內(nèi)容。

實(shí)現(xiàn)HTTPS系列第四彈之【TLS ，SSL概念理解】

總結(jié)3：實(shí)際數(shù)據(jù)傳輸所使用的對稱密鑰是通過雙方協(xié)商，根據(jù)產(chǎn)生的3個隨機(jī)數(shù)計算得出的。

結(jié)尾：

  下一篇：實(shí)現(xiàn)HTTPS系列第五彈（終章）之【通過OpenSSL實(shí)現(xiàn)HTTPS】

  博文地址：http://watchmen.blog.51cto.com/6091957/1933161

   感謝閱讀，祝有收獲的一天，謝謝！

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點(diǎn)與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

當(dāng)前題目：實(shí)現(xiàn)HTTPS系列第四彈之【TLS，SSL概念理解】-創(chuàng)新互聯(lián)
鏈接地址：http://bm7419.com/article26/gidcg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站策劃、網(wǎng)站建設(shè)、網(wǎng)站收錄、網(wǎng)站內(nèi)鏈、網(wǎng)站制作、網(wǎng)站設(shè)計

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)

網(wǎng)站托管運(yùn)營