Q1: 什么是 HTTPS？

BS: HTTPS 是安全的 HTTP

HTTP 協議中的內容都是明文傳輸酗捌，HTTPS 的目的是將這些內容加密呢诬，確保信息傳輸安全。最后一個字母 S 指的是 SSL/TLS 協議胖缤，它位于 HTTP 協議與 TCP/IP 協議中間尚镰。

Q2: 你說的信息傳輸安全是什么意思

BS: 信息傳輸的安全有三個方面:

1. 客戶端和服務器直接的通信只有自己能看懂，即使第三方拿到數據也看不懂這些信息的真實含義哪廓。
2. 第三方雖然看不懂數據狗唉，但可以 XJB 改，因此客戶端和服務器必須有能力判斷數據是否被修改過涡真。
3. 客戶端必須避免中間人攻擊分俯，即除了真正的服務器肾筐，任何第三方都無法冒充服務器。

很遺憾的是缸剪，目前的 HTTP 協議還不滿足上述三條要求中的任何一條吗铐。

Q3: 這么多要求，一個一個去滿足是不是很累杏节？

BS: 不累唬渗，第三個要求可以不用管

是的，我沒開玩笑拢锹，你可以暫時別管第三個要求谣妻，因為它實際上隸屬于第一個需求萄喳。我們都知道加密需要密碼卒稳，密碼不是天下掉下來，也得需要雙方經過通信才能協商出來他巨。所以一個設計良好的加密機制必然會防止第三者的干擾和偽造充坑。等搞明白了加密的具體原理，我們自然可以檢驗是否滿足:“任何第三者無法冒充服務器”這一要求染突。

Q4: 那怎么加密信息呢

BS: 使用對稱加密技術

對稱加密可以理解為對原始數據的可逆變換捻爷。比如 Hello 可以變換成 Ifmmp，規(guī)則就是每個字母變成它在字母表上的后一個字母份企，這里的秘鑰就是 1也榄，另一方拿到 Ifmmp 就可以還原成原來的信息 Hello 了。

引入對稱加密后司志，HTTPS 的握手流程就會多了兩步甜紫，用來傳遞對稱加密的秘鑰:

1. 客戶端: 你好，我需要發(fā)起一個 HTTPS 請求
2. 服務器: 好的骂远，你的秘鑰是 1囚霸。

提到了對稱加密，那么自然還有非對稱加密激才。它的思想很簡單拓型，計算兩個質數的乘積很容易，但反過來分解成兩個質數的乘積就很難瘸恼，要經過極為復雜的運算劣挫。非對稱加密有兩個秘鑰，一個是公鑰东帅，一個是私鑰。公鑰加密的內容只有私鑰可以解密冰啃，私鑰加密的內容只有公鑰可以解密邓夕。一般我們把服務器自己留著刘莹，不對外公布的密鑰稱為私鑰，所有人都可以獲取的稱為公鑰焚刚。

使用對稱加密一般要比非對稱加密快得多点弯，對服務器的運算壓力也小得多。

Q5: 對稱秘鑰如何傳輸

服務器直接返回明文的對稱加密密鑰是不是不安全矿咕。如果有監(jiān)聽者拿到這個密鑰抢肛，不就知道客戶端和服務器后續(xù)的通信內容了么？

BS: 利用非對稱加密

是這樣碳柱，所以不能明文傳遞對稱秘鑰捡絮，而且也不能用一個新的對稱加密算法來加密原來的對稱秘鑰，否則新的對稱秘鑰同樣無法傳輸莲镣，這就是雞生蛋福稳、蛋生雞的悖論。

這里我們引入非對稱加密的方式瑞侮，非對稱加密的特性決定了服務器用私鑰加密的內容并不是真正的加密搬味，因為公鑰所有人都有忌卤，所以服務器的密文能被所有人解析。但私鑰只掌握在服務器手上，這就帶來了兩個巨大的優(yōu)勢:

1. 服務器下發(fā)的內容不可能被偽造亭螟，因為別人都沒有私鑰吕嘀，所以無法加密宴猾。強行加密的后果是客戶端用公鑰無法解開枢析。
2. 任何人用公鑰加密的內容都是絕對安全的，因為私鑰只有服務器有店归，也就是只有真正的服務器可以看到被加密的原文阎抒。

所以傳輸對稱秘鑰的問題就迎刃而解了: 秘鑰不是由服務器下發(fā)，而是由客戶端生成并且主動告訴服務器娱节。

所以當引入非對稱加密后挠蛉，HTTPS 的握手流程依然是兩步，不過細節(jié)略有變化:

1. 客戶端: 你好肄满，我需要發(fā)起一個 HTTPS 請求谴古，這是我的 (用公鑰加密后的) 秘鑰。
2. 服務器: 好的稠歉，我知道你的秘鑰了掰担，后續(xù)就用它傳輸。

Q5: 那公鑰怎么傳輸

你好像還是沒有解決雞生蛋怒炸，蛋生雞的問題带饱。你說客戶端發(fā)送請求時要用公鑰加密對稱秘鑰，那公鑰怎么傳輸呢？

BS: 對公鑰加密就行了勺疼。教寂。。

每一個使用 HTTPS 的服務器都必須去專門的證書機構注冊一個證書执庐，證書中存儲了用權威機構私鑰加密的公鑰酪耕。這樣客戶端用權威機構的公鑰解密就可以了。

現在 HTTPS 協議的握手階段變成了四步:

1. 客戶端: 你好轨淌，我要發(fā)起一個 HTTPS 請求迂烁，請給我公鑰
2. 服務器: 好的，這是我的證書递鹉，里面有加密后的公鑰
3. 客戶端: 解密成功以后告訴服務器: 這是我的 (用公鑰加密后的) 對稱秘鑰盟步。
4. 服務器: 好的，我知道你的秘鑰了躏结，后續(xù)就用它傳輸却盘。

Q6: 你在逗我么。窜觉。谷炸。北专。

那權威機構的公鑰又怎么傳輸禀挫？

BS: 存在電腦里

這個公鑰不用傳輸，會直接內置在各大操作系統(或者瀏覽器)的出廠設置里拓颓。之所以不把每個服務器的公鑰內置在電腦里语婴，一方面是因為服務器太多，存不過來驶睦。另一方面操作系統也不信任你砰左，憑什么你說你這個就是百度/淘寶的證書呢？

所以各個公司要先去權威機構認證场航，申請證書缠导，然后操作系統只會存儲權威機構的公鑰。因為權威機構數量有限溉痢，所以操作系統廠商相對來說容易管理僻造。如果這個權威機構不夠權威，XJB 發(fā)證書孩饼，就會取消他的資格髓削，比如可憐的沃通。镀娶。立膛。。

Q7: 怎么知道證書有沒有被篡改梯码？

你說服務器第一次會返回證書宝泵，也就是加密以后的公鑰好啰，那我怎么知道這個證書是可靠的？

BS: 將信息 hash 值隨著信息一起傳遞

我們都知道哈希算法的特點儿奶，它可以壓縮數據坎怪，如果從函數角度來看，不管多復雜的數據(定義域可以非常大)經過哈希算法都會得到一個值廓握，而且這個值處在某個特定(遠小于定義域的范圍)值域內搅窿。相同數據的哈希結果一定相同，不相同數據的哈希結果一般不同隙券，不過也有小概率會重復男应，這叫哈希沖突。

為了確保原始證書沒有被篡改娱仔，我們可以在傳遞證書的同時傳遞證書的哈希值沐飘。由于第三者無法解析數據，只能 XJB 改牲迫，那么修改后的數據在解密后耐朴，就不可能通過哈希。

比如說公鑰就是之前的例子 Hello盹憎，我們假設哈希算法是獲取字符串的最后一個字符筛峭，那么 Hello 的哈希值就是 o，所以加密字符串是 Ifmmpp陪每。雖然公鑰已知影晓，每個人都可以解密，解密完也可以篡改檩禾，但是因為沒有私鑰挂签， 所以無法正確的加密。所以它再返回給客戶端的數據是無效數據盼产，用公鑰解析后會得到亂碼饵婆。即使攻擊者通過多次嘗試碰巧能夠解析，也無法通過哈希校驗戏售。

