1HTTP 協(xié)議簡介

????? 面試官：你先簡單介紹一下 HTTP 協(xié)議 吧!

????? 大白：HTTP 協(xié)議，全稱超文本傳輸協(xié)議(Hypertext Transfer Protocol)。顧名思義，HTTP 協(xié)議就是用來規(guī)范超文本的傳輸，超文本，也就是網(wǎng)絡上的包括文本在內(nèi)的各式各樣的消，具體來說，主要是來規(guī)范瀏覽器和服務器端的行為的。另外，HTTP 是一個無狀態(tài)(stateless)協(xié)議。

????? 面試官：無狀態(tài)協(xié)議這個如何理解?

????? 大白：也就是說服務器不維護任何有關(guān)客戶端過去所發(fā)請求的消息。這其實是一種懶政，有狀態(tài)協(xié)議會更加復雜，需要維護狀態(tài)(歷史信息)，而且如果客戶或服務器失效，會產(chǎn)生狀態(tài)的不一致，解決這種不一致的代價更高。

????? 面試官：HTTP 協(xié)議有哪些優(yōu)點?

????? 大白：HTTP 的主要優(yōu)點有：擴展性強、速度快、跨平臺支持性好。

????? 面試官：HTTP 屬于哪一層的協(xié)議啊?

????? 大白：HTTP 是應用層協(xié)議，他以 TCP(傳輸層)作為底層協(xié)議，默認端口為 80.

????? 面試官：HTTP 通信過程能簡單介紹一下不?

????? 大白：HTTP 通信過程主要如下：

• 服務器在 80 端口等待客戶的請求
• 瀏覽器發(fā)起到服務器的 TCP 連接(創(chuàng)建套接字 Socket)
• 服務器接收來自瀏覽器的 TCP 連接
• 瀏覽器(HTTP 客戶端)與 Web 服務器(HTTP 服務器)交換 HTTP 消息
• 關(guān)閉 TCP 連接

2HTTPS 協(xié)議簡介

????? 面試官：簡單介紹一下 HTTPS 協(xié)議吧!

????? 大白：HTTPS 協(xié)議(Hyper Text Transfer Protocol Secure)，是 HTTP 的加強安全版本。HTTPS 是基于 HTTP 的，也是用 TCP 作為底層協(xié)議，并額外使用 SSL/TLS 協(xié)議用作加密和安全認證。默認端口號是 443. HTTPS 協(xié)議中，SSL 通道通常使用基于密鑰的加密算法，密鑰長度通常是 40 比特或 128 比特。

????? 面試官：HTTPS 協(xié)議有哪些優(yōu)點?

????? 大白：HTTPS 的主要優(yōu)點有：保密性好、信任度高。正因為在不同的需求場景下 HTTP 和 HTTPS 各有優(yōu)點，即便是 HTTPS 彌補了 HTTP 前輩保密性差的缺陷，HTTP 也仍然占據(jù)著互聯(lián)網(wǎng)的主流，和 HTTPS 各司其職。事實上，現(xiàn)在一些健壯性比較好的站點，同時具備了 HTTP 和 HTTPS，當訪問 http 前綴的某網(wǎng)站時，會自動跳轉(zhuǎn)到 https 上，已實現(xiàn)高保密性、高信任的要求。

3HTTPS 的核心協(xié)議——SSL/TLS

HTTPS 之所以能達到較高的安全性要求，就是結(jié)合了 SSL/TLS 和 TCP 協(xié)議，對通信數(shù)據(jù)進行加密，解決了 HTTP 數(shù)據(jù)透明的問題。接下來重點介紹一下 SSL/TLS 的工作原理。

????? 面試官：SSL 和 TLS 的區(qū)別?

????? 大白：SSL 和 TLS 沒有太大的區(qū)別。SSL 指安全套接字協(xié)議(Secure Sockets Layer)，首次發(fā)布與 1996 年。SSL 的首次發(fā)布其實已經(jīng)是他的 3.0 版本，SSL 1.0 從未面世，SSL 2.0 則具有較大的缺陷(DROWN 缺陷——Decrypting RSA with Obsolete and Weakened eNcryption)。很快，在 1999 年，SSL 3.0 進一步升級，新版本被命名為 TLS 1.0。因此，TLS 是基于 SSL 之上的，但由于習慣叫法，通常把 HTTPS 中的核心加密協(xié)議混成為 SSL/TLS。

非對稱加密

