建站
咨詢
售后
建站咨詢
新聞中心
當(dāng)你打開瀏覽器，訪問某個(gè)網(wǎng)站，如果網(wǎng)址旁有個(gè)小鎖，代表訪問的網(wǎng)址是安全的，反之不安全。
10年積累的成都網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)經(jīng)驗(yàn)，可以快速應(yīng)對(duì)客戶對(duì)網(wǎng)站的新想法和需求。提供各種問題對(duì)應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先網(wǎng)站設(shè)計(jì)后付款的網(wǎng)站建設(shè)流程，更有合水免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。
圖片來自 Pexels
當(dāng)我們沒有看到那個(gè)小鎖的小圖標(biāo)的時(shí)候，需要提高警惕，不要隨意輸入個(gè)人重要的資料。所有的銀行和支付相關(guān)的網(wǎng)站都是 100% 使用 HTTPS 的。
為什么需要 HTTPS?
我們?yōu)槭裁葱枰?HTTPS?主要有如下三個(gè)原因：
①保護(hù)隱私(Privacy)：所有信息都是加密傳播，第三方無法竊聽數(shù)據(jù)。如果使用 HTTP 明文傳輸數(shù)據(jù)的話，很可能被第三方劫持?jǐn)?shù)據(jù)，那么所輸入的密碼或者其他個(gè)人資料都被暴露在他人面前，后果可想而知。
②數(shù)據(jù)完整性(Integraty)：一旦第三方篡改了數(shù)據(jù)，接收方會(huì)知道數(shù)據(jù)經(jīng)過了篡改，這樣便保證了數(shù)據(jù)在傳輸過程中不被篡改——數(shù)據(jù)的完整性。
③身份認(rèn)證(Identification)：第三方不可能冒充身份參與通信，因?yàn)榉?wù)器配備了由證書頒發(fā)機(jī)構(gòu)(Certificate Authority，簡稱 CA)頒發(fā)的安全證書，可以證實(shí)服務(wù)器的身份信息，防止第三方冒充身份。
也有少數(shù)情況下，通信需要客戶端提供證書，例如銀行系統(tǒng)，需要用戶在登錄的時(shí)候，插入銀行提供給用戶的 USB，就是需要客戶端提供證書，用來驗(yàn)證客戶的身份信息。
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é)議之間。(它沒有被劃分在 OSI 網(wǎng)絡(luò)協(xié)議模型中，且認(rèn)為它是應(yīng)用層的子層。)
眾所周知，網(wǎng)景公司 20 世紀(jì) 90 年代在和微軟的競爭中最終敗下陣來，之后網(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é)議之上，信息通信通過 SSL/TLS 進(jìn)行加密，最后一個(gè) S 就是 Secure 的縮寫，代表安全的意思，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ù)語存在的時(shí)間太長，很多地方還是廣泛的使用它，但是要清楚其實(shí)它說的是 TLS。
有調(diào)查顯示現(xiàn)在絕大部分瀏覽器(>99.5%)都使用 TLS 1.2 或者 TLS 1.3。只有不足 1% 的瀏覽器仍然使用 TLS 1.0 或者 TLS 1.1。
TLS 1.2 仍然是主流協(xié)議(本文寫于 2020 年初)，相信將來逐漸 TLS 1.3 將會(huì)作為主流協(xié)議。
很多瀏覽器將會(huì)開始不支持 TLS 1.0 和 1.1：
- Google 將在 Chrome 72 中不推薦使用 TLS 1.0 和 1.1，而 Chrome 81 之后將會(huì)完全不支持。
- Mozilla 的 Firefox，微軟的 Edge 和 IE 以及蘋果的 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ì)稱加密
- 非對(duì)稱加密
對(duì)稱加密：通信雙方使用相同的密鑰進(jìn)行加密。特點(diǎn)是加密速度快，但是缺點(diǎn)是需要保護(hù)好密鑰，如果密鑰泄露的話，那么加密就會(huì)被別人破解。常見的對(duì)稱加密有 AES，DES 算法。
非對(duì)稱加密：它需要生成兩個(gè)密鑰：公鑰(Public Key)和私鑰(Private Key)。
公鑰顧名思義是公開的，任何人都可以獲得，而私鑰是私人保管的，相信大多程序員已經(jīng)對(duì)這種算法很熟悉了。
我們提交代碼到 Github 的時(shí)候，就可以使用 SSH key：在本地生成私鑰和公鑰，私鑰放在本地 .ssh 目錄中，公鑰放在 Github 網(wǎng)站上。
這樣每次提交代碼，不用麻煩的輸入用戶名和密碼了，Github 會(huì)根據(jù)網(wǎng)站上存儲(chǔ)的公鑰來識(shí)別我們的身份。公鑰負(fù)責(zé)加密，私鑰負(fù)責(zé)解密;或者，私鑰負(fù)責(zé)加密，公鑰負(fù)責(zé)解密。
這種加密算法安全性更高，但是計(jì)算量相比對(duì)稱加密大很多，加密和解密都很慢。
常見的非對(duì)稱算法有 RSA。SSL/TLS 是利用了對(duì)稱加密和非對(duì)稱加密的特點(diǎn)。
先來看下整個(gè) SSL/TLS 的握手過程，之后我們?cè)俜植襟E詳細(xì)解讀，每一步都干了些什么。
①當(dāng) TCP 建立連接之后，TLS 握手的第一步由客戶端發(fā)起，發(fā)送 ClientHello 的消息到服務(wù)器。
ClientHello 消息包含：
- 客戶端支持的 SSL/TLS 版本
- 客戶端支持的加密套件(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”，這么長的名字看著有點(diǎn)暈吧，不用怕，其實(shí)它的命名非常規(guī)范，格式很固定?；镜男问绞恰懊荑€交換算法-服務(wù)身份驗(yàn)證算法-對(duì)稱加密算法-握手校驗(yàn)算法”。
握手過程中，證書簽名使用的 RSA 算法，如果證書驗(yàn)證正確，再使用 ECDHE 算法進(jìn)行密鑰交換，握手后的通信使用的是 AES256 的對(duì)稱算法分組模式是 GCM。
驗(yàn)證證書簽名合法性使用 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ù)器的安全證書(含公鑰)。如果需要客戶端也提供證書的話，還會(huì)發(fā)出客戶端證書請(qǐng)求(Client Certificate Request)，只有少數(shù)金融機(jī)構(gòu)才需要客戶端也提供客戶端證書。
此后客戶端發(fā)送 Server Hello Done 消息表示 Hello 階段完成。
③客戶端收到 ServerHello 后，會(huì)對(duì)收到的證書進(jìn)行驗(yàn)證。
我們來看一下為什么可以通過 CA(Certificate Authority，證書頒發(fā)機(jī)構(gòu))簽發(fā)的證書來確認(rèn)網(wǎng)站的身份?
當(dāng)我們安裝操作系統(tǒng)或者瀏覽器的時(shí)候，會(huì)安裝一組可信任的 CA(根證書 CA 包括 GlobalSign、GeoTrust、Verisign 等)列表。
根 CA 如 GlobalSign 就在我們的可信任的 CA 列表里，你的瀏覽器或者操作系統(tǒng)含有 GlobalSign 的公鑰。
先來看一下 Google 的證書，當(dāng)你訪問 Google 的時(shí)候，Google 會(huì)發(fā)給你它的證書。證書中包含頒發(fā)機(jī)構(gòu)的簽名以及服務(wù)器的公鑰。
瀏覽器首先用哈希函數(shù)對(duì)明文信息的摘要做哈希得到一個(gè)哈希值(用到的就是證書中的簽名哈希算法 SHA256)，然后用根 CA 的公鑰對(duì)根證書的簽名作解密得到另一個(gè)哈希值(用到的算法就是 RSA 非對(duì)稱算法)。
如果兩個(gè)哈希值相等則說明證書沒有被篡改過。當(dāng)然還需校驗(yàn)證書中服務(wù)器名稱是否合法以及驗(yàn)證證書是否過期。
這樣就免受中間人攻擊了，因?yàn)榧偃缬兄虚g人修改了證書的內(nèi)容(如將證書中的公鑰替換成自己的公鑰)，那么將獲得不同的哈希值，從而兩個(gè)哈希值不匹配導(dǎo)致驗(yàn)證失敗。
如果要繞過這個(gè)機(jī)制，中間人必須要也替換簽名，使簽名也相匹配。而做到這一點(diǎn)就需要破解到了根證書的密鑰(而這是不可能的，中間人必然會(huì)失敗)。
瀏覽器會(huì)出現(xiàn)以下畫面，告訴你正在遭受中間人攻擊，因?yàn)樽C書被篡改了：
那聰明的你肯定也想到了，如果你開發(fā)了一個(gè)系統(tǒng)還在測試階段，還沒有正式申請(qǐng)一張證書，那么你可以為服務(wù)器自簽名一張證書，然后將證書導(dǎo)入客戶端的 CA 信任列表中。
信任鏈機(jī)制如下圖：
可以看到證書路徑是：
- GlobalSign Root CA-R2→GTS CA 1O1→*.google.com
因?yàn)槲覀兊臑g覽器信任 GlobalSign Root CA，根據(jù)信任鏈機(jī)制，你相信了根 CA 頒發(fā)的證書，也要相信它簽名的子 CA 頒發(fā)的證書，也要相信子 CA 簽名的子子 CA 的證書。
而我們通過一級(jí)級(jí)的校驗(yàn)，如果從根證書到最下層的證書都沒有被篡改過，我們就相信最下層的這個(gè)服務(wù)器證書是合法的。所以在這個(gè)機(jī)制中，你就需要無條件的相信根證書的頒發(fā)機(jī)構(gòu)。
如果通過驗(yàn)證，客戶端生成一個(gè)隨機(jī)數(shù) pre-master，用于密鑰交換過程。
④密鑰交換過程：客戶端用第三步中服務(wù)器的證書中拿到服務(wù)器的公鑰，用這個(gè)公鑰加密(算法是加密套件中的密鑰交換算法，譬如 ECDHE 算法)生成密文發(fā)送給服務(wù)器。
⑤客戶端用 server-random+client-random+pre-master 一起計(jì)算出對(duì)稱密鑰 master secret。
⑥服務(wù)器收到第四步的信息之后，用服務(wù)器的私鑰對(duì)密文進(jìn)行解密得到密鑰 pre-master。
因?yàn)橹挥蟹?wù)器有私鑰，可以針對(duì)客戶端發(fā)出的加密過的信息進(jìn)行解密得到 pre-master，這樣就保證了只有服務(wù)器和客戶端知道 pre-master。
服務(wù)器端也可以用 server-random+client-random+pre-master 一起計(jì)算出對(duì)稱密鑰 master secret。
現(xiàn)在客戶端和服務(wù)器均有密鑰 master secret 了，后面就可以用它來進(jìn)行加密和解密了。
為什么不能只用一個(gè) pre-master 作為之后加密的對(duì)稱密鑰?
雖然只有服務(wù)器有私鑰，能夠解密 pre-master 呀，但僅用它作為 master secret 是不夠安全的，這是因?yàn)橐苑揽蛻舳说?pre-master 并不是隨機(jī)數(shù)的情況。
加上另外兩個(gè)隨機(jī)數(shù) client-random 以及 server-random(而這兩個(gè)隨機(jī)數(shù)和時(shí)間有相關(guān)性)，這樣就能保證最后生成的 master secret 一定是隨機(jī)數(shù)。
⑦客戶端用 master secret 加密了一條握手完成的消息發(fā)送給服務(wù)器。
⑧服務(wù)器端也回發(fā)了一條用 master secret 加密的握手完成的消息。
⑨當(dāng)兩方都收到對(duì)方發(fā)送的握手消息之后，也成功解密后，就可以用 master secret 愉快的開始數(shù)據(jù)加密和解密了。
綜上，整個(gè)握手過程主要是通過一系列步驟通過非對(duì)稱加密的算法交換得到了 master secret，這個(gè)步驟通常需要幾百毫秒，但是就是這一頓猛操作之后使得只有服務(wù)器和客戶端知道 master secret。
之后的通信又利用了高效的對(duì)稱算法對(duì)所有信息進(jìn)行加密和解密，雖然加密和解密也需要耗時(shí)耗流量，不過信息是完全不可能被別人篡改和破解的，這一點(diǎn)損耗還是值得的。
作者：Stephanie Tang
編輯：陶家龍
出處：stephanietang.github.io/2020/04/19/how-https-works/
分享名稱：摸著良心說，你了解HTTPS工作原理嗎？
網(wǎng)址分享：http://m.5511xx.com/article/cdccihj.html
