1、概述

網際網路上進行的任何活動（閱讀本文，朋友圈上傳圖片，在淘寶上買東西）都可以歸結為向伺服器傳送訊息和從伺服器接收訊息。而兩者之間傳遞訊息就需要遵守一些協議，不然的話就如同雞同鴨講，根本沒法進行溝通。其中在應用層用的最多的就是HTTP協議（HyperText Transfer Protocol，超文字傳輸協議）。而HTTP協議傳輸的資料沒有進行過任何加密操作，基本上就相當於在網上裸奔。於是在HTTP協議的基礎上，出了一個HTTPS協議（HyperText Transfer Protocol over Secure Socket Layer）。可以理解為HTTP+SSL/TLS， 即 HTTP 下加入 SSL 層，HTTPS 的安全基礎是 SSL/TLS，加密的處理就需要 SSL/TLS，用於安全的 HTTP 資料傳輸。

2、類比解釋HTTPS原理及誕生過程

2.1 開始天真的溝通

我們這邊有一群小甲和一個小乙，小甲們是小乙的粉絲，而當時只能通過飛鴿傳書來傳遞小甲們對小乙的喜愛之情。一開始是這樣的，每次小甲們想要想給小乙傳信件的時候，就把信件綁在信鴿腿上，通過信鴿飛到小乙那邊，小乙從信鴿腿上去下信件讀取訊息，然後根據信件裡的發件人和地址用同樣的方式回信件給小甲們。

直到有一天，有個叫小壞的人，在信鴿飛行的途中，把信鴿攔截了下來，偷偷看了裡面的信件，甚至還修改了信件裡面的內容，再把信鴿放走讓它繼續往目的地飛過去。這個操作有天被小甲們和小乙知道了，他們就不樂意了，感覺自己的隱私受到了侵犯。

2.2 加密

於是小甲們和小乙就決定用密碼寫他們的資訊，他們將每個字母在字母表中移動3個位置。例如，D→A，E→B，F→C。訊息“secret message”將是“pbzobq jbppxdb”。現在如果小壞就算攔截了鴿子，也看不懂裡面的內容了。

可是好景不長，有個小甲有一天說漏了嘴，讓小壞知道了加密規則，小壞按照規則，就可以反推出真實的訊息。

這時候小甲們和小乙決定，每個小甲每一串互發信件的過程，都和小乙重新商討一遍加密規則。這樣就算小壞知道了其中一個小甲這串信件的規則，頂多也就能破解這個小甲和小乙這串信件，對於其他小甲們和其他信件串就無法破解了。

但問題又出現了，小甲和小乙都不在一個地方，商討規則也只能通過飛鴿傳書，如果每次在商討規則的時候鴿子被小壞截下來了，那豈不是又就要被小壞知道祕密了。

2.3 飛鴿帶箱子

為了解決上面一個問題，小甲們和小乙提供了一個更好的方案。當小甲想要給小乙傳送封信件的時，會按照下面的步驟進行操作：

① 小甲傳送一封沒有內容的信件通過鴿子給小乙。

② 小乙把鴿子帶回家，給鴿子綁上一個開著帶鎖的箱子，自己儲存著開鎖的鑰匙。

③ 小甲拿到箱子，把信放在箱子裡面，合上箱子，通過鴿子給小乙

④ 小乙拿到箱子，通過鑰匙開啟箱子，讀取信件。

這樣小壞就算攔截了鴿子，沒有鑰匙也打不開箱子，也就無法讀取裡面的信件了。這樣一來問題看似就解決了，但是還出來了一個新的問題，如果小壞偽裝成小乙，在小乙給小甲箱子的時候把鴿子攔截下來，換上一個新的鑰匙在小壞手裡的箱子。那之後小甲把信件放在這個箱子裡，傳給小乙時候，小壞再攔下這個鴿子，開啟箱子，讀取修改信件，再把信件放到小乙給的那個箱子裡。那不就又被小壞得逞了。

2.4 確認箱子是真的

為了解決上面一個問題，小乙決定給自己的箱子簽上名。這樣當小甲收到箱子時候檢查一下這個簽名是不是小乙的簽名，這樣就可以判斷中途箱子有沒有被小壞掉包了。但是小甲如何判斷小乙的簽名的真假呢？這時候小甲和小乙就找到了一批德高望重的長者。長者給了小乙一個含有小乙名字的印章，每次傳箱子時候，在箱子上蓋一個這個印章。同時德高望重的長者承諾給人頒發印章時候，只會給人發這個人自己名字的印章，而不會給他發別人名字的印章。小甲拿到箱子時候，看到印章裡面的名字是小乙，再去問一下長者，這個印子是真印子沒錯吧。得到長者的肯定答覆後，就可以確定這個箱子是小乙傳來的那個箱子了。到此似乎小壞已經沒有空子可以鑽了。但還有一個問題，那就是，如果小乙小給小甲回訊息，似乎也要有這麼一個傳箱子的費勁事情。而且箱子真的很重，鴿子不想一直帶著箱子來回跑。

2.5 箱子太重