????? 面試官：SSL/TLS 的核心要素是非對稱加密，簡單介紹一下吧!

????? 大白：非對稱加密采用兩個密鑰——一個公鑰，一個私鑰。在通信時，私鑰僅由解密者保存，公鑰由任何一個想與解密者通信的發(fā)送者(加密者)所知?？梢栽O想一個場景，

在某個自助郵局，每個通信信道都是一個郵箱，每一個郵箱所有者都在旁邊立了一個牌子，上面掛著一把鑰匙：這是我的公鑰，發(fā)送者請將信件放入我的郵箱，并用公鑰鎖好。

但是公鑰只能加鎖，并不能解鎖。解鎖只能由郵箱的所有者——因為只有他保存著私鑰。

這樣，通信信息就不會被其他人截獲了，這依賴于私鑰的保密性。

非對稱加密的公鑰和私鑰需要采用一種復雜的數(shù)學機制生成(密碼學認為，為了較高的安全性，盡量不要自己創(chuàng)造加密方案)。公私鑰對的生成算法依賴于單向陷門函數(shù)。

單向函數(shù)：已知單向函數(shù) f，給定任意一個輸入 x，易計算輸出 y=f(x);而給定一個輸出 y，假設存在 f(x)=y，很難根據(jù) f 來計算出 x。

單向陷門函數(shù)：一個較弱的單向函數(shù)。已知單向陷門函數(shù) f，陷門 h，給定任意一個輸入 x，易計算出輸出 y=f(x;h);而給定一個輸出 y，假設存在 f(x;h)=y，很難根據(jù) f 來計算出 x，但可以根據(jù) f 和 h 來推導出 x。

單向函數(shù)

上圖就是一個單向函數(shù)(不是單項陷門函數(shù))，假設有一個絕世秘籍，任何知道了這個秘籍的人都可以把蘋果汁榨成蘋果，那么這個秘籍就是“陷門”了吧。

在這里，函數(shù) f 的計算方法相當于公鑰，陷門 h 相當于私鑰。公鑰 f 是公開的，任何人對已有輸入，都可以用 f 加密，而要想根據(jù)加密信息還原出原信息，必須要有私鑰才行。

對稱加密

????? 面試官 ：使用 SSL/TLS 進行通信的雙方需要使用非對稱加密方案來通信，但是非對稱加密設計了較為復雜的數(shù)學算法，在實際通信過程中，計算的代價較高，效率太低，因此，SSL/TLS 實際對消息的加密使用的是對稱加密。

????? 面試官 ：簡單介紹一下對稱加密吧!

????? 大白：對稱加密中，通信雙方共享唯一密鑰 k，加解密算法已知，加密方利用密鑰 k 加密，解密方利用密鑰 k 解密，保密性依賴于密鑰 k 的保密性。

對稱加密的密鑰生成代價比公私鑰對的生成代價低得多，那么有的人會問了，為什么 SSL/TLS 還需要使用非對稱加密呢?因為對稱加密的保密性完全依賴于密鑰的保密性。在雙方通信之前，需要商量一個用于對稱加密的密鑰。我們知道網(wǎng)絡通信的信道是不安全的，傳輸報文對任何人是可見的，密鑰的交換肯定不能直接在網(wǎng)絡信道中傳輸。因此，使用非對稱加密，對對稱加密的密鑰進行加密，保護該密鑰不在網(wǎng)絡信道中被竊聽。這樣，通信雙方只需要一次非對稱加密，交換對稱加密的密鑰，在之后的信息通信中，使用絕對安全的密鑰，對信息進行對稱加密，即可保證傳輸消息的保密性。

公鑰傳輸?shù)男刨囆?/h3>

????? 面試官 ：這樣會不會有什么安全隱患呢?

????? 大白：當然!設想一個下面的場景：

客戶端 C 和服務器 S 想要使用 SSL/TLS 通信，由上述 SSL/TLS 通信原理，C 需要先知道 S 的公鑰，而 S 公鑰的唯一獲取途徑，就是把 S 公鑰在網(wǎng)絡信道中傳輸。要注意網(wǎng)絡信道通信中有幾個前提：

任何人都可以捕獲通信包

通信包的保密性由發(fā)送者設計

保密算法設計方案默認為公開，而(解密)密鑰默認是安全的

