Android之網(wǎng)絡(luò)—第二篇（Https原理）

前言：這篇網(wǎng)絡(luò)系列的初衷是分享下網(wǎng)絡(luò)相關(guān)的知識，文章屬于個人的學(xué)習(xí)總結(jié)博客。部分內(nèi)容來源網(wǎng)絡(luò)，如有不適豁护，請私聊。

Android之網(wǎng)絡(luò)—第一篇（Http原理）
Android之網(wǎng)絡(luò)—第二篇（Https原理）
Android之網(wǎng)絡(luò)—第三篇（解讀OkHttp）
Android之網(wǎng)絡(luò)—第四篇（解讀Retrofit）

什么是Https：

說的通俗一點就是身披安全衣的Http欲间，本質(zhì)還是http楚里，只是在http外層嵌套了一個SSL/TLS的安全層，該層做了一些數(shù)據(jù)的加解密處理猎贴。

在講解Https原理之前班缎，先做點準(zhǔn)備工作，因為會涉及到SSL/TLS連接建立她渴、SSL/TLS加解密方面的知識吝梅。所以會整體從網(wǎng)絡(luò)架構(gòu)和比較重要的知識點回顧下網(wǎng)絡(luò)知識。

TCP/IP協(xié)議

在講解什么是SSL/TLS之前惹骂，回顧下TCP/IP協(xié)議的分層概念苏携。通常一個網(wǎng)絡(luò)的傳輸中間會經(jīng)過很多的傳輸節(jié)點，才最終達(dá)到服務(wù)器对粪。期間過程會包含數(shù)據(jù)的拆分和拼裝右冻、IP的解析、數(shù)據(jù)的傳輸?shù)鹊炔僮髦茫蔷W(wǎng)絡(luò)傳輸是很不穩(wěn)定的纱扭，如果這次網(wǎng)絡(luò)請求在中間的某一節(jié)點失敗了，難道還要重新再發(fā)送一遍么儡遮？答案是不應(yīng)該這么做乳蛾。

image.png

為了網(wǎng)絡(luò)傳輸?shù)慕y(tǒng)一規(guī)范，就設(shè)計了這么一套網(wǎng)絡(luò)通信的規(guī)范鄙币，每一層都專注做一件事情肃叶，即使當(dāng)前失敗了，也在這層做處理就可以了十嘿，盡量避免重發(fā)因惭。


image.png

簡單解釋下，每層的含義：

  • 應(yīng)用層：決定了向用戶提供應(yīng)用服務(wù)時候的通信活動绩衷。應(yīng)用層負(fù)責(zé)傳送各種最終形態(tài)的數(shù)據(jù)蹦魔，是直接與用戶打交道的層激率，典型協(xié)議是HTTP、FTP等勿决。
  • 傳輸層：負(fù)責(zé)傳送文本數(shù)據(jù)乒躺。傳輸層有兩個性質(zhì)不同的協(xié)議： TCP（Transmission Control Protocol，傳輸控制協(xié)議）和 UDP（User Data Protocol低缩，用戶數(shù)據(jù)報協(xié)議）嘉冒。
  • 網(wǎng)絡(luò)層：負(fù)責(zé)分配地址和傳送二進(jìn)制數(shù)據(jù)，主要協(xié)議是IP協(xié)議表制；
  • 鏈路層：負(fù)責(zé)建立電路連接，是整個網(wǎng)絡(luò)的物理基礎(chǔ)控乾，典型的協(xié)議包括以太網(wǎng)么介、ADSL等。

通過上圖發(fā)現(xiàn)蜕衡，數(shù)據(jù)是由上往下傳遞后壤短，再由下往回傳遞。這是怎么回事呢慨仿？總結(jié)就是：在 TCP / IP　協(xié)議中數(shù)據(jù)先由上往下將數(shù)據(jù)裝包久脯，然后由下往上拆包。在裝包的時候镰吆，每一層都會增加一些信息用于傳輸帘撰，這部分信息就叫報頭，當(dāng)上層的數(shù)據(jù)到達(dá)本層的時候万皿，會將數(shù)據(jù)加上本層的報頭打包在一起摧找，繼續(xù)往下傳遞。在拆包的時候牢硅，每一層將本層需要的報頭讀取后蹬耘，就將剩下的數(shù)據(jù)往上傳。


image.png

