當(dāng)你打開(kāi)瀏覽器，訪問(wèn)某個(gè)網(wǎng)站，如果網(wǎng)址旁有個(gè)小鎖，代表訪問(wèn)的網(wǎng)址是安全的，反之不安全。

[[325875]]

 

圖片來(lái)自 Pexels

當(dāng)我們沒(méi)有看到那個(gè)小鎖的小圖標(biāo)的時(shí)候，需要提高警惕，不要隨意輸入個(gè)人重要的資料。所有的銀行和支付相關(guān)的網(wǎng)站都是 100% 使用 HTTPS 的。

 

為什么需要 HTTPS?

我們?yōu)槭裁葱枰?HTTPS?主要有如下三個(gè)原因：

①保護(hù)隱私(Privacy)：所有信息都是加密傳播，第三方無(wú)法竊聽(tīng)數(shù)據(jù)。如果使用 HTTP 明文傳輸數(shù)據(jù)的話，很可能被第三方劫持?jǐn)?shù)據(jù)，那么所輸入的密碼或者其他個(gè)人資料都被暴露在他人面前，后果可想而知。

②數(shù)據(jù)完整性(Integraty)：一旦第三方篡改了數(shù)據(jù)，接收方會(huì)知道數(shù)據(jù)經(jīng)過(guò)了篡改，這樣便保證了數(shù)據(jù)在傳輸過(guò)程中不被篡改——數(shù)據(jù)的完整性。

③身份認(rèn)證(Identification)：第三方不可能冒充身份參與通信，因?yàn)榉?wù)器配備了由證書(shū)頒發(fā)機(jī)構(gòu)(Certificate Authority，簡(jiǎn)稱(chēng) CA)頒發(fā)的安全證書(shū)，可以證實(shí)服務(wù)器的身份信息，防止第三方冒充身份。

也有少數(shù)情況下，通信需要客戶(hù)端提供證書(shū)，例如銀行系統(tǒng)，需要用戶(hù)在登錄的時(shí)候，插入銀行提供給用戶(hù)的 USB，就是需要客戶(hù)端提供證書(shū)，用來(lái)驗(yàn)證客戶(hù)的身份信息。

HTTPS 是什么?SSL/TLS 是什么?

HTTP 協(xié)議(HyperText Transfer Protocol，超文本傳輸協(xié)議)是大家最熟悉的一種協(xié)議，它是一個(gè)用于傳輸超媒體文檔的協(xié)議，它位于 OSI 網(wǎng)絡(luò)協(xié)議模型的應(yīng)用層。

但是它是明文傳輸協(xié)議，是非常不安全的，容易被人篡改和竊取數(shù)據(jù)。

SSL(Secure Socket Layer)——網(wǎng)景(Netscape)公司設(shè)計(jì)的主要用于 Web 的安全傳輸協(xié)議。

它位于 TCP 傳輸層協(xié)議和應(yīng)用層協(xié)議之間。(它沒(méi)有被劃分在 OSI 網(wǎng)絡(luò)協(xié)議模型中，且認(rèn)為它是應(yīng)用層的子層。)

眾所周知，網(wǎng)景公司 20 世紀(jì) 90 年代在和微軟的競(jìng)爭(zhēng)中最終敗下陣來(lái)，之后網(wǎng)景公司將 SSL 協(xié)議的管理權(quán)轉(zhuǎn)交給 IETF(Internet Engineering Task Force, www.ietf.org)。

于是 IETF 將 SSL 作了標(biāo)準(zhǔn)化，重新命名為 TLS(Transport Layer Security)。在 1999 年，TLS 1.0 誕生了(其實(shí)也就是 SSL 3.1)。

 

HTTPS(HyperText Transfer Protocol Secure)是建立在 SSL/TLS 協(xié)議之上，信息通信通過(guò) SSL/TLS 進(jìn)行加密，最后一個(gè) S 就是 Secure 的縮寫(xiě)，代表安全的意思，HTTPS = HTTP+SSL/TLS。

SSL/TLS 發(fā)展史

 

 

 

 

 

 

 

 

 

 

 

 

 

SSL/TLS 發(fā)展史如上圖：

實(shí)際上現(xiàn)代的瀏覽器已經(jīng)基本不使用 SSL，使用的都是 TLS，SSL 3.0 于 2015 年已經(jīng)壽終正寢，各大瀏覽器也不支持了。

