深刻理解HTTPS工做原理

前言

近幾年，互聯網發生着翻天覆地的變化，尤爲是咱們一直習覺得常的HTTP協議，在逐漸的被HTTPS協議所取代，在瀏覽器、搜索引擎、CA機構、大型互聯網企業的共同促進下，互聯網迎來了「HTTPS加密時代」，HTTPS將在將來的幾年內全面取代HTTP成爲傳輸協議的主流。

讀完本文，但願你能明白：

• HTTP通訊存在什麼問題
• HTTPS如何改進HTTP存在那些問題
• HTTPS工做原理是什麼

想閱讀更多優質文章請猛戳GitHub博客,一年五十篇優質文章等着你！

1、什麼是HTTPS

HTTPS是在HTTP上創建SSL加密層，並對傳輸數據進行加密，是HTTP協議的安全版。如今它被普遍用於萬維網上安全敏感的通信，例如交易支付方面。

HTTPS主要做用是：

（1）對數據進行加密，並創建一個信息安全通道，來保證傳輸過程當中的數據安全;

（2）對網站服務器進行真實身份認證。

咱們常常會在Web的登陸頁面和購物結算界面等使用HTTPS通訊。使用HTTPS通訊時，再也不用http://，而是改用https://。另外，當瀏覽器訪問HTTPS通訊有效的Web網站時，瀏覽器的地址欄內會出現一個帶鎖的標記。對HTTPS的顯示方式會因瀏覽器的不一樣而有所改變。

2、爲何須要HTTPS

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

• 通訊使用明文（不加密），內容可能被竊聽

因爲HTTP自己不具有加密的功能，因此也沒法作到對通訊總體（使用HTTP協議通訊的請求和響應的內容）進行加密。即，HTTP報文使用明文（指未通過加密的報文）方式發送。

HTTP明文協議的缺陷是致使數據泄露、數據篡改、流量劫持、釣魚攻擊等安全問題的重要緣由。HTTP協議沒法加密數據，全部通訊數據都在網絡中明文「裸奔」。經過網絡的嗅探設備及一些技術手段，就可還原HTTP報文內容。

• 沒法證實報文的完整性，因此可能遭篡改

所謂完整性是指信息的準確度。若沒法證實其完整性，一般也就意味着沒法判斷信息是否準確。因爲HTTP協議沒法證實通訊的報文完整性，所以，在請求或響應送出以後直到對方接收以前的這段時間內，即便請求或響應的內容遭到篡改，也沒有辦法獲悉。 換句話說，沒有任何辦法確認，發出的請求/響應和接收到的請求/響應是先後相同的。

• 不驗證通訊方的身份，所以有可能遭遇假裝

HTTP協議中的請求和響應不會對通訊方進行確認。在HTTP協議通訊時，因爲不存在確認通訊方的處理步驟，任何人均可以發起請求。另外，服務器只要接收到請求，無論對方是誰都會返回一個響應（但也僅限於發送端的IP地址和端口號沒有被Web服務器設定限制訪問的前提下）

HTTP協議沒法驗證通訊方身份，任何人均可以僞造虛假服務器欺騙用戶，實現「釣魚欺詐」，用戶沒法察覺。

反觀HTTPS協議，它比HTTP協議相比多瞭如下優點（下文會詳細介紹）:

• 數據隱私性：內容通過對稱加密，每一個鏈接生成一個惟一的加密密鑰
• 數據完整性：內容傳輸通過完整性校驗
• 身份認證：第三方沒法僞造服務端（客戶端）身份

3、HTTPS如何解決HTTP上述問題?

HTTPS並不是是應用層的一種新協議。只是HTTP通訊接口部分用SSL和TLS協議代替而已。

一般，HTTP直接和TCP通訊。當使用SSL時，則演變成先和SSL通訊，再由SSL和TCP通訊了。簡言之，所謂HTTPS，其實就是身披SSL協議這層外殼的HTTP。

在採用SSL後，HTTP就擁有了HTTPS的加密、證書和完整性保護這些功能。也就是說HTTP加上加密處理和認證以及完整性保護後便是HTTPS。

HTTPS 協議的主要功能基本都依賴於 TLS/SSL 協議，TLS/SSL 的功能實現主要依賴於三類基本算法：散列函數 、對稱加密和非對稱加密，其利用非對稱加密實現身份認證和密鑰協商，對稱加密算法採用協商的密鑰對數據加密，基於散列函數驗證信息的完整性。

1.解決內容可能被竊聽的問題——加密

方法1.對稱加密

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

以對稱加密方式加密時必須將密鑰也發給對方。可究竟怎樣才能安全地轉交？在互聯網上轉發密鑰時，若是通訊被監聽那麼密鑰就可會落人攻擊者之手，同時也就失去了加密的意義。另外還得設法安全地保管接收到的密鑰。

