聊一聊 TLS/SSL
哈嘍大家好，我是咸魚
當(dāng)我們在上網(wǎng)沖浪的時候，會在瀏覽器界面頂部看到一個小鎖標(biāo)志，或者網(wǎng)址以 "https://" 開頭
圖片
這意味著我們正在使用 TLS/SSL 協(xié)議進(jìn)行安全通信。雖然它可能看起來只是一個小小的鎖圖標(biāo)和一個 “https” ，但實(shí)際上，這個協(xié)議在保護(hù)我們的在線隱私和安全方面扮演著至關(guān)重要的角色
那今天咸魚就跟大家聊一聊 TLS/SSL 相關(guān)的一些知識
閱讀文章之前，需要知道：
TLS（Transport Layer Security）和 SSL（Secure Sockets Layer）都是用于加密通信的協(xié)議
TLS 是 SSL 的升級版本，它修復(fù)了 SSL 中存在的一些安全漏洞，并提供了更高級的安全性
中間人攻擊
一天中午，咸魚在星巴克里打算上網(wǎng)沖浪一下，這時候有一個很壞很壞的人走進(jìn)了星巴克
壞人建了一個跟星巴克 WI-FI 同名的接入點(diǎn)，當(dāng)咸魚上網(wǎng)的時候，稍微不注意連接到了壞人偽造的那個假的星巴克 WI-FI，這就導(dǎo)致咸魚任何流量請求都在壞人的監(jiān)控之下
又或者壞人跟咸魚都連上了星巴克 WI-FI ，然后他通過偽造 DHCP 服務(wù)來告訴咸魚的設(shè)備：【我就是網(wǎng)關(guān)，要上網(wǎng)的話，讓我?guī)湍戕D(zhuǎn)發(fā)就可以了】
當(dāng)咸魚要登陸銀行進(jìn)行轉(zhuǎn)賬開始訪問銀行網(wǎng)站的時候，壞人截獲了咸魚這個請求，并向銀行的網(wǎng)站發(fā)送一個偽裝請求，假裝是咸魚在請求
銀行以為這個請求來自于咸魚，于是返回響應(yīng)；壞人把這個響應(yīng)截獲了，然后轉(zhuǎn)發(fā)到咸魚的設(shè)備上
咸魚的設(shè)備認(rèn)為這個響應(yīng)來自于銀行，于是咸魚看到的是一個正常的銀行網(wǎng)站登陸界面，便乖乖地輸入了登錄信息（用戶名密碼等）
壞人再次截獲這些信息，然后將其發(fā)送給真正的銀行網(wǎng)站，這時候壞人已經(jīng)拿到了咸魚的登錄信息
同時，他也繼續(xù)截獲所有咸魚與銀行之間的通信，以便訪問咸魚的銀行賬戶或者進(jìn)行其他惡意活動
圖片
這便是中間人攻擊（Man-in-the-Middle Attack，簡稱 MITM 攻擊）
中間人攻擊是一種計算機(jī)安全威脅，攻擊者插入自己在通信的兩端，竊取或篡改信息
這種攻擊可以在不被察覺的情況下進(jìn)行，因?yàn)橥ㄐ诺膬煞秸J(rèn)為他們正在直接相互通信，而實(shí)際上信息經(jīng)過了攻擊者的處理
如何避免遭受中間人攻擊呢？聰明的小伙伴很快就想到了——通過 HTTPS 來進(jìn)行加密通信！這樣即使信息被截獲，壞人也無法輕易解密
TLS/SSL
非對稱加密
HTTPS 通過 TLS/SSL 來實(shí)現(xiàn)加密傳輸數(shù)據(jù)，保證數(shù)據(jù)在傳輸?shù)倪^程中中間人無法解密，這樣就保證了數(shù)據(jù)的安全性
加密數(shù)據(jù)不是什么難題，通信的時候雙方用密鑰對數(shù)據(jù)加密就行了
但如果大家跟銀行進(jìn)行加密通信的時候用的密鑰都是一樣的，中間人依舊能夠使用這個密鑰去偽造網(wǎng)站然后截獲你的加密數(shù)據(jù)。這樣的話要不要密鑰都沒啥區(qū)別，甚至不還如不要密鑰呢
所以最好的情況就是：我跟銀行通信的時候協(xié)商好用什么密鑰——用 A 密鑰對數(shù)據(jù)加密（公鑰），然后用 B 密鑰對數(shù)據(jù)解密（私鑰），而且：
- A 密鑰加密的數(shù)據(jù)只能 B 密鑰解密
- 這個 B 密鑰只能我一個人擁有，別人是拿不到的
B 密鑰的唯一性，既保證了數(shù)據(jù)的安全（A 密鑰加密的數(shù)據(jù)只能 B 密鑰解密），又能證明我是我（即 B 密鑰只能我一個人擁有）
這便是非對稱加密技術(shù)
非對稱加密有兩個秘鑰，一個是公鑰，一個是私鑰：
- 公鑰會放在互聯(lián)網(wǎng)上公開；私鑰被自己保存，不能對外泄露
- 公鑰加密的數(shù)據(jù)，只有對應(yīng)的私鑰才可以解密
- 只有你有私鑰，我才相信你是你
舉個例子，首先咸魚和銀行把自己的公鑰互相給對方，在通信的時候，咸魚用銀行給的公鑰去加密數(shù)據(jù)并發(fā)送給銀行，銀行拿到之后用自己的私鑰解密數(shù)據(jù)
同理，銀行用咸魚提供的公鑰進(jìn)行數(shù)據(jù)加密，然后咸魚拿到加密數(shù)據(jù)之后用自己的私鑰進(jìn)行解密
TLS/SSL 握手
我們在與銀行通信的時候使用 TLS/SSL 加密傳輸數(shù)據(jù)，會有經(jīng)過兩個階段：
- TLS/SSL 握手階段：用于建立安全的連接通道（非對稱加密）
- 數(shù)據(jù)傳輸階段：通道建立好之后，開始傳輸數(shù)據(jù)（對稱加密）
即在 TLS/SSL 握手階段使用的是非對稱加密技術(shù)，數(shù)據(jù)傳輸階段用的是對稱加密技術(shù)
首先網(wǎng)站會公開自己的公鑰（也就是大家常說的“證書”，網(wǎng)站的公鑰是通過數(shù)字證書公開的）
當(dāng)瀏覽器連接到網(wǎng)站時，會先去下載網(wǎng)站的證書
那這里會有一個問題：既然網(wǎng)站的證書是公開的，阿貓阿狗也能下載。那瀏覽器如何知道這個證書的擁有者即對方就是該網(wǎng)站呢？
聰明的小伙伴肯定會想到：只要能證明對方有私鑰就行了！也就是說瀏覽器用證書（即公鑰）加密一個數(shù)據(jù)，然后發(fā)送給對方；如果對方有私鑰，那就能解密這個數(shù)據(jù)并返回給瀏覽器，那瀏覽器就知道對方身份了
瀏覽器會驗(yàn)證證書的有效性（包括驗(yàn)證服務(wù)器的身份，檢查證書是否過期，是否由受信任的證書頒發(fā)機(jī)構(gòu)（CA）簽發(fā)）
以此來確保正在與合法的網(wǎng)站通信
所以瀏覽器會生成一個隨機(jī)數(shù)（client random），并使用服務(wù)器的公鑰對其進(jìn)行加密，然后將其發(fā)送回服務(wù)器
服務(wù)器使用自己的私鑰解密此數(shù)據(jù)，并使用瀏覽器的公鑰對另一個隨機(jī)數(shù)（server random）進(jìn)行加密并發(fā)送回客戶端
這兩個隨機(jī)數(shù)將用于生成會話密鑰，用于之后的對稱加密通信
具體TLS/SSL 握手階段請看：TLS 詳解握手流程 - 掘金 (juejin.cn)
證書頒發(fā)機(jī)構(gòu) CA
前面我們提到：瀏覽器會去驗(yàn)證證書的有效性，其中包括驗(yàn)證證書是否由受信任的證書頒發(fā)機(jī)構(gòu)（CA）簽發(fā)
這個證書頒發(fā)機(jī)構(gòu)（CA，Certification Authority）是一個權(quán)威的第三方機(jī)構(gòu)，它的存在是為了告訴瀏覽器：有我做擔(dān)保，你們只管信我；只有網(wǎng)站的擁有者，才能擁有網(wǎng)站的證書
即 CA 在這個過程中充當(dāng)了一個【擔(dān)保人】的角色，當(dāng)瀏覽器拿到網(wǎng)站的證書的時候，會去問 CA ：“這個證書是否合法？”
然后 CA 說：“這個證書是合法的！”，瀏覽器才會信任這個網(wǎng)站
網(wǎng)站需要向 CA 申請證書，CA 要對自己頒發(fā)的證書負(fù)責(zé)
最后
以上就是關(guān)于中間人攻擊、TLS/SSL、CA 大致的原理和內(nèi)容。