但是由于 SSL 這個(gè)術(shù)語(yǔ)存在的時(shí)間太長(zhǎng)，很多地方還是廣泛的使用它，但是要清楚其實(shí)它說(shuō)的是 TLS。

有調(diào)查顯示現(xiàn)在絕大部分瀏覽器(>99.5%)都使用 TLS 1.2 或者 TLS 1.3。只有不足 1% 的瀏覽器仍然使用 TLS 1.0 或者 TLS 1.1。

TLS 1.2 仍然是主流協(xié)議(本文寫(xiě)于 2020 年初)，相信將來(lái)逐漸 TLS 1.3 將會(huì)作為主流協(xié)議。

很多瀏覽器將會(huì)開(kāi)始不支持 TLS 1.0 和 1.1：

• Google 將在 Chrome 72 中不推薦使用 TLS 1.0 和 1.1，而 Chrome 81 之后將會(huì)完全不支持。
• Mozilla 的 Firefox，微軟的 Edge 和 IE 以及蘋(píng)果的 Safari 都會(huì)分別于 2020 年逐漸移除對(duì) TLS 1.0 和 1.1 的支持。

那么一些還在使用 TLS 1.0 和 1.1 的網(wǎng)站就得被迫升級(jí)到 TLS 1.2 或者 TLS 1.3。

要關(guān)閉瀏覽器對(duì) TLS 1.0 和 1.1 的支持，可以在 Internet 選項(xiàng)中修改：

 

SSL/TLS 的工作原理

需要理解 SSL/TLS 的工作原理，我們需要掌握加密算法。

加密算法有兩種：

• 對(duì)稱(chēng)加密
• 非對(duì)稱(chēng)加密

對(duì)稱(chēng)加密：通信雙方使用相同的密鑰進(jìn)行加密。特點(diǎn)是加密速度快，但是缺點(diǎn)是需要保護(hù)好密鑰，如果密鑰泄露的話，那么加密就會(huì)被別人破解。常見(jiàn)的對(duì)稱(chēng)加密有 AES，DES 算法。

非對(duì)稱(chēng)加密：它需要生成兩個(gè)密鑰：公鑰(Public Key)和私鑰(Private Key)。

公鑰顧名思義是公開(kāi)的，任何人都可以獲得，而私鑰是私人保管的，相信大多程序員已經(jīng)對(duì)這種算法很熟悉了。

我們提交代碼到 Github 的時(shí)候，就可以使用 SSH key：在本地生成私鑰和公鑰，私鑰放在本地 .ssh 目錄中，公鑰放在 Github 網(wǎng)站上。

這樣每次提交代碼，不用麻煩的輸入用戶(hù)名和密碼了，Github 會(huì)根據(jù)網(wǎng)站上存儲(chǔ)的公鑰來(lái)識(shí)別我們的身份。公鑰負(fù)責(zé)加密，私鑰負(fù)責(zé)解密;或者，私鑰負(fù)責(zé)加密，公鑰負(fù)責(zé)解密。

這種加密算法安全性更高，但是計(jì)算量相比對(duì)稱(chēng)加密大很多，加密和解密都很慢。

常見(jiàn)的非對(duì)稱(chēng)算法有 RSA。SSL/TLS 是利用了對(duì)稱(chēng)加密和非對(duì)稱(chēng)加密的特點(diǎn)。

先來(lái)看下整個(gè) SSL/TLS 的握手過(guò)程，之后我們?cè)俜植襟E詳細(xì)解讀，每一步都干了些什么。

 

①當(dāng) TCP 建立連接之后，TLS 握手的第一步由客戶(hù)端發(fā)起，發(fā)送 ClientHello 的消息到服務(wù)器。

ClientHello 消息包含：

• 客戶(hù)端支持的 SSL/TLS 版本
• 客戶(hù)端支持的加密套件(Cipher Suites)
• 會(huì)話 Idsession id(如果有的值的話，服務(wù)器端會(huì)復(fù)用對(duì)應(yīng)的握手信息，避免短時(shí)間內(nèi)重復(fù)握手)
• 隨機(jī)數(shù) client-random

延伸閱讀：