簡要分析下傳輸過程：

  • 首先作為發(fā)送端的客戶端在應(yīng)用層（HTTP 協(xié)議）發(fā)出的HTTP請求（如：想瀏覽www.baidu.com）减余，并生成HTTP報文综苔。
  • 為了傳輸方便，在傳輸層（TCP 協(xié)議）把從應(yīng)用層處收到的數(shù)據(jù)（HTTP 請求報文）進(jìn)行分割位岔，并在各個報文上打上標(biāo)記序號及端口號后轉(zhuǎn)發(fā)給網(wǎng)絡(luò)層如筛。
  • 在網(wǎng)絡(luò)層（IP 協(xié)議），增加作為通信目的地的 MAC 地址后轉(zhuǎn)發(fā)給鏈路層抒抬。
  • 給這些數(shù)據(jù)附加上以太網(wǎng)首部并進(jìn)行發(fā)送處理妙黍，生成的以太網(wǎng)數(shù)據(jù)包將通過物理層傳輸給接收端。
  • 接收端的服務(wù)器在鏈路層接收到數(shù)據(jù)瞧剖，按序往上層發(fā)送拭嫁，一直到應(yīng)用層可免。當(dāng)傳輸?shù)綉?yīng)用層，才能算真正接收到由客戶端發(fā)送過來的 HTTP 請求做粤。

\color{red}{而Https就是在應(yīng)用層和傳輸層之間加一個SSL/TLS的數(shù)據(jù)加解密層浇借。}

TCP的三次握手和四次揮手

這里簡單總結(jié)下傳輸層的兩種連接方式：TCP和UDP

  • 用戶數(shù)據(jù)報協(xié)議（UDP）:這種類型不要求建立和斷開連接，發(fā)送端可任何時候發(fā)送數(shù)據(jù)怕品，接收端也不知道自己何時從哪里接受數(shù)據(jù)妇垢。
  • 傳輸控制協(xié)議（TCP）:發(fā)送數(shù)據(jù)之前，需要在收發(fā)主機(jī)之間建立一條通信線路肉康，在通信傳輸前后闯估，專門進(jìn)行建立和斷開連接的處理，如果與對端之間無法通信吼和，可避免發(fā)送無謂的數(shù)據(jù)涨薪。

三次握手：客戶端主動打開連接，服務(wù)器被動打開連接炫乓。

  • image.png

  • 第一次握手：客戶端向服務(wù)器發(fā)出連接請求報文刚夺，這是報文首部中的同部位SYN=1，同時選擇一個初始序列號 seq=x 末捣，此時侠姑，TCP客戶端進(jìn)程進(jìn)入了 SYN-SENT（同步已發(fā)送狀態(tài)）狀態(tài)。

  • 第二次握手：服務(wù)器收到請求報文后箩做，如果同意連接莽红，則發(fā)出確認(rèn)報文。確認(rèn)報文中應(yīng)該 ACK=1邦邦，SYN=1船老，確認(rèn)號是ack=x+1，同時也要為自己初始化一個序列號 seq=y圃酵，此時柳畔，TCP服務(wù)器進(jìn)程進(jìn)入了SYN-RCVD（同步收到）狀態(tài)。

  • 第三次握手：客戶進(jìn)程收到確認(rèn)后郭赐，還要向服務(wù)器給出確認(rèn)薪韩。確認(rèn)報文的ACK=1，ack=y+1捌锭，自己的序列號seq=x+1俘陷，此時，TCP連接建立观谦，客戶端進(jìn)入ESTABLISHED（已建立連接）狀態(tài)拉盾。服務(wù)器端檢查ack是否為y+1，ACK是否為1豁状，如果正確則連接建立成功捉偏，客戶端和服務(wù)器端進(jìn)入ESTABLISHED狀態(tài)倒得，完成三次握手，隨后客戶端與服務(wù)器端之間可以開始傳輸數(shù)據(jù)了夭禽。

為什么3次握手:

  • 前兩次的握手很顯然是必須的霞掺，主要是最后一次，即客戶端收到服務(wù)端發(fā)來的確認(rèn)后為什么還要想服務(wù)端再發(fā)送一次確認(rèn)呢讹躯？\color{red}{這主要是為了防止已失效的請求報文段突然又傳送到了服務(wù)端而產(chǎn)生連接的誤判菩彬。}

  • 考慮如下的情況：客戶端發(fā)送了一個連接請求報文段到服務(wù)端，但是在某些網(wǎng)絡(luò)節(jié)點上長時間滯留了潮梯，而后客戶端又超時重發(fā)了一個連接請求報文段該服務(wù)端骗灶，而后正常建立連接，數(shù)據(jù)傳輸完畢秉馏，并釋放了連接耙旦。如果這時候第一次發(fā)送的請求報文段延遲了一段時間后，又到了服務(wù)端沃饶，很顯然母廷，這本是一個早已失效的報文段轻黑，但是服務(wù)端收到后會誤以為客戶端又發(fā)出了一次連接請求糊肤，于是向客戶端發(fā)出確認(rèn)報文段，并同意建立連接氓鄙。但是客戶端認(rèn)為之前的連接已經(jīng)失效了馆揉，不會給服務(wù)器發(fā)送任何數(shù)據(jù)，服務(wù)端就會一直等待下去抖拦，直到超出鄙ǎ活計數(shù)器的設(shè)定值，而將客戶端判定為出了問題态罪，才會關(guān)閉這個連接噩茄。這樣就浪費了很多服務(wù)器的資源。

  • 如果采用的是三次握手复颈，就算是那一次失效的報文傳送過來了绩聘，服務(wù)端接受到了那條失效報文并且回復(fù)了確認(rèn)報文，但是客戶端不會再次發(fā)出確認(rèn)耗啦。由于服務(wù)器收不到確認(rèn)凿菩，就知道客戶端并沒有請求連接。

