實作HTTPS系列第四彈之【TLS ，SSL概念了解】

博文說明【前言】：

    本文将通過個人口吻介紹TLS ，SSL等相關知識，在目前時間點【2017年5月21号】下，所掌握的技術水準有限，可能會存在不少知識了解不夠深入或全面，望大家指出問題共同交流，在後續工作及學習中如發現本文内容與實際情況有所偏差，将會完善該博文内容。

1、第一彈：實作HTTPS系列第一彈之【http,https,www,web等概念簡介】

博文連結：http://watchmen.blog.51cto.com/6091957/1922919

2、第二彈：實作HTTPS系列第二彈之【非對稱加密，公鑰私鑰，數字簽名，OpenSSL及HTTPS等概念簡介】

3、第三彈：實作HTTPS系列第三彈之【數字簽名，數字證書，CA認證等概念了解】

本文參考文獻引用連結及其他資料：

該網站屬于qualys公司，qualiy's ssl labs，這是一家雲安全公司，網址：www.qualys.com

4、推薦圖書：《Bulletproof SSL and TLS》-作者Ivan Ristic，資料我已上傳，可從站内搜尋下載下傳

正文：

    首先，HTTP 是一個網絡協定，是專門用來傳輸 Web 内容。關于這個協定，就算你不了解，至少也聽說過，比如你通路百度的首頁，浏覽器位址欄會出現如下的網址http://www.baidu.com/，

這就是指通過HTTP 協定通路該百度的web伺服器的内容。在Internet發展前期，大部分網站都是通過 HTTP 協定來傳輸 Web 頁面以及 Web 頁面上包含的各種東西（圖檔、CSS 樣式、JS 腳本等）。這部分内容可以檢視的我的第一彈博文簡單了解，好，基礎知識介紹完畢，故事開始。

一：SSL/TLS是什麼？:

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

TLS（Transport Layer Security，傳輸層安全協定）是SSL的後繼版本，在SSL的基礎上發展優化。

TLS的主要目标是使SSL更安全，并使協定的規範更精确和完善，是以TLS 在SSL v3.0 的基礎上，提供了一些增強功能（包括更安全的MAC算法，更嚴密的警報，“灰色區域”規範的更明确的定義等等）

TLS允許協商失敗的時候降級使用SSLv3，但是由于出現漏洞，目前大部分廠商的浏覽器已經禁用該功能。也即現在主流是使用TLS，但是由于曆史遺留問題，仍然有部分伺服器在使用SSL

在當時，不使用SSL/TLS的HTTP通信，就是不加密的通信。所有資訊通過明文傳播，帶來了三大風險。

（1） 竊聽風險（eavesdropping）：第三方可以獲知通信内容。

（2） 篡改風險（tampering）：第三方可以修改通信内容。

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

SSL/TLS協定是為了解決這三大風險而設計的，達到：

（1）認證使用者和伺服器，確定資料發送到正确的客戶機和伺服器，防止身份被冒充。

（2）加密資料以防止資料中途被竊取，所有資訊都是加密傳播，第三方無法竊聽

（3）維護資料的完整性，確定資料在傳輸過程中不被改變，具有校驗機制，一旦被篡改，通信雙方會立刻發現。。

    咱們通常所說的 HTTPS 協定，其實就是“HTTP 協定”和“SSL/TLS 協定”的組合。你可以進行因式分解，把 HTTPS 了解為是HTTP over SSL”或“HTTP over TLS”

總結1：SSL/TLS是在網際網路中實作通信安全的一個網絡協定。

二：SSL/TLS的發展曆史:

1994年，NetScape公司設計了SSL協定（Secure Sockets Layer）的1.0版，但是未釋出。

1995年，NetScape公司釋出SSL 2.0版，很快發現有嚴重漏洞。

1996年，SSL 3.0版問世，得到大規模應用。

1999年，網際網路标準化組織ISOC接替NetScape公司，釋出了SSL的更新版TLS 1.0版。

2006年和2008年，TLS進行了兩次更新，分别為TLS 1.1版和TLS 1.2版。最新的變動是2011年TLS 1.2的修訂版。

目前，應用最廣泛的是TLS 1.2/TLS1.3，接下來是SSL 3.0。目前主流浏覽器都已經實作了TLS 1.2的支援。對老玩家來說，TLS 1.0通常被标示為SSL 3.1，TLS 1.1為SSL 3.2，TLS 1.2為SSL 3.3。

三：SSL/TLS協定實作簡介？

應用層（HTTP,SMTP,IMAP）            應用層（HTTP,SMTP,IMAP）

    |                                                        |

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

    |                                                        |

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

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

網絡層（IP,IPSec）                            網絡層（IP,IPSec）

資料鍊路層（Ethernet）                    資料鍊路層（Ethernet）

    |                                                         |

