首先講解一下這篇文字的背景。你看到的這篇文章其實已經寫了很久了，不過在最近進行了一次大的改版。因爲作者之前寫這篇文字的時候並沒有完全掌握https協議的精髓，只是記錄下了https協議的一些知識點，雖然這期間作者也陸續增添了幾次內容。直到作者前幾天在聽完某大佬分享了https協議，併產生了深深的自我懷疑——爲什麼有人可以隨時把https建立連接的過程講得那麼清楚？這個過程明明很複雜啊！大佬當時給我的答案是：“那你就是沒有真正理解！真正理解了是不會忘記的！”。於是，作者在大腦中深度思考了兩天，並翻閱了所有能翻閱的資料後，終於把思路理順了。。。
一、讀完本文你將收穫什麼？
1、一張可以概括https建立連接過程的圖，當別人詢問你https相關知識時，你的腦海裏只需要檢索出這幅圖就可以了。
2、區分幾個看似很好理解，卻很容易理解錯，而要想掌握https協議又必須知道的密碼學基礎知識。比如，
（1）「密鑰」、「密碼」、「加密」這三者有什麼關係？
（2）什麼是「對稱加密」和『非對稱加密」?
（3）什麼是「公鑰」和「私鑰」？
（4）什麼是「數字簽名」和「數字證書」？
3、「https協議建立連接」的過程和「建立TSL連接」的過程有什麼關係？
4、https協議的精髓是什麼？學會了什麼，纔算懂得https協議了？
接下來我們由淺入深逐步揭開https協議的神祕面紗。準備好跟作者一起探索https協議之旅了嗎？let's go！！
二、HTTP協議有什麼問題
- 如果你通過http協議訪問一個網站，其所有內容都是明文傳輸。這意味着你的私人信息（用戶名、密碼）可能被別人看到。舉個栗子，當你連接到wifi上，你和服務端通過http協議傳輸的任何內容都可以被其他連接到該wifi的用戶看到。
- 如果你通過http協議訪問一個網站，服務端返回的數據很可能被第三方篡改。舉個栗子，當你看愛奇藝視頻時，服務端本來發送給你的是“創造101”小姐姐的視頻，可這視頻可以被第三方截取，然後添加一段超級爛的廣告再返回給你。
- 如果你通過http協議訪問一個網站，服務端返回的數據很可能被掉包。舉個栗子，當你想在淘寶買件衣服時，第三方可以截取淘寶返回的商品詳情，直接給你換成亞馬遜的某件衣服。
總之你通過http協議訪問一個網站時，很可能就像下面這幅圖一樣。
總結一下，https協議存在以下三個問題：「竊聽風險」、「篡改風險」、「冒充風險」。
而https協議的產生就是爲了解決這三個問題。
三、HTTPS握手的整個過程
你要連接到https://github.com/colinNaive這個網站時，你看到的一切就只是你能看到的，你看不到的還有複雜的https握手的整個過程。
下圖可以概括https握手的整個過程。這裏可以先暫停一下，花幾分鐘時間仔細研究一下這張圖。
https握手具體的步驟如下：
- 服務端生成一個公鑰和一個私鑰，然後把公鑰發給CA進行認證。那麼CA怎麼認證的呢？CA自己也有一個公鑰和一個私鑰，它把自己的公鑰內置到各大主流瀏覽器中，然後用自己的私鑰來加密服務端發來的公鑰，並把加密好的公鑰返還給服務端。（嚴格意義上說，這一步還不是https握手的具體步驟之一，這一步是準備步驟，準備好了這一步纔可以進行https握手）。
- 客戶端請請求服務器發送建立連接消息，消息中包含支持的加密算法，使用的協議等。
- 服務器收到客戶端支持的加密算法後，和自己支持的加密算法進行比對，如果不符合，就斷開連接。否則，服務端對客戶端迴應一個消息，消息中包含：符合的加密算法、數字證書和數字簽名。
- 客戶端收到消息後，對證書的真僞進行驗證。
- 驗證通過之後，客戶端會生成一個隨機字符串，然後用服務端發來的公鑰進行加密，這裏就保證了只有服務端能夠看到這個隨機字符串。同樣，客戶端生成一個數字簽名。
- 服務器接收到到隨機祕鑰，然後開始進行數據交換。
可能你對上面的步驟仍然存在疑惑，下面我們來一一爲你解惑。
四、HTTPS協議簡介
最初在作者淺薄的認識裏，https協議是這樣的——“https協議是更安全的http協議，它比http協議多了一個加密連接”。這個理解的後半句其實是含糊其辭的，不準確的。「加密連接」是什麼鬼？到底是加密，還是連接？https協議到底比http協議多了什麼？其實準備的說法應該是這樣的：
- https協議比http協議多了加密傳輸（https協議中所有客戶端與服務端之間通信的數據都是經過加密的）。
- https協議比http協議多了TSL連接（TSL連接保證了客戶端與服務端建立了安全的連接）。
1、HTTPS是什麼？
聊了這麼多，https到底是什麼呢？我們首先來看一張圖。
最底層是Network層，上面是IP層，再上面是傳輸層，再往上看，是TLS層，然後是HTTP層。這就是https協議的整個層次圖。也就是說，相比http協議，https協議在傳輸層之上多了一個TLS層，弄懂TLS層做了什麼，就掌握了https協議的精髓。
總結一下，HTTPS協議是工作在TLS層上的HTTP協議，通過在傳輸層和HTTP層之間加入TLS層（Transport Layer Security）來「加密、認證、數據完整性保護」。這三個詞你現在可能不是很理解，不用擔心，讀完本文你就可以理解這三個詞的含義了。
不過，這裏總結出一個公式：
HTTPS = 加密 + 認證 + 數據完整性保護 + HTTP
2、TLS協議是什麼？
很多人理解中的https中的s就是SSL，殊不知，SSL已經在技術升級換代中被替代，替代SSL的就是TSL。TSL是SSL的現實版應用。我們來看看TSL是如何替代SSL的：
- 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的修訂版。
很明顯TSL就是SSL的升級版。
爲了能真正理解https協議，我們還必須弄懂以下幾個概念
五、必須要弄懂的幾個密碼學基本概念
1、密鑰、密碼、加密
- 密鑰是一種參數，它是在「明文轉換爲密文」或「密文轉換爲明文」的算法中輸入的參數。
- 密碼是一種特定的暗號或口令，常在個人取款或保密通信中用到。
- 加密包含算法和密鑰兩個元素。算法將密鑰和密鑰數據結合產生一個不易理解的密文。
我們說要對https協議傳輸的數據進行加密，那是怎麼加密的呢？我們知道是通過密鑰和算法，那麼密鑰和算法是不是都是保密的呢？答案是“No！”。要想搞清楚https加密的算法其實不難，最常用的加密算法也就那麼幾種，而這其中RSA加密算法是最普遍的。那麼什麼是保密的呢？是傳入加密算法中的參數——密鑰。
2、對稱加密&非對稱加密
- 對稱加密，又稱共享密鑰。對稱密鑰在加密和解密的過程中使用的密鑰是相同的，常見的對稱加密算法有DES、3DES、AES、RC5、RC6。缺點是發送方和接收方需要協商共享同一把密鑰，優點是計算速度快。
- 非對稱加密，又稱公開密鑰。服務端會生成一對密鑰，一個私鑰保存在服務端，僅自己知道；另一個是公鑰，可以發佈供任何人使用。客戶端通過公鑰加密的明文，需要服務端用私鑰解密。之所以稱爲不對稱加密，是因爲其加密和解密需要不同的密鑰。
這裏我們重點講一下非對稱加密。首先請思考一下這幾個問題。
- 公鑰加密，可以由公鑰解密嗎？
- 私鑰加密，可以由私鑰解密嗎？
- 私鑰是保存在客戶端，還是保存在服務端？
公鑰加密，只能由私鑰解密；而私鑰加密，只能由公鑰解密。那如果公鑰加密由公鑰解密會解密出什麼呢？答案是什麼都解密不出來。我們可以簡單的模擬一下，用AES算法加密，用DES算法解密。道理是相類似的。這裏提供一個在線加解密測試網址：
http://tool.oschina.net/encrypt
在https協議中私鑰是保存在服務端的，這一點比較容易搞錯。因爲離我們日常開發最近的能接觸到公鑰和私鑰的是使用git時，配置git時私鑰是保存在客戶端，而公鑰是保存在github上的，這和https協議是不同的。
3、數字簽名
把服務端報文通過hash處理，得到摘要信息，然後再通過服務端私鑰加密，就生成了一個數字簽名。數字簽名是用來驗證傳輸的內容是不是真實服務器發送的數據，發送的數據有沒有被篡改過。那麼數字簽名是怎麼用來驗證傳輸內容有沒有被篡改過呢？下面我們來看一下驗證過程：
- 第一步：服務端把報文經過hash處理，生成摘要信息（digest1），把這個摘要信息用私鑰加密，得到一個數字簽名。
- 第二步：當客戶端接收到數據，把簽名抽取出來，用公鑰來解密。
- 第三步：客戶端將報文提取出來做同樣的hash處理，得到digest2，與digest1比較，如果相等則確認沒有被篡改過。
這裏爲什麼要清楚數字簽名的概念？因爲TSL層握手過程中，就要驗證數據的完整性，這裏就用到了數字簽名。
這裏總結兩個公式：
摘要 = 報文 + hash
摘要 -> 服務端私鑰進行加密 = 數字簽名
4、數字證書
剛講完了數字簽名，怎麼又冒出來了一個數字證書？作者是不是弄錯了？數字證書是不是就是數字簽名？數字證書跟數字簽名是完全不同的兩個存在，這裏請不要搞混了。
數字證書的作用是：
- 證明“數據沒有被掉包，確實是來自己客戶端請求的服務器”。
- 把服務端生成的公鑰順利發送給客戶端。
公鑰爲什麼要發送給客戶端呢？因爲在客戶端驗證了“數據完整性”、“數據沒有被掉包”後，會生成了隨機數，這個隨機數會發送給服務端，在服務端接收到該隨機數後，客戶端和服務端就會用該隨機數進行對稱加密。那怎麼保證這個隨機數能安全的到達服務端呢？就需要用公鑰加密，然後服務端收到隨機數後再用私鑰解密。
向CA提交的證書申請文件如下：
這裏總結一個公式：
服務端公鑰 + 服務端基本信息 -> CA私鑰 = 數字證書
六、總結
本文講解了https的握手的完整過程。在開始寫這篇文章之前，作者對於https的握手過程的認知是混亂的，經過幾天的深度思考後，作者寫下了這篇文章。這篇文章包含了作者的全部思考過程。當你看到這裏時，作者已經把自己認爲需要講解的知識點都講解了，如果你還有疑問，可以隨時評論，作者會第一時間回覆。
七、參考
https://www.cnblogs.com/ehcoo/p/6368304.html
https://blog.csdn.net/xiaofei0859/article/details/70747034
https://www.jianshu.com/p/33d0f8631f90
https://www.jianshu.com/p/b0b6b88fe9fe
https://jingyan.baidu.com/article/a3a3f811cb3e0d8da3eb8a5e.html