背景
https協(xié)議對于我們做開發(fā)的小伙伴往往是一種既熟悉又朦朧的存在：對基本的概念有大致的了解包括加密，證書等等但是由于HTTP協(xié)議本身已經(jīng)有了很好的封裝所以對于通信細節(jié)往往缺乏全面的了解，筆者也是由于工作中正好碰到了相關的證書問題出于解決問題的需要對協(xié)議本身有了一些分析和了解。在查詢文獻過程中發(fā)現(xiàn)網(wǎng)上文章多而雜所以結合https抓包整理成簡書文章分享給大家，希望能給大家?guī)韼椭?/p>
1.HTTPS協(xié)議的通信過程概述
HTTPS的通信一般使用非對稱加密進行秘鑰傳遞然后使用對稱加密進行后面的業(yè)務數(shù)據(jù)的傳輸。過程如下圖所示：
首先，是著名的TCP三次握手，然后是客戶端和服務端的通信協(xié)議協(xié)商服務端會從客戶端發(fā)送的協(xié)議中選擇一種作為加密算法協(xié)議，再然后是服務端發(fā)送CA證書到客戶端驗證身份，驗證通過后客戶端會將私鑰最后一段通過服務端公鑰非對稱加密傳送到服務端，后面客戶端會利用協(xié)商好的機密算法和對稱秘鑰進行加密通信。
關鍵詞：TCP三次握手，CA證書，證書鏈，加密協(xié)議協(xié)商
2.TCP三次握手
tcp的三次握手主要流程是SYN>>>SYN,ACK>>>ACK相信大家都比較熟悉了。這里主要說下為什么是三次握手，三次握手都握了什么。
要理解tcp握手的三次過程就要先有一個背景知識就是tcp通信中的seq number，next seq number以及acknowledgment number的概念。簡單來說就是B收到A發(fā)送的數(shù)據(jù)包中就會有seq+數(shù)據(jù)包長度len就可以計算出next seq number。next seq number作用有兩個：1、B如果再接收到A的下一個數(shù)據(jù)包后就可以將下一個數(shù)據(jù)包的seq和本次的next seq number比較來判斷中間是否有丟包 2、B通過將計算出的next seq number作為acknowledgment number返回給A來和A確認包的接收情況。（參見下圖）
有了以上背景我們就能理解tcp的三次握手內(nèi)容是啥了，其實就是A和B在交換各自的初始seq number。首先A將seq作為SYN發(fā)給B為，B在該seq上加1作為ACK返回A同時將自己的seq作為SYN發(fā)給A，A校驗通過后在B的seq上加1作為ACK返回給B。如果A和B都能校驗通過則連接建立，如上描述TCP的握手最少為三次（B將ACK和SYN合并為一次）。
3.加密協(xié)議協(xié)商
在加密過程中首先客戶端發(fā)送ClientHello消息攜帶支持的加密算法（圖中Cipher Suites）和一段隨機數(shù)字Random1到服務端。其中隨機數(shù)字Random1會在后面的對稱加密中用到。
然后服務端會在客戶端加密算法中選擇一個自己也支持的加密算法作為后面通信的加密算法（本次實驗中服務端選擇TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 作為加密算法）和隨機數(shù)Random2。
4.證書驗證
服務端如果能夠支持客戶端的協(xié)議，則服務端發(fā)送證書到客戶端進行身份驗證。關于證書驗證個人感覺主要需要掌握兩點：證書鏈和防偽。如果以介紹信作為類比可以這樣形容張三拿著李四開的介紹信去別的地方辦事，這時候別人就會有兩個疑問第一這個介紹信是不是李四開的（防偽），憑什么李四的介紹信說你是張三你就是張三吶（證書鏈）？
關于防偽有一個非對稱加密的背景知識需要理解（關于非對稱加密現(xiàn)在網(wǎng)上將的最明白的一篇文章就是卡卡羅2017大神的文章）簡單來說非對稱加密的一個核心就是六點：1，公鑰和私鑰成對出現(xiàn) 2，公開的密鑰叫公鑰，只有自己知道的叫私鑰3，用公鑰加密的數(shù)據(jù)只有對應的私鑰可以解密4，用私鑰加密的數(shù)據(jù)只有對應的公鑰可以解密5，如果可以用公鑰解密，則必然是對應的私鑰加的密6，如果可以用私鑰解密，則必然是對應的公鑰加的密?；氐奖绢}中，則證書頒發(fā)過程其實就是上級證書頒發(fā)機構通過持有的私鑰為證書請求Server信息通過私鑰進行加密簽名，客戶端證書驗證則是收到Server證書后通過證書頒發(fā)機構的公鑰對簽名進行解密如果能夠解密則一定是證書頒發(fā)機構頒發(fā)的證書如果解密后信息與Server信息一致則確實是頒發(fā)給該Server的，綜上校驗通過。
如果理解了防偽則證書鏈就好理解了，Server將自己證書發(fā)送到客戶端時候會連同頒發(fā)機構證書一同發(fā)往客戶端，通過和Server證書驗證同樣的過程通過內(nèi)嵌在瀏覽器或者JDK中的根證書驗證下中級證書的合法性就好了。因為根證書是內(nèi)嵌的具有絕對的合法性，如果根證書信任該中級機構，則該中級證書頒發(fā)的證書也是可信的這就是證書鏈了。所以寫到這里你就知道隨便安裝根證書的危害了，以后只要是該根證書信任的證書就都能為客戶端信任了。
主要在本次消息中的兩個證書：中級證書和server證書。
5.秘鑰傳遞
證書驗證通過后，則生成隨機數(shù)Random3通過server證書中的公鑰（同時也是Server非對稱加密算法公鑰）加密并傳遞給服務端。Random3只有服務端利用存儲的秘鑰才能解密得到，這樣對稱算法最后一段傳遞完成。
6.加密通信
由于非對稱加密的運算成本較高，所以一般只用來進行秘鑰傳遞所以完成秘鑰傳遞之后則客戶端一般會使用之前協(xié)商的加密算法并將Random1+Random2+Random3作為對稱加密算法的秘鑰進行加密通信。
7.總結
關于非對稱加密非常重要的一點就是私鑰和公鑰成對出現(xiàn)，如果能用私鑰解密則一定是用公鑰加密如果能用公鑰解密則一定為私鑰加密這個前提對于理解證書簽名認證非常重要
參考文獻：
http://m.itdecent.cn/p/7615d036969f
https://juejin.im/entry/5904345ab123db3ee4755ebb
https://cattail.me/tech/2015/11/30/how-https-works.html
https://www.aneasystone.com/archives/2016/04/java-and-https.html?tdsourcetag=s_pctim_aiomsg