四次揮手：客戶端主動關(guān)閉帜讲，服務(wù)器被動關(guān)閉

  • image.png

  • 第一次揮手：客戶端進(jìn)程發(fā)出連接釋放報文衅谷，并且停止發(fā)送數(shù)據(jù)。釋放數(shù)據(jù)報文首部似将，F(xiàn)IN=1获黔，其序列號為seq=u（等于前面已經(jīng)傳送過來的數(shù)據(jù)的最后一個字節(jié)的序號加1）蚀苛，此時，客戶端進(jìn)入FIN-WAIT-1（終止等待1）狀態(tài)肢执。意思是說"我客戶端沒有數(shù)據(jù)要發(fā)給你了"枉阵，但是如果你服務(wù)器端還有數(shù)據(jù)沒有發(fā)送完成，則不必急著關(guān)閉連接预茄，可以繼續(xù)發(fā)送數(shù)據(jù)兴溜。

  • 第二次揮手：服務(wù)器收到連接釋放報文，發(fā)出確認(rèn)報文耻陕，ACK=1拙徽，ack=u+1，并且?guī)献约旱男蛄刑杝eq=v诗宣，此時膘怕，服務(wù)端就進(jìn)入了CLOSE-WAIT（關(guān)閉等待）狀態(tài)。意思是說“你的請求我收到了召庞，但是我還沒準(zhǔn)備好岛心，請繼續(xù)你等我的消息±鹤疲”
    客戶端收到服務(wù)器的確認(rèn)請求后忘古，此時，客戶端就進(jìn)入FIN-WAIT-2（終止等待2）狀態(tài)诅诱，等待服務(wù)器發(fā)送連接釋放報文（在這之前還需要接受服務(wù)器發(fā)送的最后的數(shù)據(jù)）髓堪。

  • 第三次揮手：服務(wù)器將最后的數(shù)據(jù)發(fā)送完畢后，就向客戶端發(fā)送連接釋放報文娘荡，F(xiàn)IN=1干旁，ack=u+1，由于在半關(guān)閉狀態(tài)炮沐，服務(wù)器很可能又發(fā)送了一些數(shù)據(jù)争群，假定此時的序列號為seq=w，此時大年，服務(wù)器就進(jìn)入了LAST-ACK（最后確認(rèn)）狀態(tài)换薄，等待客戶端的確認(rèn)。意思是說“好了鲜戒，我數(shù)據(jù)發(fā)送完畢了专控，你可以關(guān)閉了《舨停”

  • 第四次揮手：客戶端收到服務(wù)器的連接釋放報文后伦腐，必須發(fā)出確認(rèn)，ACK=1失都，ack=w+1柏蘑，而自己的序列號是seq=u+1幸冻，此時，客戶端就進(jìn)入了TIME-WAIT（時間等待）狀態(tài)咳焚，如果服務(wù)器端沒有收到ACK則可以重傳洽损。注意此時TCP連接還沒有釋放，必須經(jīng)過2MSL（最長報文段壽命）的時間后革半，當(dāng)客戶端撤銷相應(yīng)的TCB后碑定，才進(jìn)入CLOSED狀態(tài)。而服務(wù)器只要收到了客戶端發(fā)出的確認(rèn)又官，立即進(jìn)入CLOSED狀態(tài)延刘。

為什么客戶端最后還要等待2MSL:

  • 第一，保證客戶端發(fā)送的最后一個ACK報文能夠到達(dá)服務(wù)器六敬，因為這個ACK報文可能丟失碘赖，站在服務(wù)器的角度看來，我已經(jīng)發(fā)送了FIN+ACK報文請求斷開了外构，客戶端還沒有給我回應(yīng)普泡，應(yīng)該是我發(fā)送的請求斷開報文它沒有收到，于是服務(wù)器又會重新發(fā)送一次审编，而客戶端就能在這個2MSL時間段內(nèi)收到這個重傳的報文撼班，接著給出回應(yīng)報文，并且會重啟2MSL計時器割笙。

  • 第二权烧，防止類似與“三次握手”中提到了的“已經(jīng)失效的連接請求報文段”出現(xiàn)在本連接中眯亦∩烁龋客戶端發(fā)送完最后一個確認(rèn)報文后，在這個2MSL時間中妻率，就可以使本連接持續(xù)的時間內(nèi)所產(chǎn)生的所有報文段都從網(wǎng)絡(luò)中消失乱顾。這樣使下一個新的連接中不會出現(xiàn)舊連接的請求報文。

