摘要：明文協(xié)議的缺陷是導(dǎo)致數(shù)據(jù)泄露數(shù)據(jù)篡改流量劫持釣魚攻擊等安全問題的重要原因。也就是說加上加密處理和認(rèn)證以及完整性保護后即是。數(shù)字簽名能確定消息的完整性證明數(shù)據(jù)是否未被篡改過。

近幾年，互聯(lián)網(wǎng)發(fā)生著翻天覆地的變化，尤其是我們一直習(xí)以為常的HTTP協(xié)議，在逐漸的被HTTPS協(xié)議所取代，在瀏覽器、搜索引擎、CA機構(gòu)、大型互聯(lián)網(wǎng)企業(yè)的共同促進下，互聯(lián)網(wǎng)迎來了“HTTPS加密時代”，HTTPS將在未來的幾年內(nèi)全面取代HTTP成為傳輸協(xié)議的主流。

讀完本文，希望你能明白：

HTTP通信存在什么問題

HTTPS如何改進HTTP存在那些問題

HTTPS工作原理是什么

想閱讀更多優(yōu)質(zhì)文章請猛戳GitHub博客,一年五十篇優(yōu)質(zhì)文章等著你！

HTTPS是在HTTP上建立SSL加密層，并對傳輸數(shù)據(jù)進行加密，是HTTP協(xié)議的安全版。現(xiàn)在它被廣泛用于萬維網(wǎng)上安全敏感的通訊，例如交易支付方面。

HTTPS主要作用是：

（1）對數(shù)據(jù)進行加密，并建立一個信息安全通道，來保證傳輸過程中的數(shù)據(jù)安全;

（2）對網(wǎng)站服務(wù)器進行真實身份認(rèn)證。

我們經(jīng)常會在Web的登錄頁面和購物結(jié)算界面等使用HTTPS通信。使用HTTPS通信時，不再用http://，而是改用https://。另外，當(dāng)瀏覽器訪問HTTPS通信有效的Web網(wǎng)站時，瀏覽器的地址欄內(nèi)會出現(xiàn)一個帶鎖的標(biāo)記。對HTTPS的顯示方式會因瀏覽器的不同而有所改變。

在HTTP協(xié)議中有可能存在信息竊取或身份偽裝等安全問題。使用HTTPS通信機制可以有效地防止這些問題，接下來，我們先來了解下
HTTP協(xié)議存在的哪些問題：

通信使用明文（不加密），內(nèi)容可能被竊聽

由于HTTP本身不具備加密的功能，所以也無法做到對通信整體（使用HTTP協(xié)議通信的請求和響應(yīng)的內(nèi)容）進行加密。即，HTTP報文使用明文（指未經(jīng)過加密的報文）方式發(fā)送。

HTTP明文協(xié)議的缺陷是導(dǎo)致數(shù)據(jù)泄露、數(shù)據(jù)篡改、流量劫持、釣魚攻擊等安全問題的重要原因。HTTP協(xié)議無法加密數(shù)據(jù)，所有通信數(shù)據(jù)都在網(wǎng)絡(luò)中明文“裸奔”。通過網(wǎng)絡(luò)的嗅探設(shè)備及一些技術(shù)手段，就可還原HTTP報文內(nèi)容。

無法證明報文的完整性，所以可能遭篡改

所謂完整性是指信息的準(zhǔn)確度。若無法證明其完整性，通常也就意味著無法判斷信息是否準(zhǔn)確。由于HTTP協(xié)議無法證明通信的報文完整性，因此，在請求或響應(yīng)送出之后直到對方接收之前的這段時間內(nèi)，即使請求或響應(yīng)的內(nèi)容遭到篡改，也沒有辦法獲悉。
換句話說，沒有任何辦法確認(rèn)，發(fā)出的請求/響應(yīng)和接收到的請求/響應(yīng)是前后相同的。

不驗證通信方的身份，因此有可能遭遇偽裝

HTTP協(xié)議中的請求和響應(yīng)不會對通信方進行確認(rèn)。在HTTP協(xié)議通信時，由于不存在確認(rèn)通信方的處理步驟，任何人都可以發(fā)起請求。另外，服務(wù)器只要接收到請求，不管對方是誰都會返回一個響應(yīng)（但也僅限于發(fā)送端的IP地址和端口號沒有被Web服務(wù)器設(shè)定限制訪問的前提下）

