張三李四手摸手教你 HTTPS 的原理（通俗易懂！）

作者：DBCdouble 

原文：https://juejin.cn/post/6872276748570984455

一、前言

一開(kāi)始去真正接觸HTTPS是由于在上線小程序的時(shí)候，小程序官方限定接口必須需是https協(xié)議，后面就去弄了騰訊云的云服務(wù)器，還有免費(fèi)的https證書(shū)等，跟著官方的教程去配置https等等，讓我知道：

• https默認(rèn)端口號(hào)是443
• https協(xié)議比http協(xié)議更加安全
• 需要將CA機(jī)構(gòu)頒布的https證書(shū)安裝在服務(wù)器上
• nginx服務(wù)的一些配置（轉(zhuǎn)發(fā)、入口文件html、gzip壓縮）

最終，小程序也完美上線，但是好像我對(duì)HTTPS的底層原理和流程還是不清楚。下面先通過(guò)李四給張三發(fā)消息的例子先來(lái)說(shuō)明HTTPS相對(duì)HTTP做了哪些工作

二、使用HTTP協(xié)議時(shí)

先看下面一個(gè)例子（需要掌握非對(duì)稱加密的概念），李四想要給張三發(fā)消息：

李四：
“hi哥們，我想給你發(fā)個(gè)密文，把你的公鑰給我發(fā)過(guò)來(lái)用用?！?br>
張三：
“沒(méi)問(wèn)題的，這是我的公鑰：d#8yHE8eU#hb*!neb，用這個(gè)公鑰加密你的信息后給我發(fā)過(guò)來(lái)吧”

李四：
“這是我想對(duì)你說(shuō)的話：*&#@uehuu(**#eehu&$##bfeu&&”

分析：上面是一個(gè)典型的非對(duì)稱加密的案例，張三把自己的公鑰給了李四，李四拿到張三的公鑰把自己的消息加密發(fā)送給張三，張三收到密文用自己的私鑰解密

提問(wèn)：有朋友會(huì)問(wèn)，李四怎么確認(rèn)對(duì)方是張三的？因?yàn)楹苡锌赡?，李四發(fā)給張三的消息被黑客小劉攔截了（如本地host文件被修改，dns攔截），也就是說(shuō)李四拿到的公鑰是黑客小劉的公鑰，那么李四發(fā)過(guò)去的密文，黑客小劉就能用自己的私鑰去解密了

結(jié)論：HTTP協(xié)議之所以不安全是因?yàn)檎?qǐng)求發(fā)起方無(wú)法確認(rèn)響應(yīng)方的真實(shí)身份

三、使用HTTPS協(xié)議時(shí)

接著上面一個(gè)例子：

黑客小劉：四兒，最近有什么新計(jì)劃沒(méi)？。
李四：沒(méi)。。。有。。。。
黑客小劉：沒(méi)有？我是你三哥，你說(shuō)吧。
李四：那你先把你的證書(shū)給我看看？
黑客小劉：....神馬證...書(shū)..？
--- 李四已下線 ---

分析：原來(lái)，李四自從上次被坑了之后私下里去找了一個(gè)叫“王五”的大哥，想尋求幫助，王五說(shuō)這個(gè)事不難，王五對(duì)李四說(shuō)：“如果你相信我，那么我就來(lái)作證人證明張三是張三”。

李四說(shuō)：“那沒(méi)問(wèn)題，那你怎么證明張三是他本人？”。

“我可以給張三頒發(fā)一個(gè)證書(shū)！只要他給你看到這個(gè)電子證書(shū)，證書(shū)上有我的的電子簽名，你就相信他是張三”，王五說(shuō)。

李四思考了片刻又問(wèn)道：“那我怎么證明這個(gè)證書(shū)不是偽造的呢？”

王五說(shuō)：“因?yàn)槲铱梢越o你一個(gè)神器，這個(gè)神器能夠讓你分辨這個(gè)證書(shū)確實(shí)是我頒發(fā)的！”。