名詞解釋:
  • ACK：TCP報頭的控制位之一,對數(shù)據(jù)進(jìn)行確認(rèn).確認(rèn)由目的端發(fā)出,用它來告訴發(fā)送端這個序列號之前的數(shù)據(jù)段都收到了.比如,確認(rèn)號為X,則表示前X-1個數(shù)據(jù)段都收到了,只有當(dāng)ACK=1時,確認(rèn)號才有效,當(dāng)ACK=0時,確認(rèn)號無效,這時會要求重傳數(shù)據(jù),保證數(shù)據(jù)的完整性.
  • SYN：同步序列號宫静，TCP建立連接時將這個位置1走净。
  • FIN：發(fā)送端完成發(fā)送任務(wù)位，當(dāng)TCP完成數(shù)據(jù)傳輸需要斷開時孤里，提出斷開連接的一方將置1

現(xiàn)代密碼學(xué)

說個概念性的東西就是伏伯，現(xiàn)代密碼學(xué)分為對稱加密和非對稱加密，跟傳統(tǒng)密碼學(xué)不一樣的地方就是捌袜，除了可以加密文字內(nèi)容外说搅，還可以用于各種二進(jìn)制數(shù)據(jù)的加解密。

對稱加密：

通信雙方使用同一個密鑰虏等，使用加密算法配合上密鑰來加密弄唧，解密時使用解密算法（加密過程的完全逆運算）配合密鑰來進(jìn)行解密适肠。常用的經(jīng)典算法：DES（56 位密鑰，密鑰太短而逐漸被棄用）候引、AES（128 位侯养、192 位、256 位密鑰澄干，現(xiàn)在最流行）逛揩。


image.png
非對稱加密：

通信雙方使用公鑰和加密算法對數(shù)據(jù)進(jìn)行加密得到密文；使用私鑰和加密算法對數(shù)據(jù)進(jìn)行解密得到原數(shù)據(jù)麸俘。常用的經(jīng)典算法：RSA（可用于加密和簽名）息尺、DSA（僅用于簽名，但速度更快）疾掰。


image.png

這個有什么用搂誉？其實這個就是后面Https加解密的原理。原理這么簡單么静檬？是的炭懊，就這么簡單。但是要理解還得慢慢往下看拂檩。

  • 第一個問題：這些對稱加密和非對稱加密的破解都有哪些侮腹？

暴力破解法（窮舉法）：對于對稱加密而言，我只要拿到密鑰就可以破解了稻励。同樣的父阻，非對稱加密只要拿到私鑰也就搞定了。所以只要拿一堆密碼一個個的試望抽，在最短的時間內(nèi)找到對應(yīng)的密鑰/私鑰就搞定了加矛。

而反破解，或者對一個優(yōu)秀加密算法的定義標(biāo)準(zhǔn)是煤篙，讓破解者找不到比窮舉法（暴力力破解法）更有效的破解手段斟览，并且窮舉法的破解時間足夠長（例如數(shù)千年）

  • 第二個問題：這些對稱加密和非對稱加密的優(yōu)缺點？

  • 對稱加密：不能在不安全網(wǎng)絡(luò)上傳輸密鑰辑奈，一旦密鑰泄露則加密通信失敗苛茂。
    正常的網(wǎng)絡(luò)傳輸是要經(jīng)過很多個節(jié)點的，為了保證通信的雙方正常通信鸠窗，都必須要求知道密鑰妓羊，但是密鑰如果在網(wǎng)絡(luò)傳輸中就很容易被劫持。有泄漏的風(fēng)險稍计。如下場景：在網(wǎng)絡(luò)傳輸?shù)倪^程中在某個節(jié)點被C劫持躁绸，C就可以解密你傳輸?shù)膬?nèi)容啦。


    image.png

  • 非對稱加密：可以在不安全網(wǎng)絡(luò)上傳輸密鑰（準(zhǔn)確來說是公鑰），但是計算復(fù)雜涨颜，因此性能比對稱加密差很多费韭。
    在正常的網(wǎng)絡(luò)上通信，為保證正常通信庭瑰，通信的雙方都需要持有對方的公鑰將數(shù)據(jù)加密后發(fā)送給對方星持，接收方再將加密的數(shù)據(jù)通過自己的私鑰解密出來。這樣即使在傳輸?shù)哪硞€節(jié)點被C劫持了弹灭，C也解密不了你的數(shù)據(jù)督暂，因為數(shù)據(jù)只能用私鑰來解。

    image.png

    \color{red}{但是穷吮，這里會有個問題逻翁，C解不了數(shù)據(jù)，但是可以改數(shù)據(jù)呀捡鱼“嘶兀可以冒充給你傳輸假數(shù)據(jù)啊。咋辦驾诈？}

  • 第三個問題：私鑰加密的數(shù)據(jù)缠诅，用公鑰來解能解么？