加密套件名如：“TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA256”，這么長(zhǎng)的名字看著有點(diǎn)暈吧，不用怕，其實(shí)它的命名非常規(guī)范，格式很固定。基本的形式是“密鑰交換算法-服務(wù)身份驗(yàn)證算法-對(duì)稱(chēng)加密算法-握手校驗(yàn)算法”。

握手過(guò)程中，證書(shū)簽名使用的 RSA 算法，如果證書(shū)驗(yàn)證正確，再使用 ECDHE 算法進(jìn)行密鑰交換，握手后的通信使用的是 AES256 的對(duì)稱(chēng)算法分組模式是 GCM。

驗(yàn)證證書(shū)簽名合法性使用 SHA256 作哈希算法檢驗(yàn)。相關(guān)的算法的用處將在后文中詳解。

②然后服務(wù)器端在收到這個(gè) ClientHello，從中選擇服務(wù)器支持的版本和套件，發(fā)送 ServerHello 消息：

• 服務(wù)器所能支持的最高 SSL/TLS 版本
• 服務(wù)器選擇的加密套件
• 隨機(jī)數(shù) server-random
• 會(huì)話 Idsession id(用于下次復(fù)用當(dāng)前握手的信息，避免短時(shí)間內(nèi)重復(fù)握手。)

隨后服務(wù)器發(fā)送服務(wù)器的安全證書(shū)(含公鑰)。如果需要客戶(hù)端也提供證書(shū)的話，還會(huì)發(fā)出客戶(hù)端證書(shū)請(qǐng)求(Client Certificate Request)，只有少數(shù)金融機(jī)構(gòu)才需要客戶(hù)端也提供客戶(hù)端證書(shū)。

此后客戶(hù)端發(fā)送 Server Hello Done 消息表示 Hello 階段完成。

③客戶(hù)端收到 ServerHello 后，會(huì)對(duì)收到的證書(shū)進(jìn)行驗(yàn)證。

我們來(lái)看一下為什么可以通過(guò) CA(Certificate Authority，證書(shū)頒發(fā)機(jī)構(gòu))簽發(fā)的證書(shū)來(lái)確認(rèn)網(wǎng)站的身份?

當(dāng)我們安裝操作系統(tǒng)或者瀏覽器的時(shí)候，會(huì)安裝一組可信任的 CA(根證書(shū) CA 包括 GlobalSign、GeoTrust、Verisign 等)列表。

根 CA 如 GlobalSign 就在我們的可信任的 CA 列表里，你的瀏覽器或者操作系統(tǒng)含有 GlobalSign 的公鑰。

先來(lái)看一下 Google 的證書(shū)，當(dāng)你訪問(wèn) Google 的時(shí)候，Google 會(huì)發(fā)給你它的證書(shū)。證書(shū)中包含頒發(fā)機(jī)構(gòu)的簽名以及服務(wù)器的公鑰。

 

瀏覽器首先用哈希函數(shù)對(duì)明文信息的摘要做哈希得到一個(gè)哈希值(用到的就是證書(shū)中的簽名哈希算法 SHA256)，然后用根 CA 的公鑰對(duì)根證書(shū)的簽名作解密得到另一個(gè)哈希值(用到的算法就是 RSA 非對(duì)稱(chēng)算法)。

如果兩個(gè)哈希值相等則說(shuō)明證書(shū)沒(méi)有被篡改過(guò)。當(dāng)然還需校驗(yàn)證書(shū)中服務(wù)器名稱(chēng)是否合法以及驗(yàn)證證書(shū)是否過(guò)期。

 

這樣就免受中間人攻擊了，因?yàn)榧偃缬兄虚g人修改了證書(shū)的內(nèi)容(如將證書(shū)中的公鑰替換成自己的公鑰)，那么將獲得不同的哈希值，從而兩個(gè)哈希值不匹配導(dǎo)致驗(yàn)證失敗。

如果要繞過(guò)這個(gè)機(jī)制，中間人必須要也替換簽名，使簽名也相匹配。而做到這一點(diǎn)就需要破解到了根證書(shū)的密鑰(而這是不可能的，中間人必然會(huì)失敗)。

瀏覽器會(huì)出現(xiàn)以下畫(huà)面，告訴你正在遭受中間人攻擊，因?yàn)樽C書(shū)被篡改了：

 