“哇！這么吊！那快給我！”，李四渴望的眼神中又閃爍著對(duì)王五的崇拜！

其實(shí)，這個(gè)神奇呢，很簡(jiǎn)單，你想到了嗎？嗯，于是，王五就把這個(gè)神器交給了李四，這個(gè)神器是：“王五的公鑰”！。

哈哈哈哈哈哈。。。

結(jié)論：

• 以上這種方式就是https的授信機(jī)制，加入第三方公證人來(lái)證明身份
• 王五就相當(dāng)于頒發(fā)https證書(shū)的CA機(jī)構(gòu)（類似于授信的公證處）
• 李四持有的王五的公鑰就是個(gè)根證書(shū)，用于驗(yàn)證張三的證書(shū)是否是否合法，是否是王五頒發(fā)
• 電子證書(shū)上的電子簽名，是使用王五使用自己的私鑰將張三的公鑰和個(gè)人信息加密得到的，所以李四使用張三的公鑰去解密張三的電子證書(shū)上的電子簽名得到張三的公鑰，和張三傳過(guò)來(lái)的公鑰作對(duì)比，確認(rèn)張三的身份

詳細(xì)看圖解，如下：

四、HTTPS的實(shí)現(xiàn)原理

大家可能都聽(tīng)說(shuō)過(guò) HTTPS 協(xié)議之所以是安全的是因?yàn)?HTTPS 協(xié)議會(huì)對(duì)傳輸?shù)臄?shù)據(jù)進(jìn)行加密，而加密過(guò)程是使用了非對(duì)稱加密實(shí)現(xiàn)。但其實(shí)，HTTPS 在內(nèi)容傳輸?shù)募用苌鲜褂玫氖菍?duì)稱加密，非對(duì)稱加密只作用在證書(shū)驗(yàn)證階段。

HTTPS的整體過(guò)程分為證書(shū)驗(yàn)證和數(shù)據(jù)傳輸階段，具體的交互過(guò)程如下：

① 證書(shū)驗(yàn)證階段

1. 瀏覽器發(fā)起 HTTPS 請(qǐng)求
2. 服務(wù)端返回 HTTPS 證書(shū)
3. 客戶端驗(yàn)證證書(shū)是否合法，如果不合法則提示告警

② 數(shù)據(jù)傳輸階段

1. 當(dāng)證書(shū)驗(yàn)證合法后，在本地生成隨機(jī)數(shù)
2. 通過(guò)公鑰加密隨機(jī)數(shù)，并把加密后的隨機(jī)數(shù)傳輸?shù)椒?wù)端
3. 服務(wù)端通過(guò)私鑰對(duì)隨機(jī)數(shù)進(jìn)行解密
4. 服務(wù)端通過(guò)客戶端傳入的隨機(jī)數(shù)構(gòu)造對(duì)稱加密算法，對(duì)返回結(jié)果內(nèi)容進(jìn)行加密后傳輸

為什么數(shù)據(jù)傳輸是用對(duì)稱加密？

首先，非對(duì)稱加密的加解密效率是非常低的，而 http 的應(yīng)用場(chǎng)景中通常端與端之間存在大量的交互，非對(duì)稱加密的效率是無(wú)法接受的；

另外，在 HTTPS 的場(chǎng)景中只有服務(wù)端保存了私鑰，一對(duì)公私鑰只能實(shí)現(xiàn)單向的加解密，所以 HTTPS 中內(nèi)容傳輸加密采取的是對(duì)稱加密，而不是非對(duì)稱加密。

五、從網(wǎng)絡(luò)模型來(lái)認(rèn)識(shí)HTTPS

網(wǎng)絡(luò)模型一般是指OSI七層參考模型和TCP/IP五層模型的協(xié)議，這個(gè)模型是干嘛的呢？就是將計(jì)算機(jī)和計(jì)算機(jī)之間信息交換“概念化”成不同的層次，每層分別有它自己的“實(shí)現(xiàn)”，每層有它自己的任務(wù)，同時(shí)“向上”提供“抽象”的“接口”供上層使用。一般分成7層或者5層。為了簡(jiǎn)便期間我這里按照5層架構(gòu)說(shuō)一下，這五層分別是：