根據(jù)上面的場景乍迄，A用B的公鑰加密的數(shù)據(jù)發(fā)送給B管引，B用私鑰可以解。反過來闯两？B用私鑰加密的數(shù)據(jù)發(fā)送給A褥伴，A用B的公鑰能不能解？答案是可以的漾狼。下面舉個不規(guī)范的例子說明下：

有個數(shù)字庫：0123456789包含十個數(shù)字重慢，加密算法都定義為：兩數(shù)相加，滿十時取個位邦投。

正常邏輯：A 有原數(shù)據(jù)為110伤锚，使用B的公鑰4和加法算法后的密文為554擅笔；然后B用自己的私鑰6和加密算法解密后的數(shù)據(jù)為110.


image.png

反向邏輯：B有原數(shù)據(jù)110志衣，使用自己的私鑰和加密算法加密后的密文為776；然后A用B的公鑰4和加密算法解密后的數(shù)據(jù)同樣為110.


image.png

結(jié)論就是：公鑰加密的數(shù)據(jù)用私鑰可以解猛们，私鑰加密的數(shù)據(jù)念脯，用公鑰也可以解。但是要注意的是弯淘，公鑰和私鑰是不能對調(diào)的绿店。

\color{red}{這個結(jié)論有什么用呢？可以用來做數(shù)字簽名，驗證數(shù)據(jù)信息的來源假勿。也就是剛才的冒充數(shù)據(jù)行為解決方法借嗽。}

簽名和驗證：

A用自己的私鑰通過加密算法得到的數(shù)據(jù)密文數(shù)據(jù)，這個數(shù)據(jù)就可以稱為簽過名转培。接收方B再用A提供的公鑰通過加密算法就可以還原數(shù)據(jù)恶导，從而就驗證了數(shù)據(jù)的真實性。因為只有A一個人擁有自己的私鑰浸须。


image.png

到這里咱們就可以聊聊剛才中間人偽造數(shù)據(jù)是如何處理了惨寿。通過對稱加密可以防止中間人偷窺數(shù)據(jù)，通過數(shù)字簽名可以防止中間人篡改偽造數(shù)據(jù)删窒。


image.png

但是完整版的簽名信息需要將簽名數(shù)據(jù)取Hash值裂垦，減少數(shù)據(jù)大小


image.png

Https的加密原理分析

好了，看完理解了上面的知識點肌索，到這里我們可以慢慢分析Https是如何工作的了蕉拢。

先來總結(jié)一句話：Https的本質(zhì)就是在客戶端和服務(wù)端之間用非對稱加密協(xié)商出一套對稱密鑰，每次發(fā)送信息之前將內(nèi)容加密诚亚，接收后解密企量，達(dá)到內(nèi)容的加密傳輸。解釋下亡电，就是整個數(shù)據(jù)的傳輸過程是用對稱加密的方式來傳輸?shù)慕旃皇敲荑€的生成是由客戶端和服務(wù)端在創(chuàng)建連接的時候通過非對稱加密的方式協(xié)商生成的。

那這里就會有一系列的問題啦：
Q：為什么不直接用非對稱加密的方式直接加密呢份乒？
A：因為非對稱加密的計算過程是復(fù)雜的數(shù)學(xué)運算恕汇，太復(fù)雜了，很慢或辖。
Q：哦哦瘾英，那既然使用對稱加密的話，這個對稱密鑰是怎么來的颂暇？
A：在實際的場景中缺谴，服務(wù)端會對接N個客戶端，這個對稱密鑰如果都使用同一個密鑰來通信的話耳鸯，肯定是不合理的湿蛔，只要破解了其中一個，其他所有的都會被破解县爬。所以整體的網(wǎng)絡(luò)架構(gòu)應(yīng)該是使用不同加密方式用不同的密鑰來進(jìn)行數(shù)據(jù)傳輸?shù)难羯丁ＤＰ腿缦聢D


image.png

Q：但是在網(wǎng)絡(luò)場景中，對稱加密的密鑰是不能直接在網(wǎng)絡(luò)上傳輸?shù)牟圃７?wù)端和客戶端是如何都知道的呢察迟？
A：這個是服務(wù)端和客戶端一起協(xié)商根據(jù)只有它倆知道的規(guī)則分別生成斩狱，就不用通過網(wǎng)絡(luò)傳輸啦。
Q：如果保證它倆協(xié)商出來的密鑰不被破解呢扎瓶？
A：當(dāng)然是使用非對稱加密的方式啦所踊。通過之前的加密知識，可以知道非對稱加密是目前來說是絕對安全的概荷。而且一個私鑰可以有多個公鑰污筷，正好滿足一個服務(wù)端對N個客戶端的場景。模型如下圖：


