實現HTTPS系列第四彈之【TLS ，SSL等概念理解】
博文說明【前言】：
本文將通過個人口吻介紹TLS ，SSL，PKI等相關知識，在目前時間點【2017年5月21號】下，所掌握的技術水平有限，可能會存在不少知識理解不夠深入或全面，望大家指出問題共同交流，在後續工作及學習中如發現本文內容與實際情況有所偏差，將會完善該博文內容。
1、第一彈：實現HTTPS系列第一彈之【http,https,www,web等概念簡介】
博文鏈接：http://watchmen.blog.51cto.com/6091957/1922919
2、第二彈：實現HTTPS系列第二彈之【非對稱加密，公鑰私鑰，數字簽名，OpenSSL及HTTPS等概念簡介】
博文鏈接：http://watchmen.blog.51cto.com/6091957/1923426
3、第三彈：實現HTTPS系列第三彈之【數字簽名，數字證書，CA認證等概念理解】
博文鏈接：http://watchmen.blog.51cto.com/6091957/1924747
本文參考文獻引用鏈接及其他資料：
1、https://www.openssl.org/docs/
2、https://www.feistyduck.com/?【經典，強烈推薦，TLS/SSL技術文檔網站】
3、https://www.ssllabs.com 【經典，強烈推薦,在線檢測網站SSL/TLS安全強度】
該網站屬於qualys公司，qualiy‘s ssl labs，這是一家雲安全公司，網址：www.qualys.com
4、推薦圖書：《Bulletproof SSL and TLS》-作者Ivan Ristic，資料我已上傳，可從站內搜索下載
下載路徑：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 是一個網絡協議，是專門用來傳輸 Web 內容。關於這個協議，就算你不了解，至少也聽說過，比如你訪問百度的主頁，瀏覽器地址欄會出現如下的網址http:
這就是指通過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所在層為應用層，可以控制下層的層數，那麽這個時候我們的數據流是：物理層--->TCP-->TLS-->http-->對端物理層-->......-->對端應用層，也即通過TLS再連接到TCP如果我們只是需要HTTP，那麽我們舍棄表示層，直接從TCP將數據發送至7層的HTTP，也就是4層到7層。
從上面我們可以簡單地看出，TCP 協議是 HTTP 協議的基石---HTTP 協議需要依靠 TCP 協議來傳輸數據。
總結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/1927938
實現HTTPS系列第四彈之【TLS ，SSL等概念理解】