雖然前面的一頓操作已經讓小壞沒有機會了。但是箱子真的太重了，影響了鴿子的飛行速度。於是小甲們和小乙決定，小甲只在箱子裡面放加密規則。一旦小乙收到加密規則後，之後的通訊就按照前面所說的加密方式進行通訊。因為已經通過箱子印章操作解決了在商討規則時候被小壞攔截下來的問題。

到此整個小甲們和小乙通訊的過程就得到了很好的保密，同時也儘可能的減少了鴿子的壓力。

3、HTTPS原理解釋

其實HTTPS的操作就如同前面所說，接下來從專業的角度解釋一下前面所說的小甲們小乙長者箱子等個代表什麼意思，同時再串一遍HTTPS的通訊過程。

小甲們：客戶端

小乙：服務端

小壞：黑客

商討規則的加密方式：對稱加密

箱子和鑰匙：非對稱加密裡的公鑰和私鑰

長者們：證書頒發機構CA，如Symantec、Comodo、GoDaddy、GlobalSign等。

長者給小乙印章：如果需要採用HTTPS協議服務端需要向CA申請認證證書。

箱子太重：非對稱加密要比對稱加密複雜，加解密過程更加耗費時間。

而整個HTTPS通訊步驟大致如下：

① 客戶端傳送一個空訊息給服務端

② 服務端將包含有非對稱加密公鑰和CA認證證書的伺服器證書傳給客戶端

③ 客戶端根據放在本地庫裡面的CA證書列表判斷傳來的CA認證證書是否是有效的

④ 客戶端隨機生成對稱加密公鑰，並將這個對稱加密公鑰用從伺服器傳來的非對稱加密公鑰加密，發給服務端。

⑤ 服務端收到用非對稱加密公鑰加密過的資料，通過非對稱加密的私鑰解密，獲取裡面的對稱加密公鑰。

⑥ 服務端和客戶端用對稱加密公鑰對訊息進行加密後互相傳送通訊。

4、SSL/TSL

根據前面所述，已經大致走通了HTTPS的通訊流程，這邊再對服務端（小乙）如何CA機構（長者們）申請認證證書（印章），以及客戶端（小甲們）如何向驗證證書進行一下說明。這層驗證是基於網路層裡面SSL/TSL層進行的。

CA即證書授權中心( certificate authority)，這些機構受國際認可。他會對他受信任的申請物件頒發相應的證書server.crt，同時他可以隨時吊銷申請物件的證書。而客戶端的本地一般會儲存有ca.crt，可以來驗證server.crt的正確性。要看本地的ca.crt對於chrome瀏覽器可以通過：設定 -> 高階 -> 管理證書 -> 授權中心 檢視。服務端想申請server.crt，需要先生成一對server.pub/server.key（傳信件的帶鎖箱子和解鎖鑰匙），然後將組織資訊，個人資訊（域名等）和server.pub（帶鎖箱子）一起打包成一個server.req即申請認證檔案給CA認證機構。CA認證機構通過線上、線下等多種手段驗證申請者提供資訊的真實性，如組織是否存在、企業是否合法，是否擁有域名的所有權等。如果一切合法，就向申請者簽發認證檔案證書。證書裡面包含如下資訊：申請者公鑰（帶鎖箱子）、申請者的組織資訊和個人資訊、簽發機構 CA的資訊、有效時間、證書序列號等明文資訊，同時包含一個簽名。最後一個簽名很關鍵，它是通過如下演算法生成的：首先，使用雜湊函式計算明文資訊的資訊摘要。然後用 CA的私鑰（ca.key）對資訊摘要進行加密，密文就是這個簽名。而這個簽名的解密公鑰就是前面說的放在本地的ca.crt。每當客戶端向服務端發起請求，服務端需要返回證書檔案。客戶端讀取證書中的明文資訊，採用同樣的雜湊函式計算得到資訊摘要。然後利用對應CA機構的ca.crt去解密簽名。如果計算的資訊摘要和解密出來的簽名一致，代表這個資訊沒有被篡改過，是可信的資訊。也就是說資訊裡面的公鑰（帶鎖箱子）合法，客戶端然後會驗證證書相關的域名資訊、有效時間、是否吊銷等資訊。 一切通過了，這時候就可以用證書明文資訊裡面的公鑰（帶鎖箱子）進行加密客戶端隨機生成的對稱加密的公鑰了。整個流程如下圖：

Tips：從上面的表述可以看到，公鑰可以用來加密也可以用來解密，私鑰也是一樣。兩者的區別在於私鑰只有建立者知道，公鑰是傳出去給需要的人用的。公鑰加密的資訊只有對應私鑰能解密讀取，私鑰加密的資訊只有對應公鑰能解密讀取。CA就是用自己的私鑰（ca.key）對證書加密，用公鑰（ca.crt）對證書解密。而服務端是用公鑰（帶鎖箱子）來對資訊進行加密，用私鑰（解鎖鑰匙）來對資訊進行解密的。這種是一對公私鑰的加密方式指非對稱加密。客戶端隨機生成的一對都是公鑰的加密方式指對稱加密，這種被公鑰加密過的資訊，所有公鑰都能解密出來。