image.png

實際在協(xié)商通訊的過程中乍赫，這個公鑰是服務(wù)端給客戶端發(fā)送的瓣蛀。而且需要注意這個公鑰是用來協(xié)商生成對稱密鑰的，不是用來做數(shù)據(jù)的加密傳輸?shù)?/code>雷厂。

Q：哦哦惋增，原來是這樣，但是這樣子還是有問題啊改鲫，客戶端與服務(wù)端在協(xié)商生成密鑰的過程中為了保證數(shù)據(jù)被偷窺和被篡改的風(fēng)險诈皿，一般會要求有兩套公鑰和私鑰分別做加解密和簽名驗證處理的，上面的模型只有一套公鑰和私鑰像棘，沒法規(guī)避數(shù)據(jù)被被篡改的風(fēng)險呀稽亏。
A：能提出這個問題，說明之前的學(xué)習(xí)理解得很好缕题。從上面的模型截歉，可以保證在協(xié)商的過程中客戶端A/B/C/D分別向服務(wù)器傳輸?shù)臄?shù)據(jù)是安全。但是服務(wù)器發(fā)送給客戶端的數(shù)據(jù)是如何保證的呢烟零？換句話說就是瘪松，客戶端如何驗證數(shù)據(jù)是服務(wù)端發(fā)送過來的，而不是被中間假冒掉包的數(shù)據(jù)锨阿。這不就是之前講的數(shù)字簽名的內(nèi)容么宵睦？而實際情況中，就是通過CA證書來處理這個問題的墅诡。
Q：那這個CA證書是怎么驗證的呢壳嚎？
A：請看下面的CA證書的分析。

CA證書鏈分析末早。

回歸之前的分析烟馅，我們的問題點卡在了“服務(wù)器發(fā)送給客戶端的數(shù)據(jù)是如何保證的呢”。對吧荐吉。實際上在協(xié)商通信的過程中焙糟，服務(wù)端會先給客戶端下發(fā)證書信息，這個證書信息里面會包含非對稱加密的公鑰样屠。但是考慮一個問題，如何保證這個公鑰就是客戶端要的公鑰呢？或者說怎么保證這個證書就是真實的證書痪欲，而不是被篡改假冒的證書悦穿。只有驗證了這一步，客戶端才完全信賴服務(wù)端业踢，才給服務(wù)器發(fā)消息栗柒，也才接受服務(wù)器的消息。這時候就只需要一套公鑰和私鑰客戶端和服務(wù)端就可以通信了知举。

Q：那客戶端如何驗證服務(wù)端下發(fā)的證書和公鑰是正確的呢瞬沦？
A：先換個概念，將證書里面的公鑰假設(shè)為一串?dāng)?shù)據(jù)雇锡。要驗證這個數(shù)據(jù)逛钻，只需要提供這串?dāng)?shù)據(jù)的簽名以及加密這段數(shù)據(jù)的簽名的私鑰對應(yīng)的公鑰就可以了，如下圖框框所示锰提。


image.png
image.png

Q：那這樣子又有另外的一個問題產(chǎn)生了怎么去驗證這段數(shù)據(jù)的簽名的私鑰對應(yīng)的公鑰了曙痘？
A：同樣的，也是需要提供對應(yīng)的簽名和對應(yīng)簽名的私鑰對應(yīng)的公鑰立肘。

image.png

Q：但是這樣子下去就會變成一個循環(huán)了边坤，怎么辦竣稽？
其實在這里還會有一個場景問題：第三方簽發(fā)機(jī)構(gòu)不可能只給你一家公司制作證書椭赋，它也可能會給中間人這樣有壞心思的公司發(fā)放證書。這樣的锐想，中間人就有機(jī)會對你的證書進(jìn)行調(diào)包融蹂，客戶端在這種情況下是無法分辨出是接收的是你的證書文黎，還是中間人的。因為不論中間人殿较，還是你的證書耸峭，都能使用第三方簽發(fā)機(jī)構(gòu)的公鑰進(jìn)行解密。