方法2.非對稱加密

公開密鑰加密使用一對非對稱的密鑰。一把叫作私有密鑰，另外一把叫作公開密鑰。顧名思義，私有密鑰不能讓其餘任何人知道，而公開密鑰則能夠隨意發佈，任何人均可以得到。

使用公開密鑰加密方式，發送密文的一方使用對方的公開密鑰進行加密處理，對方收到被加密的信息後，再使用本身的私有密鑰進行解密。利用這種方式，不須要發送用來解密的私有密鑰，也沒必要擔憂密鑰被攻擊者竊聽而盜走。

非對稱加密的特色是信息傳輸一對多，服務器只須要維持一個私鑰就可以和多個客戶端進行加密通訊。

這種方式有如下缺點：

• 公鑰是公開的，因此針對私鑰加密的信息，黑客截獲後可使用公鑰進行解密，獲取其中的內容；
• 公鑰並不包含服務器的信息，使用非對稱加密算法沒法確保服務器身份的合法性，存在中間人攻擊的風險，服務器發送給客戶端的公鑰可能在傳送過程當中被中間人截獲並篡改；
• 使用非對稱加密在數據加密解密過程須要消耗必定時間，下降了數據傳輸效率；

方法3.對稱加密+非對稱加密(HTTPS採用這種方式)

使用對稱密鑰的好處是解密的效率比較快，使用非對稱密鑰的好處是可使得傳輸的內容不能被破解，由於就算你攔截到了數據，可是沒有對應的私鑰，也是不能破解內容的。就好比說你搶到了一個保險櫃，可是沒有保險櫃的鑰匙也不能打開保險櫃。那咱們就將對稱加密與非對稱加密結合起來,充分利用二者各自的優點，在交換密鑰環節使用非對稱加密方式，以後的創建通訊交換報文階段則使用對稱加密方式。

具體作法是：發送密文的一方使用對方的公鑰進行加密處理「對稱的密鑰」，而後對方用本身的私鑰解密拿到「對稱的密鑰」，這樣能夠確保交換的密鑰是安全的前提下，使用對稱加密方式進行通訊。因此，HTTPS採用對稱加密和非對稱加密二者並用的混合加密機制。

2.解決報文可能遭篡改問題——數字簽名

網絡傳輸過程當中須要通過不少中間節點，雖然數據沒法被解密，但可能被篡改，那如何校驗數據的完整性呢？----校驗數字簽名。

數字簽名有兩種功效：

• 能肯定消息確實是由發送方簽名併發出來的，由於別人假冒不了發送方的簽名。
• 數字簽名能肯定消息的完整性,證實數據是否未被篡改過。

數字簽名如何生成:

將一段文本先用Hash函數生成消息摘要，而後用發送者的私鑰加密生成數字簽名，與原文文一塊兒傳送給接收者。接下來就是接收者校驗數字簽名的流程了。

校驗數字簽名流程：

接收者只有用發送者的公鑰才能解密被加密的摘要信息，而後用HASH函數對收到的原文產生一個摘要信息，與上一步獲得的摘要信息對比。若是相同，則說明收到的信息是完整的，在傳輸過程當中沒有被修改，不然說明信息被修改過，所以數字簽名可以驗證信息的完整性。

假設消息傳遞在Kobe，James兩人之間發生。James將消息連同數字簽名一塊兒發送給Kobe，Kobe接收到消息後，經過校驗數字簽名，就能夠驗證接收到的消息就是James發送的。固然，這個過程的前提是Kobe知道James的公鑰。問題的關鍵的是，和消息自己同樣，公鑰不能在不安全的網絡中直接發送給Kobe,或者說拿到的公鑰如何證實是James的。

此時就須要引入了證書頒發機構（Certificate Authority，簡稱CA），CA數量並很少，Kobe客戶端內置了全部受信任CA的證書。CA對James的公鑰（和其餘信息）數字簽名後生成證書。

3.解決通訊方身份可能被假裝的問題——數字證書

數字證書認證機構處於客戶端與服務器雙方均可信賴的第三方機構的立場上。

咱們來介紹一下數字證書認證機構的業務流程：