實體層(CAT5)                                    實體層(CAT5)

從上面我們可以看出，SSL和TLS都是工作在第6層，也就是表示層（presentation），在實際的資料走向時，OSI中的層數是邏輯可變的，如果不需要可以删除，是以如果HTTP需要加密實作HTTPS，那麼我們就會加上表示層，因為HTTP所在層為應用層，可以控制下層的層數，那麼這個時候我們的資料流是：應用層--->TLS--->TCP-->IP-->實體層--->對端實體層-->......-->對端應用層，也即通過TLS再連接配接到TCP如果我們隻是需要HTTP，那麼我們舍棄表示層，HTTP直接發送資料到TCP，也就是7層到4層。

從上面我們可以簡單地看出，TCP 協定是 HTTP 協定的基石---HTTP 協定需要依靠 TCP 協定來傳輸資料。是以，你在配置了https的伺服器，檢視加密端口對應的PID，你會發現就是80對應的PID，這是因為加密是承載的http的基礎之上的。也就是，資料先到80，然後80到443，443把80包裹起來把資料傳下去。

總結2：

1、考慮到HTTP的相容性問題（這裡所說的相容性包括很多方面比如已有的 Web 應用要盡可能無縫地遷移到 HTTPS；比如對浏覽器廠商而言，改動要盡可能小），是以 HTTPS 還是要基于 TCP 來傳輸（如果改為 UDP 作傳輸層，無論是 Web 服務端還是浏覽器用戶端，都需要大改）

2、實作過程是單獨使用一個新的協定，把 HTTP 協定包裹起來（所謂的“HTTP over SSL”，實際上是在原有的 HTTP 資料外面加了一層 SSL 的封裝。HTTP 協定原有的 GET、POST 之類的機制，基本上原封不動）

例如：如果原來的 HTTP 是塑膠水管，容易被戳破；那麼如今新設計的 HTTPS 就像是在原有的塑膠水管之外，再包一層金屬水管。一來，原有的塑膠水管照樣運作；二來，用金屬加強了之後，不容易被戳破。

注意：前面說了，HTTPS 相當于是“HTTP over SSL”，SSL 這個協定在“可擴充性”方面的設計也足夠牛逼，它除了能跟 HTTP 搭配，還能夠跟其它的應用層協定搭配。如今的 SSL/TLS 可以跟很多常用的應用層協定（比如：FTP、SMTP、POP、Telnet）搭配，來強化這些應用層協定的安全性。

再說一句：其實SSL和TLS協定都是由2個子協定組成的

SSL協定可分為兩層： 

SSL記錄協定（SSL Record Protocol）：它建立在可靠的傳輸協定（如TCP）之上，為高層協定提供資料封裝、壓縮、加密等基本功能的支援。 

SSL握手協定（SSL Handshake Protocol）：它建立在SSL記錄協定之上，用于在實際的資料傳輸開始前，通訊雙方進行身份認證、協商加密算法、交換加密密鑰等。

TLS也分為兩層：

TLS 記錄協定（TLS Record）：用于封裝各種高層協定。記錄協定支援資訊傳輸、将資料分段到可處理塊、壓縮資料、應用MAC 、加密以及傳輸結果等。對接收到的資料進行解密、校驗、解壓縮、重組等，然後将它們傳送到高層客戶機。TLS記錄協定是一種分層協定。每一層中的資訊可能包含長度、描述和内容等字段。

TLS 握手協定（TLS Handshake）：允許伺服器與客戶機在應用程式協定傳輸和接收其第一個資料位元組前彼此之間互相認證，協商加密算法和加密密鑰。

四：SSL/TLS實作過程？

SSL/TLS協定的基本思路是采用公鑰加密法，也就是說，用戶端先向伺服器端索要公鑰，然後用公鑰加密資訊，伺服器收到密文後，用自己的私鑰解密。

但是，這裡有兩個問題。

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

解決方法：将公鑰放在數字證書中。隻要證書是可信的，公鑰就是可信的。

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

解決方法：每一次對話（session），用戶端和伺服器端都生成一個"對話密鑰"（session key），用它來加密資訊。由于"對話密鑰"是對稱加密，是以運算速度非常快，而伺服器公鑰隻用于加密"對話密鑰"本身，這樣就減少了加密運算的消耗時間。

是以，SSL/TLS協定的基本過程是這樣的：

（1） 用戶端向伺服器端索要并驗證公鑰。

（2） 雙方協商生成"對話密鑰"。

（3） 雙方采用"對話密鑰"進行加密通信。

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

握手階段的詳細過程

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

1、用戶端送出請求（ClientHello）

首先，用戶端（通常是浏覽器）先向伺服器發出加密通信的請求，這被叫做ClientHello請求。

在這一步，用戶端主要向伺服器提供以下資訊。