HTTP協(xié)議無法驗證通信方身份，任何人都可以偽造虛假服務(wù)器欺騙用戶，實現(xiàn)“釣魚欺詐”，用戶無法察覺。

反觀HTTPS協(xié)議，它比HTTP協(xié)議相比多了以下優(yōu)勢（下文會詳細(xì)介紹）:

數(shù)據(jù)隱私性：內(nèi)容經(jīng)過對稱加密，每個連接生成一個唯一的加密密鑰

數(shù)據(jù)完整性：內(nèi)容傳輸經(jīng)過完整性校驗

身份認(rèn)證：第三方無法偽造服務(wù)端（客戶端）身份

HTTPS并非是應(yīng)用層的一種新協(xié)議。只是HTTP通信接口部分用SSL和TLS協(xié)議代替而已。

通常，HTTP直接和TCP通信。當(dāng)使用SSL時，則演變成先和SSL通信，再由SSL和TCP通信了。簡言之，所謂HTTPS，其實就是身披SSL協(xié)議這層外殼的HTTP。

在采用SSL后，HTTP就擁有了HTTPS的加密、證書和完整性保護這些功能。也就是說HTTP加上加密處理和認(rèn)證以及完整性保護后即是HTTPS。

HTTPS 協(xié)議的主要功能基本都依賴于 TLS/SSL 協(xié)議，TLS/SSL 的功能實現(xiàn)主要依賴于三類基本算法：散列函數(shù) 、對稱加密和非對稱加密，其利用非對稱加密實現(xiàn)身份認(rèn)證和密鑰協(xié)商，對稱加密算法采用協(xié)商的密鑰對數(shù)據(jù)加密，基于散列函數(shù)驗證信息的完整性。

這種方式加密和解密同用一個密鑰。加密和解密都會用到密鑰。沒有密鑰就無法對密碼解密，反過來說，任何人只要持有密鑰就能解密了。

以對稱加密方式加密時必須將密鑰也發(fā)給對方?？删烤乖鯓硬拍馨踩剞D(zhuǎn)交？在互聯(lián)網(wǎng)上轉(zhuǎn)發(fā)密鑰時，如果通信被監(jiān)聽那么密鑰就可會落人攻擊者之手，同時也就失去了加密的意義。另外還得設(shè)法安全地保管接收到的密鑰。

公開密鑰加密使用一對非對稱的密鑰。一把叫做私有密鑰，另一把叫做公開密鑰。顧名思義，私有密鑰不能讓其他任何人知道，而公開密鑰則可以隨意發(fā)布，任何人都可以獲得。

使用公開密鑰加密方式，發(fā)送密文的一方使用對方的公開密鑰進行加密處理，對方收到被加密的信息后，再使用自己的私有密鑰進行解密。利用這種方式，不需要發(fā)送用來解密的私有密鑰，也不必?fù)?dān)心密鑰被攻擊者竊聽而盜走。

非對稱加密的特點是信息傳輸一對多，服務(wù)器只需要維持一個私鑰就能夠和多個客戶端進行加密通信。

這種方式有以下缺點：

公鑰是公開的，所以針對私鑰加密的信息，黑客截獲后可以使用公鑰進行解密，獲取其中的內(nèi)容；

公鑰并不包含服務(wù)器的信息，使用非對稱加密算法無法確保服務(wù)器身份的合法性，存在中間人攻擊的風(fēng)險，服務(wù)器發(fā)送給客戶端的公鑰可能在傳送過程中被中間人截獲并篡改；

使用非對稱加密在數(shù)據(jù)加密解密過程需要消耗一定時間，降低了數(shù)據(jù)傳輸效率；

使用對稱密鑰的好處是解密的效率比較快，使用非對稱密鑰的好處是可以使得傳輸?shù)膬?nèi)容不能被破解，因為就算你攔截到了數(shù)據(jù)，但是沒有對應(yīng)的私鑰，也是不能破解內(nèi)容的。就比如說你搶到了一個保險柜，但是沒有保險柜的鑰匙也不能打開保險柜。那我們就將對稱加密與非對稱加密結(jié)合起來,充分利用兩者各自的優(yōu)勢，在交換密鑰環(huán)節(jié)使用非對稱加密方式，之后的建立通信交換報文階段則使用對稱加密方式。