那聰明的你肯定也想到了，如果你開(kāi)發(fā)了一個(gè)系統(tǒng)還在測(cè)試階段，還沒(méi)有正式申請(qǐng)一張證書(shū)，那么你可以為服務(wù)器自簽名一張證書(shū)，然后將證書(shū)導(dǎo)入客戶(hù)端的 CA 信任列表中。

信任鏈機(jī)制如下圖：

 

可以看到證書(shū)路徑是：

• GlobalSign Root CA-R2→GTS CA 1O1→*.google.com

因?yàn)槲覀兊臑g覽器信任 GlobalSign Root CA，根據(jù)信任鏈機(jī)制，你相信了根 CA 頒發(fā)的證書(shū)，也要相信它簽名的子 CA 頒發(fā)的證書(shū)，也要相信子 CA 簽名的子子 CA 的證書(shū)。

而我們通過(guò)一級(jí)級(jí)的校驗(yàn)，如果從根證書(shū)到最下層的證書(shū)都沒(méi)有被篡改過(guò)，我們就相信最下層的這個(gè)服務(wù)器證書(shū)是合法的。所以在這個(gè)機(jī)制中，你就需要無(wú)條件的相信根證書(shū)的頒發(fā)機(jī)構(gòu)。

如果通過(guò)驗(yàn)證，客戶(hù)端生成一個(gè)隨機(jī)數(shù) pre-master，用于密鑰交換過(guò)程。

④密鑰交換過(guò)程：客戶(hù)端用第三步中服務(wù)器的證書(shū)中拿到服務(wù)器的公鑰，用這個(gè)公鑰加密(算法是加密套件中的密鑰交換算法，譬如 ECDHE 算法)生成密文發(fā)送給服務(wù)器。

⑤客戶(hù)端用 server-random+client-random+pre-master 一起計(jì)算出對(duì)稱(chēng)密鑰 master secret。

⑥服務(wù)器收到第四步的信息之后，用服務(wù)器的私鑰對(duì)密文進(jìn)行解密得到密鑰 pre-master。

因?yàn)橹挥蟹?wù)器有私鑰，可以針對(duì)客戶(hù)端發(fā)出的加密過(guò)的信息進(jìn)行解密得到 pre-master，這樣就保證了只有服務(wù)器和客戶(hù)端知道 pre-master。

服務(wù)器端也可以用 server-random+client-random+pre-master 一起計(jì)算出對(duì)稱(chēng)密鑰 master secret。

現(xiàn)在客戶(hù)端和服務(wù)器均有密鑰 master secret 了，后面就可以用它來(lái)進(jìn)行加密和解密了。

為什么不能只用一個(gè) pre-master 作為之后加密的對(duì)稱(chēng)密鑰?

雖然只有服務(wù)器有私鑰，能夠解密 pre-master 呀，但僅用它作為 master secret 是不夠安全的，這是因?yàn)橐苑揽蛻?hù)端的 pre-master 并不是隨機(jī)數(shù)的情況。

加上另外兩個(gè)隨機(jī)數(shù) client-random 以及 server-random(而這兩個(gè)隨機(jī)數(shù)和時(shí)間有相關(guān)性)，這樣就能保證最后生成的 master secret 一定是隨機(jī)數(shù)。

⑦客戶(hù)端用 master secret 加密了一條握手完成的消息發(fā)送給服務(wù)器。

⑧服務(wù)器端也回發(fā)了一條用 master secret 加密的握手完成的消息。

⑨當(dāng)兩方都收到對(duì)方發(fā)送的握手消息之后，也成功解密后，就可以用 master secret 愉快的開(kāi)始數(shù)據(jù)加密和解密了。

綜上，整個(gè)握手過(guò)程主要是通過(guò)一系列步驟通過(guò)非對(duì)稱(chēng)加密的算法交換得到了 master secret，這個(gè)步驟通常需要幾百毫秒，但是就是這一頓猛操作之后使得只有服務(wù)器和客戶(hù)端知道 master secret。

之后的通信又利用了高效的對(duì)稱(chēng)算法對(duì)所有信息進(jìn)行加密和解密，雖然加密和解密也需要耗時(shí)耗流量，不過(guò)信息是完全不可能被別人篡改和破解的，這一點(diǎn)損耗還是值得的。

作者：Stephanie Tang

編輯：陶家龍

出處：stephanietang.github.io/2020/04/19/how-https-works/