（1） 用戶端支援的協定版本，比如TLS 1.0版。

（2） 一個用戶端生成的随機數（第1個随機數），稍後用于生成"對話密鑰"。

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

（4） 支援的壓縮方法。

這裡需要注意的是，用戶端發送的資訊之中不包括伺服器的域名。也就是說，理論上伺服器隻能包含一個網站，否則會分不清應該向用戶端提供哪一個網站的數字證書。這就是為什麼通常一台伺服器隻能有一張數字證書的原因。

對于虛拟主機的使用者來說，這當然很不友善。2006年，TLS協定加入了一個Server Name Indication擴充，允許用戶端向伺服器提供它所請求的域名。

2、伺服器回應（SeverHello）

伺服器收到用戶端請求後，向用戶端發出回應，這叫做SeverHello。伺服器的回應包含以下内容。

（1） 确認使用的加密通信協定版本，比如TLS 1.0版本。如果浏覽器與伺服器支援的版本不一緻，伺服器關閉加密通信。

（2） 一個伺服器生成的随機數（第2個随機數），稍後用于生成"對話密鑰"。

（3） 确認使用的加密方法，比如RSA公鑰加密。

（4） 伺服器證書。

除了上面這些資訊，如果伺服器需要确認用戶端的身份，就會再包含一項請求，要求用戶端提供"用戶端證書"。比如，金融機構往往隻允許認證客戶連入自己的網絡，就會向正式客戶提供USB密鑰，裡面就包含了一張用戶端證書。

注意：此處還會涉及數字簽名，也即數字簽名的驗證隻在TLS協定的握手過程中使用，握手結束的時候，這個數字簽名就失效了。

3、用戶端回應

用戶端收到伺服器回應以後，首先驗證伺服器證書。如果證書不是可信機構頒布、或者證書中的域名與實際域名不一緻、或者證書已經過期，就會向通路者顯示一個警告，由其選擇是否還要繼續通信。

如果證書沒有問題，用戶端就會從證書中取出伺服器的公鑰。然後，向伺服器發送下面三項資訊。

（1） 一個随機數（第3個随機數）。該随機數用伺服器公鑰加密，防止被竊聽。

（2） 編碼改變通知，表示随後的資訊都将用雙方商定的加密方法和密鑰發送。

（3） 用戶端握手結束通知，表示用戶端的握手階段已經結束。這一項同時也是前面發送的所有内容的hash值，用來供伺服器校驗。

上面第一項的随機數，是整個握手階段出現的第三個随機數，又稱"pre-master key"。有了它以後，用戶端和伺服器就同時有了三個随機數，接着雙方就用事先商定的加密方法，各自生成本次會話所用的同一把"會話密鑰"。

為什麼一定要用三個随機數，來生成"會話密鑰"？

解釋："不管是用戶端還是伺服器，都需要随機數，這樣生成的密鑰才不會每次都一樣。由于SSL協定中證書是靜态的，是以十分有必要引入一種随機因素來保證協商出來的密鑰的随機性。

對于RSA密鑰交換算法來說，pre-master-key本身就是一個随機數，再加上hello消息中的随機，三個随機數通過一個密鑰導出器最終導出一個對稱密鑰。

pre master的存在在于SSL協定不信任每個主機都能産生完全随機的随機數，如果随機數不随機，那麼pre master secret就有可能被猜出來，那麼僅适用pre master secret作為密鑰就不合适了，是以必須引入新的随機因素，那麼用戶端和伺服器加上pre master secret三個随機數一同生成的密鑰就不容易被猜出了，一個僞随機可能完全不随機，可是是三個僞随機就十分接近随機了，每增加一個自由度，随機性增加的可不是一。"

此外，如果前一步，伺服器要求用戶端證書，用戶端會在這一步發送證書及相關資訊。

4、伺服器的最後回應

伺服器收到用戶端的第三個随機數pre-master key之後，計算生成本次會話所用的"會話密鑰"。然後，向用戶端最後發送下面資訊。

（1）編碼改變通知，表示随後的資訊都将用雙方商定的加密方法和密鑰發送。

（2）伺服器握手結束通知，表示伺服器的握手階段已經結束。這一項同時也是前面發送的所有内容的hash值，用來供用戶端校驗。

至此，整個握手階段全部結束。接下來，用戶端與伺服器進入加密通信，就完全是使用普通的HTTP協定，隻不過用"會話密鑰"加密内容。

總結3：實際資料傳輸所使用的對稱密鑰是通過雙方協商，根據産生的3個随機數計算得出的。

結尾：

    下一篇：實作HTTPS系列第五彈（終章）之【通過OpenSSL實作HTTPS】

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

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

      本文轉自1清風攬月1  51CTO部落格，原文連結：http://blog.51cto.com/watchmen/1927937，如需轉載請自行聯系原作者