具體做法是：發(fā)送密文的一方使用對方的公鑰進行加密處理“對稱的密鑰”，然后對方用自己的私鑰解密拿到“對稱的密鑰”，這樣可以確保交換的密鑰是安全的前提下，使用對稱加密方式進行通信。所以，HTTPS采用對稱加密和非對稱加密兩者并用的混合加密機制。

網(wǎng)絡(luò)傳輸過程中需要經(jīng)過很多中間節(jié)點，雖然數(shù)據(jù)無法被解密，但可能被篡改，那如何校驗數(shù)據(jù)的完整性呢？----校驗數(shù)字簽名。

數(shù)字簽名有兩種功效：

能確定消息確實是由發(fā)送方簽名并發(fā)出來的，因為別人假冒不了發(fā)送方的簽名。

數(shù)字簽名能確定消息的完整性,證明數(shù)據(jù)是否未被篡改過。

數(shù)字簽名如何生成:

將一段文本先用Hash函數(shù)生成消息摘要，然后用發(fā)送者的私鑰加密生成數(shù)字簽名，與原文文一起傳送給接收者。接下來就是接收者校驗數(shù)字簽名的流程了。

校驗數(shù)字簽名流程：

接收者只有用發(fā)送者的公鑰才能解密被加密的摘要信息，然后用HASH函數(shù)對收到的原文產(chǎn)生一個摘要信息，與上一步得到的摘要信息對比。如果相同，則說明收到的信息是完整的，在傳輸過程中沒有被修改，否則說明信息被修改過，因此數(shù)字簽名能夠驗證信息的完整性。

假設(shè)消息傳遞在Kobe，James兩人之間發(fā)生。James將消息連同數(shù)字簽名一起發(fā)送給Kobe，Kobe接收到消息后，通過校驗數(shù)字簽名，就可以驗證接收到的消息就是James發(fā)送的。當(dāng)然，這個過程的前提是Kobe知道James的公鑰。問題的關(guān)鍵的是，和消息本身一樣，公鑰不能在不安全的網(wǎng)絡(luò)中直接發(fā)送給Kobe,或者說拿到的公鑰如何證明是James的。

此時就需要引入了證書頒發(fā)機構(gòu)（Certificate Authority，簡稱CA），CA數(shù)量并不多，Kobe客戶端內(nèi)置了所有受信任CA的證書。CA對James的公鑰（和其他信息）數(shù)字簽名后生成證書。

數(shù)字證書認(rèn)證機構(gòu)處于客戶端與服務(wù)器雙方都可信賴的第三方機構(gòu)的立場上。

我們來介紹一下數(shù)字證書認(rèn)證機構(gòu)的業(yè)務(wù)流程：

服務(wù)器的運營人員向第三方機構(gòu)CA提交公鑰、組織信息、個人信息(域名)等信息并申請認(rèn)證;

CA通過線上、線下等多種手段驗證申請者提供信息的真實性，如組織是否存在、企業(yè)是否合法，是否擁有域名的所有權(quán)等;

如信息審核通過，CA會向申請者簽發(fā)認(rèn)證文件-證書。證書包含以下信息：申請者公鑰、申請者的組織信息和個人信息、簽發(fā)機構(gòu) CA的信息、有效時間、證書序列號等信息的明文，同時包含一個簽名。 其中簽名的產(chǎn)生算法：首先，使用散列函數(shù)計算公開的明文信息的信息摘要，然后，采用 CA的私鑰對信息摘要進行加密，密文即簽名;

客戶端 Client 向服務(wù)器 Server 發(fā)出請求時，Server 返回證書文件;

客戶端 Client 讀取證書中的相關(guān)的明文信息，采用相同的散列函數(shù)計算得到信息摘要，然后，利用對應(yīng) CA的公鑰解密簽名數(shù)據(jù)，對比證書的信息摘要，如果一致，則可以確認(rèn)證書的合法性，即服務(wù)器的公開密鑰是值得信賴的。

客戶端還會驗證證書相關(guān)的域名信息、有效時間等信息; 客戶端會內(nèi)置信任CA的證書信息(包含公鑰)，如果CA不被信任，則找不到對應(yīng) CA的證書，證書也會被判定非法。

1.Client發(fā)起一個HTTPS（比如https://juejin.im/user/5a9a9cdcf265da238b7d771c）的請求，根據(jù)RFC2818的規(guī)定，Client知道需要連接Server的443（默認(rèn)）端口。