A：是的淋纲，為處理這個問題劳闹，就需要講一個根證書的東西。先舉個例子：假設(shè)你是HR洽瞬，你手上拿到候選人的學(xué)歷證書本涕，證書上寫了持證人，頒發(fā)機(jī)構(gòu)伙窃，頒發(fā)時間等等菩颖，同時證書上，還寫有一個最重要的：證書編號为障！我們怎么鑒別這張證書是的真?zhèn)文鼗奕颍恐灰弥@個證書編號上相關(guān)機(jī)構(gòu)去查放祟，如果證書上的持證人與現(xiàn)實的這個候選人一致，同時證書編號也能對應(yīng)上呻右，那么就說明這個證書是真實的跪妥。同樣的，Https請求驗證時声滥，會用到手機(jī)操作系統(tǒng)內(nèi)置的根證書去驗證這個證書的真?zhèn)蔚摹?/p>

到這里就簡要分析完了證書的驗證過程眉撵。證書會包含很多信息，包括服務(wù)器公鑰落塑，服務(wù)器名字纽疟，服務(wù)器地區(qū)等等信息。這個是沒法篡改的憾赁。其中對Https連接來說最重要的就是服務(wù)器的公鑰缠沈。


image.png
Https連接

之前學(xué)習(xí)完TCP的連接過程颓芭，現(xiàn)在我們開始來嘮嘮Https連接。什么是Https連接呢州藕？準(zhǔn)確來說就是SSL/TLS加解密層的連接床玻。

大致的建立流程：

  • 1、客戶端請求建立TLS連接
  • 2待牵、服務(wù)端發(fā)回證書
  • 3缨该、客戶端驗證服務(wù)端證書
  • 4蛤袒、客戶端信任服務(wù)器后與服務(wù)端協(xié)商對稱密鑰
  • 5皱碘、使用對稱密鑰開始通信

詳細(xì)的建立流程：


image.png

  • 1健蕊、客戶端給服務(wù)器發(fā)送一個Client Hello缩功。同時會還會發(fā)送一些附加信息，客戶端支持的可選TLS的版本信息，比如支持1.0/1.1啦桌；Cipher Suite(加密套件)：客戶端支持的對稱加密算法有哪些，比如AES/DES板驳。支持的非對稱加密算法有哪些若治，比如RAS和支持的Hash算法等等加密信息；同時還會有一個客戶端的隨機(jī)數(shù)。

  • 2洽蛀、服務(wù)端收到信息后峡碉，會給客戶端一個回應(yīng)Server Hello。同時也會發(fā)送一些附加信息地来。服務(wù)端選定TLS的版本，比如1.1蜡秽；選定的Cipher Suite(加密套件)：對稱加密用AES，非對稱加密用RAS等等選定的加密方式；同時還會有一個服務(wù)端的隨機(jī)數(shù)睬澡。
    接著，服務(wù)器給客戶端下發(fā)證書。

  • 3云稚、客戶端驗證該證書信息，拿到證書內(nèi)的公鑰拐格。
    注意，在驗證這一步的時候金踪，可以區(qū)分證書是否是被劫持假冒的證書劣领。如果是假冒的，驗證不通過村生，https鏈接失敗肄鸽。

  • 4蟀苛、客戶端產(chǎn)生一個隨機(jī)數(shù)pre-master secret并加密后發(fā)送給服務(wù)器梅鹦。這時候客戶端和服務(wù)端就可以計算對稱密鑰了嗤栓。
    注意，即使劫持方攔截后，還將正確的證書下發(fā)給客戶端马昙，客戶端驗證通過后土匀，加密后的隨機(jī)數(shù)發(fā)送給服務(wù)器被劫持后，也只有服務(wù)器的私鑰能解，不怕信息泄露和篡改。即使劫持篡改了哼鬓，后續(xù)生成對應(yīng)的對稱密鑰是不一致的宠互。在第五步，互相發(fā)送驗證消息時是驗證不通過的。https鏈接也失敗。
    將客戶端隨機(jī)數(shù)和服務(wù)端隨機(jī)數(shù)及pre-master secret通過算法計算出對稱密鑰Master secret。其實這個Master secret包含的信息主要有四個：客戶端加密密鑰，服務(wù)端加密密鑰虑鼎，客戶端MAC secret，服務(wù)端MAC secret划址。具體的使用是：客戶端發(fā)送加密數(shù)據(jù)時，服務(wù)端用客戶端密鑰解密；服務(wù)端發(fā)送加密數(shù)據(jù)時封恰，客戶端用服務(wù)端密鑰解密。

為啥要這么處理呢？主要是防止消息被扔回來低飒。如果只有一個密鑰的話，場景是：A：“分手吧” 褥赊。期待B看到后有回應(yīng)“別分手”。但是中間劫持后崭倘，雖然看不懂，但是直接扔回來司光。然后A解密看到就是“分手吧”。那就涼涼了

客戶端MAC secret榆俺，服務(wù)端MAC secret的主要作用：用來認(rèn)證這個消息是正確的，完整的茴晋，解決對稱加密方式?jīng)]法驗證消息的缺點。

  • 5回窘、客戶端和服務(wù)端相互發(fā)送驗證信息（不過是客戶端先發(fā)送）