Q8: 這樣可以防止第三方冒充服務器么

BS: 也許可以

首先真正的服務器下發(fā)的內容侨核，無法被別人篡改。他們有權威機構的公鑰蜈项，所以可以解密芹关，但是因為沒有私鑰，所以解密以后的信息無法加密紧卒。沒有加密或者錯誤加密的信息被客戶端用公鑰解密以后侥衬，必然無法通過哈希校驗。

但是，如果你一開始請求的就不是真的服務器轴总，而是一個攻擊者直颅，此時的他完全有機會進行中間人攻擊。我們知道第一次握手的時候服務器會下發(fā)用于證明自己身份的證書怀樟，這個證書會用預設在設備上的公鑰來解密功偿。所以要么是經過認證的證書用權威機構的私鑰加密，再用權威機構解密往堡，要么是用非權威機構的私鑰加密械荷，然后找不到公鑰解密。

所以如果不小心安裝過非權威機構的根證書虑灰，比如黑客提供的惡意證書吨瞎，這時候設備上就多了一個預設的公鑰，那么用惡意私鑰加密的證書就能被正常解析出來穆咐。所以千萬不要隨便裝根證書颤诀，這等于是為那些惡意證書留了一扇門。

當然对湃，凡是都有兩面性崖叫。我們知道 Charles 可以調試 HTTPS 通信，它的原理就是需要用戶安裝 Charles 的根證書拍柒，然后我們的請求會被代理到 Charles 服務器心傀，它下發(fā)的 Charles 證書才能被正確解析。另一方面斤儿，Charles 會作為客戶端剧包，從真正的服務器哪里拿到正確的 https 證書并用于后續(xù)通信恐锦。幸好 Charles 不是流氓軟件往果，或者它的私鑰一旦泄露，對用戶都會造成很大的影響一铅。

我可以舉一個例子陕贮，證書有多個種類，最貴的叫 EV (Extended Validation)潘飘，它需要公司營業(yè)執(zhí)照等多個文件才能申請人工審核肮之，好處也很明顯，可以在瀏覽器地址欄左側準確顯示公司名稱卜录，比如 Bitbucket 的官網:

這是客戶端直連時候的正掣昵埽現象。但如果你用 Charles 代理艰毒，客戶端拿到的是 Charles 證書筐高，所以會變成:

Q9: HTTPS 握手會影響性能么

TCP 有三次握手，再加上 HTTPS 的四次握手，會不會影響性能柑土？

BS: 影響肯定有蜀肘，但是可以接受

首先，HTTPS 肯定會更慢一點稽屏，時間主要花費在兩組 SSL 之間的耗時和證書的讀取驗證上扮宠，對稱算法的加解密時間幾乎可以忽略不計。

而且如果不是首次握手狐榔，后續(xù)的請求并不需要完整的握手過程坛增。客戶端可以把上次的加密情況直接發(fā)送給服務器從而快速恢復薄腻，具體細節(jié)可以參考 圖解SSL/TLS協議轿偎。

除此以外，SSL 握手的時間并不是只能用來傳遞加密信息被廓，還可以承擔起客戶端和服務器溝通 HTTP2 兼容情況的任務坏晦。因此從 HTTPS 切換到 HTTP2.0 不會有任何性能上的開銷，反倒是得益于 HTTP2.0 的多路復用等技術嫁乘，后續(xù)可以節(jié)約大量時間昆婿。

如果把 HTTPS2.0 當做目標，那么 HTTPS 的性能損耗就更小了蜓斧，遠遠比不上它帶來的安全性提升仓蛆。

結語

相信以上九個問題足夠幫助新人了解 HTTPS 了，但這只是基本概念挎春，關于 HTTPS 的使用(比如 iOS 上的一些具體問題)還需要不斷嘗試和研究看疙。

九個問題從入門到熟悉 HTTPS（原）