• 服務器的運營人員向第三方機構CA提交公鑰、組織信息、我的信息(域名)等信息並申請認證;
• CA經過線上、線下等多種手段驗證申請者提供信息的真實性，如組織是否存在、企業是否合法，是否擁有域名的全部權等;
• 如信息審覈經過，CA會向申請者簽發認證文件-證書。證書包含如下信息：申請者公鑰、申請者的組織信息和我的信息、簽發機構 CA的信息、有效時間、證書序列號等信息的明文，同時包含一個簽名。 其中籤名的產生算法：首先，使用散列函數計算公開的明文信息的信息摘要，而後，採用 CA的私鑰對信息摘要進行加密，密文即簽名;
• 客戶端 Client 向服務器 Server 發出請求時，Server 返回證書文件;
• 客戶端 Client 讀取證書中的相關的明文信息，採用相同的散列函數計算獲得信息摘要，而後，利用對應 CA的公鑰解密簽名數據，對比證書的信息摘要，若是一致，則能夠確認證書的合法性，即服務器的公開密鑰是值得信賴的。
• 客戶端還會驗證證書相關的域名信息、有效時間等信息; 客戶端會內置信任CA的證書信息(包含公鑰)，若是CA不被信任，則找不到對應 CA的證書，證書也會被斷定非法。

4、 HTTPS工做流程

1.Client發起一個HTTPS（好比https://juejin.cn/user/4283353031252967）的請求，根據RFC2818的規定，Client知道須要鏈接Server的443（默認）端口。

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

3.Client驗證公鑰證書：好比是否在有效期內，證書的用途是否是匹配Client請求的站點，是否是在CRL吊銷列表裏面，它的上一級證書是否有效，這是一個遞歸的過程，直到驗證到根證書（操做系統內置的Root證書或者Client內置的Root證書）。若是驗證經過則繼續，不經過則顯示警告信息。

4.Client使用僞隨機數生成器生成加密所使用的對稱密鑰，而後用證書的公鑰加密這個對稱密鑰，發給Server。

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

6.Server使用對稱密鑰加密「明文內容A」，發送給Client。

7.Client使用對稱密鑰解密響應的密文，獲得「明文內容A」。

8.Client再次發起HTTPS的請求，使用對稱密鑰加密請求的「明文內容B」，而後Server使用對稱密鑰解密密文，獲得「明文內容B」。

5、HTTP 與 HTTPS 的區別

• HTTP 是明文傳輸協議，HTTPS 協議是由 SSL+HTTP 協議構建的可進行加密傳輸、身份認證的網絡協議，比 HTTP 協議安全。

關於安全性，用最簡單的比喻形容二者的關係就是卡車運貨，HTTP下的運貨車是敞篷的，貨物都是暴露的。而https則是封閉集裝箱車，安全性天然提高很多。

• HTTPS比HTTP更加安全，對搜索引擎更友好，利於SEO,谷歌、百度優先索引HTTPS網頁;
• HTTPS須要用到SSL證書，而HTTP不用;
• HTTPS標準端口443，HTTP標準端口80;
• HTTPS基於傳輸層，HTTP基於應用層;
• HTTPS在瀏覽器顯示綠色安全鎖，HTTP沒有顯示;

6、爲什麼不全部的網站都使用HTTPS

既然HTTPS那麼安全可靠，那爲什麼不全部的Web網站都使用HTTPS？

首先，不少人仍是會以爲HTTPS實施有門檻，這個門檻在於須要權威CA頒發的SSL證書。從證書的選擇、購買到部署，傳統的模式下都會比較耗時耗力。

其次，HTTPS廣泛認爲性能消耗要大於HTTP，由於與純文本通訊相比，加密通訊會消耗更多的CPU及內存資源。若是每次通訊都加密，會消耗至關多的資源，平攤到一臺計算機上時，可以處理的請求數量一定也會隨之減小。但事實並不是如此，用戶能夠經過性能優化、把證書部署在SLB或CDN，來解決此問題。舉個實際的例子，「雙十一」期間，全站HTTPS的淘寶、天貓依然保證了網站和移動端的訪問、瀏覽、交易等操做的順暢、平滑。經過測試發現，通過優化後的許多頁面性能與HTTP持平甚至還有小幅提高，所以HTTPS通過優化以後其實並不慢。

除此以外，想要節約購買證書的開銷也是緣由之一。要進行HTTPS通訊，證書是必不可少的。而使用的證書必須向認證機構（CA）購買。

最後是安全意識。相比國內，國外互聯網行業的安全意識和技術應用相對成熟，HTTPS部署趨勢是由社會、企業、政府共同去推進的。

給你們推薦一個好用的BUG監控工具Fundebug，歡迎免費試用！

歡迎關注公衆號：前端工匠，你的成長咱們一塊兒見證！

參考文章與書籍

• 圖解HTTP
• 珠峯架構課(推薦)
• 數字簽名是什麼？(推薦)
• HTTPS工做原理
• HTTPS 原理詳解
• 詳解HTTPS是如何確保安全性的？
• [信息安全] 3.HTTPS工做流程
• 爲何HTTPS比HTTP更安全