至此完整的Https在TLS層連接過程分析完畢诺擅。

后序：關(guān)于Https原理篇主要涉及到的知識點比較多，主要是請求連接的過程及數(shù)據(jù)的加解密模塊啡直。后續(xù)文章會針對原理的內(nèi)容從源碼角度去解讀OkHttp和Retrofit兩個官方開源的網(wǎng)絡(luò)庫烁涌。

如果覺得我的文章對你有幫助，請隨意贊賞酒觅。您的支持將鼓勵我繼續(xù)創(chuàng)作撮执！

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
禁止轉(zhuǎn)載，如需轉(zhuǎn)載請通過簡信或評論聯(lián)系作者舷丹。
  • 人面猴
    序言：七十年代末抒钱，一起剝皮案震驚了整個濱河市，隨后出現(xiàn)的幾起案子颜凯，更是在濱河造成了極大的恐慌谋币，老刑警劉巖，帶你破解...
    沈念sama閱讀 219,539評論 6贊 508
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件装获，死亡現(xiàn)場離奇詭異瑞信，居然都是意外死亡，警方通過查閱死者的電腦和手機(jī)穴豫，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 93,594評論 3贊 396
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進(jìn)店門凡简，熙熙樓的掌柜王于貴愁眉苦臉地迎上來逼友，“玉大人，你說我怎么就攤上這事秤涩≈钠颍” “怎么了？”我有些...
    開封第一講書人閱讀 165,871評論 0贊 356
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵筐眷，是天一觀的道長黎烈。 經(jīng)常有香客問我，道長匀谣，這世上最難降的妖魔是什么照棋？ 我笑而不...
    開封第一講書人閱讀 58,963評論 1贊 295
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任，我火速辦了婚禮烈炭，結(jié)果婚禮上符隙，老公的妹妹穿的比我還像新娘垫毙。我一直安慰自己，他們只是感情好丽蝎，可當(dāng)我...
    茶點故事閱讀 67,984評論 6贊 393
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布征峦。 她就那樣靜靜地躺著消请，像睡著了一般臊泰。 火紅的嫁衣襯著肌膚如雪蚜枢。 梳的紋絲不亂的頭發(fā)上，一...
    開封第一講書人閱讀 51,763評論 1贊 307
  • 城市分裂傳說
    那天，我揣著相機(jī)與錄音筷凤，去河邊找鬼苞七。 笑死蹂风，一個胖子當(dāng)著我的面吹牛惠啄，可吹牛的內(nèi)容都是我干的任内。 我是一名探鬼主播，決...
    沈念sama閱讀 40,468評論 3贊 420
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼趋距，長吁一口氣：“原來是場噩夢啊……” “哼棚品！你這毒婦竟也來了铜跑？” 一聲冷哼從身側(cè)響起锅纺，我...
    開封第一講書人閱讀 39,357評論 0贊 276
  • 萬榮殺人案實錄
    序言：老撾萬榮一對情侶失蹤囤锉，失蹤者是張志新（化名）和其女友劉穎护锤，沒想到半個月后烙懦，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體氯析，經(jīng)...
    沈念sama閱讀 45,850評論 1贊 317
  • ?護(hù)林員之死
    正文 獨居荒郊野嶺守林人離奇死亡，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 38,002評論 3贊 338
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年雪情，在試婚紗的時候發(fā)現(xiàn)自己被綠了巡通。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 40,144評論 1贊 351
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡正卧，死狀恐怖炉旷，靈堂內(nèi)的尸體忽然破棺而出窘行，到底是詐尸還是另有隱情罐盔，我是刑警寧澤救崔，帶...
    沈念sama閱讀 35,823評論 5贊 346
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布六孵，位于F島的核電站劫窒，受9級特大地震影響主巍，放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜逛艰，卻給世界環(huán)境...
    茶點故事閱讀 41,483評論 3贊 331
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一瓮孙、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧脸甘，春花似錦、人聲如沸钝的。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,026評論 0贊 22
  • 一樁弒父案，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽啼肩。三九已至祈坠，卻和暖如春赦拘，著一層夾襖步出監(jiān)牢的瞬間躺同，已是汗流浹背蹋艺。 一陣腳步聲響...
    開封第一講書人閱讀 33,150評論 1贊 272
  • 情欲美人皮
    我被黑心中介騙來泰國打工车海， 沒想到剛下飛機(jī)就差點兒被人妖公主榨干…… 1. 我叫王不留侍芝，地道東北人州叠。 一個月前我還...
    沈念sama閱讀 48,415評論 3贊 373
  • 代替公主和親
    正文 我出身青樓凶赁，卻偏偏與公主長得像虱肄，于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子斟或，可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 45,092評論 2贊 355

推薦閱讀更多精彩內(nèi)容