2.Server把事先配置好的公鑰證書（public key certificate）返回給客戶端。

3.Client驗證公鑰證書：比如是否在有效期內(nèi)，證書的用途是不是匹配Client請求的站點，是不是在CRL吊銷列表里面，它的上一級證書是否有效，這是一個遞歸的過程，直到驗證到根證書（操作系統(tǒng)內(nèi)置的Root證書或者Client內(nèi)置的Root證書）。如果驗證通過則繼續(xù)，不通過則顯示警告信息。

4.Client使用偽隨機數(shù)生成器生成加密所使用的對稱密鑰，然后用證書的公鑰加密這個對稱密鑰，發(fā)給Server。

5.Server使用自己的私鑰（private key）解密這個消息，得到對稱密鑰。至此，Client和Server雙方都持有了相同的對稱密鑰。

6.Server使用對稱密鑰加密“明文內(nèi)容A”，發(fā)送給Client。

7.Client使用對稱密鑰解密響應(yīng)的密文，得到“明文內(nèi)容A”。

8.Client再次發(fā)起HTTPS的請求，使用對稱密鑰加密請求的“明文內(nèi)容B”，然后Server使用對稱密鑰解密密文，得到“明文內(nèi)容B”。

HTTP 是明文傳輸協(xié)議，HTTPS 協(xié)議是由 SSL+HTTP 協(xié)議構(gòu)建的可進行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比 HTTP 協(xié)議安全。

關(guān)于安全性，用最簡單的比喻形容兩者的關(guān)系就是卡車運貨，HTTP下的運貨車是敞篷的，貨物都是暴露的。而https則是封閉集裝箱車，安全性自然提升不少。

HTTPS比HTTP更加安全，對搜索引擎更友好，利于SEO,谷歌、百度優(yōu)先索引HTTPS網(wǎng)頁;

HTTPS需要用到SSL證書，而HTTP不用;

HTTPS標(biāo)準(zhǔn)端口443，HTTP標(biāo)準(zhǔn)端口80;

HTTPS基于傳輸層，HTTP基于應(yīng)用層;

HTTPS在瀏覽器顯示綠色安全鎖，HTTP沒有顯示;

既然HTTPS那么安全可靠，那為何不所有的Web網(wǎng)站都使用HTTPS？

首先，很多人還是會覺得HTTPS實施有門檻，這個門檻在于需要權(quán)威CA頒發(fā)的SSL證書。從證書的選擇、購買到部署，傳統(tǒng)的模式下都會比較耗時耗力。

其次，HTTPS普遍認(rèn)為性能消耗要大于HTTP，因為與純文本通信相比，加密通信會消耗更多的CPU及內(nèi)存資源。如果每次通信都加密，會消耗相當(dāng)多的資源，平攤到一臺計算機上時，能夠處理的請求數(shù)量必定也會隨之減少。但事實并非如此，用戶可以通過性能優(yōu)化、把證書部署在SLB或CDN，來解決此問題。舉個實際的例子，“雙十一”期間，全站HTTPS的淘寶、天貓依然保證了網(wǎng)站和移動端的訪問、瀏覽、交易等操作的順暢、平滑。通過測試發(fā)現(xiàn)，經(jīng)過優(yōu)化后的許多頁面性能與HTTP持平甚至還有小幅提升，因此HTTPS經(jīng)過優(yōu)化之后其實并不慢。

除此之外，想要節(jié)約購買證書的開銷也是原因之一。要進行HTTPS通信，證書是必不可少的。而使用的證書必須向認(rèn)證機構(gòu)（CA）購買。

最后是安全意識。相比國內(nèi)，國外互聯(lián)網(wǎng)行業(yè)的安全意識和技術(shù)應(yīng)用相對成熟，HTTPS部署趨勢是由社會、企業(yè)、政府共同去推動的。

給大家推薦一個好用的BUG監(jiān)控工具Fundebug，歡迎免費試用！

歡迎關(guān)注公眾號：前端工匠，你的成長我們一起見證！

圖解HTTP

珠峰架構(gòu)課(推薦)

數(shù)字簽名是什么？(推薦)

HTTPS工作原理

HTTPS 原理詳解

詳解HTTPS是如何確保安全性的？

HTTPS工作流程

為什么HTTPS比HTTP更安全