• 應(yīng)用層(application layer)
• 傳輸層(transport layer)
• 網(wǎng)絡(luò)層(network layer)
• 數(shù)據(jù)鏈路層(data link layer)
• 物理層(physical layer)

舉個(gè)例子，當(dāng)張三用QQ向李四發(fā)送一條信息時(shí)，首先QQ屬于應(yīng)用層，應(yīng)用層需要將信息發(fā)送給傳輸層，傳輸層經(jīng)過(guò)處理之后傳給網(wǎng)絡(luò)層，以此類推傳給物理層，這樣一層層向下“包裝”，每層有對(duì)應(yīng)的協(xié)議，這樣最后通過(guò)物理層傳出去，傳到李四的物理層，然后李四那邊通過(guò)一層層向上按照協(xié)議“解包”，最后到應(yīng)用層，傳到李四的qq里。

所以每層都有相對(duì)應(yīng)的協(xié)議比如我們的物理層和數(shù)據(jù)鏈路層通過(guò)無(wú)線網(wǎng)傳輸使用的802.2傳輸協(xié)議，有線網(wǎng)的Ethernet(以太網(wǎng))傳輸協(xié)議，還有網(wǎng)絡(luò)層的IPv4, IPv6協(xié)議，傳輸層的TCP, UDP協(xié)議，而我們熟悉的HTTP協(xié)議其實(shí)屬于應(yīng)用層，所以HTTP是建立在TCP/IPv4或v6/以太網(wǎng)基礎(chǔ)上進(jìn)一步細(xì)化用于傳輸“超文本”信息的協(xié)議，比如FTP也屬于應(yīng)用層，也是在下面各層協(xié)議基礎(chǔ)上進(jìn)行細(xì)化，專門(mén)用于“文件傳輸”的協(xié)議。

大家可以看到，協(xié)議越往上越具體，越往下約抽象，其實(shí)計(jì)算機(jī)技術(shù)的發(fā)展就是一層層的向上抽象，這樣上層的可以直接使用下層的“成果”(API)！

我們?cè)賮?lái)說(shuō)一下TLS/SSL，SSL(secure sockets layer)是TLS(transport layer security)的前身，為什么將他們合起來(lái)的，大家可以理解成都屬于同一東西的不同階段吧，比如該協(xié)議之前叫SSL后來(lái)改名成TLS了。

為什么要有這種協(xié)議呢？因?yàn)镠TTP是使用明文傳輸，隨著網(wǎng)絡(luò)的發(fā)展，安全性越來(lái)越重要，所以大家就要想辦法讓傳輸更加安全，同時(shí)使用密碼學(xué)的成果，利用“非對(duì)稱加密算法”的思想以及OSI模型，來(lái)對(duì)HTTP的信息進(jìn)行加密。

因?yàn)樯厦嫖覀冋f(shuō)了，根據(jù)OSI模型，如果向外傳輸信息就是要從上到下挨個(gè)層進(jìn)行，TLS/SSL也是位于應(yīng)用層，所以為了加密HTTP的內(nèi)容，那么TLS/SSL必須位于HTTP下面，可以看成這樣：

HTTP
TLS/SSL
TCP
Ip
..

信息從HTTP經(jīng)過(guò)TLS/SSL非對(duì)稱加密后傳出去，而在接收方，接收到信息是需要一層層向上進(jìn)行，經(jīng)過(guò)每層的“解包/解密”，最終通過(guò)HTTP轉(zhuǎn)換成超文本信息。

結(jié)論

• 從網(wǎng)絡(luò)協(xié)議上來(lái)說(shuō)，HTTPS = HTTP + TLS/SSL
• 從功能上來(lái)說(shuō)，HTTPS = HTTP + 非對(duì)稱加密的證書(shū)身份驗(yàn)證 + 對(duì)稱加密的傳輸信息加密