因此，假設 S 公鑰不做加密，在信道中傳輸，那么很有可能存在一個攻擊者 A，發(fā)送給 C 一個詐包，假裝是 S 公鑰，其實是誘餌服務器 AS 的公鑰。當 C 收獲了 AS 的公鑰(卻以為是 S 的公鑰)，C 后續(xù)就會使用 AS 公鑰對數(shù)據(jù)進行加密，并在公開信道傳輸，那么 A 將捕獲這些加密包，用 AS 的私鑰解密，就截獲了 C 本要給 S 發(fā)送的內(nèi)容，而 C 和 S 二人全然不知。

同樣的，S 公鑰即使做加密，也難以避免這種信任性問題，C 被 AS 拐跑了!

為了公鑰傳輸?shù)男刨囆詥栴}，第三方機構(gòu)應運而生——證書頒發(fā)機構(gòu)(CA，Certificate Authority)。CA 默認是受信任的第三方。CA 會給各個服務器頒發(fā)證書，證書存儲在服務器上，并附有 CA 的電子簽名(見下節(jié))。

當客戶端(瀏覽器)向服務器發(fā)送 HTTPS 請求時，一定要先獲取目標服務器的證書，并根據(jù)證書上的信息，檢驗證書的合法性。一旦客戶端檢測到證書非法，就會發(fā)生錯誤?？蛻舳双@取了服務器的證書后，由于證書的信任性是由第三方信賴機構(gòu)認證的，而證書上又包含著服務器的公鑰信息，客戶端就可以放心的信任證書上的公鑰就是目標服務器的公鑰。

數(shù)字簽名

????? 面試官 ：上面提到了數(shù)字簽名，能簡單介紹一下數(shù)字簽名解決的問題么?

????? 大白：數(shù)字簽名要解決的問題，是防止證書被偽造。第三方信賴機構(gòu) CA 之所以能被信賴，就是靠數(shù)字簽名技術(shù)。

數(shù)字簽名，是 CA 在給服務器頒發(fā)證書時，使用散列+加密的組合技術(shù)，在證書上蓋個章，以此來提供驗偽的功能。具體行為如下：

CA 知道服務器的公鑰，對該公鑰采用散列技術(shù)生成一個摘要。CA 使用 CA 私鑰對該摘要進行加密，并附在證書下方，發(fā)送給服務器。

現(xiàn)在服務器將該證書發(fā)送給客戶端，客戶端需要驗證該證書的身份。客戶端找到第三方機構(gòu) CA，獲知 CA 的公鑰，并用 CA 公鑰對證書的簽名進行解密，獲得了 CA 生成的摘要。

客戶端對證書數(shù)據(jù)(也就是服務器的公鑰)做相同的散列處理，得到摘要，并將該摘要與之前從簽名中解碼出的摘要做對比，如果相同，則身份驗證成功;否則驗證失敗。

注意，驗證身份的證書一定是由 CA 的公鑰進行簽名，而不能由發(fā)送者自己來簽名。這是為了抵抗以下的攻擊場景：

攻擊者使用某種手段，欺騙了客戶端，將服務器的公鑰替換為攻擊者的誘餌公鑰。

假使證書的簽名使用的是服務器的私鑰，那么客戶端在解碼的時候，將會使用假的服務器公鑰(實則為誘餌公鑰)。那么，如果該證書實則由攻擊者(使用自己的私鑰簽名)發(fā)出，那么客戶端就會成功驗證(攻擊者的)身份為真，從而信賴了證書中的公鑰。

如果使用 CA 的私鑰和公鑰來對簽名處理，則不會出現(xiàn)上述問題。

總結(jié)來說，帶有證書的公鑰傳輸機制如下：

• 設有服務器 S，客戶端 C，和第三方信賴機構(gòu) CA。
• S 信任 CA，CA 是知道 S 公鑰的，S 向 CA 頒發(fā)證書。并附上 CA 私鑰對消息摘要的加密簽名。
• S 獲得 CA 頒發(fā)的證書，將該證書傳遞給 C。
• C 獲得 S 的證書，信任 CA 并知曉 CA 公鑰，使用 CA 公鑰對 S 證書山的簽名解密，同時對消息進行散列處理，得到摘要。比較摘要，驗證 S 證書的真實性。
• 如果 C 驗證 S 證書是真實的，則信任 S 的公鑰(在 S 證書中)。

4HTTP 和 HTTPS 的區(qū)別

????? 面試官：最后總結(jié)一下 HTTP 和 HTTPS 的區(qū)別吧!

????? 大白：為了幫助區(qū)分 HTTP 和 HTTPS 的區(qū)別，我專門匯總了一張表格：