為什麼HTTPS比HTTP更安全？
摘要： 理解HTTPS。
- 作者：浪裏行舟
Fundebug經授權轉載，版權歸原作者所有。
前言
近幾年，互聯網發生著翻天覆地的變化，尤其是我們一直習以為常的HTTP協議，在逐漸的被HTTPS協議所取代，在瀏覽器、搜索引擎、CA機構、大型互聯網企業的共同促進下，互聯網迎來了「HTTPS加密時代」，HTTPS將在未來的幾年內全面取代HTTP成為傳輸協議的主流。
讀完本文，希望你能明白：
- HTTP通信存在什麼問題
- HTTPS如何改進HTTP存在那些問題
- HTTPS工作原理是什麼
想閱讀更多優質文章請猛戳GitHub博客，一年五十篇優質文章等著你！
一、什麼是HTTPS
HTTPS是在HTTP上建立SSL加密層，並對傳輸數據進行加密，是HTTP協議的安全版。現在它被廣泛用於萬維網上安全敏感的通訊，例如交易支付方面。
HTTPS主要作用是：
（1）對數據進行加密，並建立一個信息安全通道，來保證傳輸過程中的數據安全;
（2）對網站伺服器進行真實身份認證。
我們經常會在Web的登錄頁面和購物結算界面等使用HTTPS通信。使用HTTPS通信時，不再用http://，而是改用https://。另外，當瀏覽器訪問HTTPS通信有效的Web網站時，瀏覽器的地址欄內會出現一個帶鎖的標記。對HTTPS的顯示方式會因瀏覽器的不同而有所改變。
二、為什麼需要HTTPS
在HTTP協議中有可能存在信息竊取或身份偽裝等安全問題。使用HTTPS通信機制可以有效地防止這些問題，接下來，我們先來瞭解下 HTTP協議存在的哪些問題：
- 通信使用明文（不加密），內容可能被竊聽
由於HTTP本身不具備加密的功能，所以也無法做到對通信整體（使用HTTP協議通信的請求和響應的內容）進行加密。即，HTTP報文使用明文（指未經過加密的報文）方式發送。
HTTP明文協議的缺陷是導致數據泄露、數據篡改、流量劫持、釣魚攻擊等安全問題的重要原因。HTTP協議無法加密數據，所有通信數據都在網路中明文「裸奔」。通過網路的嗅探設備及一些技術手段，就可還原HTTP報文內容。
- 無法證明報文的完整性，所以可能遭篡改
所謂完整性是指信息的準確度。若無法證明其完整性，通常也就意味著無法判斷信息是否準確。由於HTTP協議無法證明通信的報文完整性，因此，在請求或響應送出之後直到對方接收之前的這段時間內，即使請求或響應的內容遭到篡改，也沒有辦法獲悉。 換句話說，沒有任何辦法確認，發出的請求/響應和接收到的請求/響應是前後相同的。
- 不驗證通信方的身份，因此有可能遭遇偽裝
HTTP協議中的請求和響應不會對通信方進行確認。在HTTP協議通信時，由於不存在確認通信方的處理步驟，任何人都可以發起請求。另外，伺服器只要接收到請求，不管對方是誰都會返回一個響應（但也僅限於發送端的IP地址和埠號沒有被Web伺服器設定限制訪問的前提下）
HTTP協議無法驗證通信方身份，任何人都可以偽造虛假伺服器欺騙用戶，實現「釣魚欺詐」，用戶無法察覺。
反觀HTTPS協議，它比HTTP協議相比多了以下優勢（下文會詳細介紹）:
- 數據隱私性：內容經過對稱加密，每個連接生成一個唯一的加密密鑰
- 數據完整性：內容傳輸經過完整性校驗
- 身份認證：第三方無法偽造服務端（客戶端）身份
三、HTTPS如何解決HTTP上述問題?
HTTPS並非是應用層的一種新協議。只是HTTP通信介面部分用SSL（Secure Socket Layer）和TLS（Transport Layer Security）協議代替而已。
通常，HTTP直接和TCP通信。當使用SSL時，則演變成先和SSL通信，再由SSL和TCP通信了。簡言之，所謂HTTPS，其實就是身披SSL協議這層外殼的HTTP。
在採用SSL後，HTTP就擁有了HTTPS的加密、證書和完整性保護這些功能。也就是說HTTP加上加密處理和認證以及完整性保護後即是HTTPS。
HTTPS 協議的主要功能基本都依賴於 TLS/SSL 協議，TLS/SSL 的功能實現主要依賴於三類基本演算法：散列函數 、對稱加密和非對稱加密，其利用非對稱加密實現身份認證和密鑰協商，對稱加密演算法採用協商的密鑰對數據加密，基於散列函數驗證信息的完整性。
（一）解決內容可能被竊聽的問題——加密
方法1. 對稱加密
這種方式加密和解密同用一個密鑰。加密和解密都會用到密鑰。沒有密鑰就無法對密碼解密，反過來說，任何人只要持有密鑰就能解密了。
以對稱加密方式加密時必須將密鑰也發給對方。可究竟怎樣才能安全地轉交？在互聯網上轉發密鑰時，如果通信被監聽那麼密鑰就可會落人攻擊者之手，同時也就失去了加密的意義。另外還得設法安全地保管接收到的密鑰。
方法2. 非對稱加密
公開密鑰加密使用一對非對稱的密鑰。一把叫做私有密鑰，另一把叫做公開密鑰。顧名思義，私有密鑰不能讓其他任何人知道，而公開密鑰則可以隨意發布，任何人都可以獲得。
使用公開密鑰加密方式，發送密文的一方使用對方的公開密鑰進行加密處理，對方收到被加密的信息後，再使用自己的私有密鑰進行解密。利用這種方式，不需要發送用來解密的私有密鑰，也不必擔心密鑰被攻擊者竊聽而盜走。
非對稱加密的特點是信息傳輸一對多，伺服器只需要維持一個私鑰就能夠和多個客戶端進行加密通信。
這種方式有以下缺點：
- 公鑰是公開的，所以針對私鑰加密的信息，黑客截獲後可以使用公鑰進行解密，獲取其中的內容；
- 公鑰並不包含伺服器的信息，使用非對稱加密演算法無法確保伺服器身份的合法性，存在中間人攻擊的風險，伺服器發送給客戶端的公鑰可能在傳送過程中被中間人截獲並篡改；
- 使用非對稱加密在數據加密解密過程需要消耗一定時間，降低了數據傳輸效率；
方法3. 對稱加密+非對稱加密(HTTPS採用這種方式)
使用對稱密鑰的好處是解密的效率比較快，使用非對稱密鑰的好處是可以使得傳輸的內容不能被破解，因為就算你攔截到了數據，但是沒有對應的私鑰，也是不能破解內容的。就比如說你搶到了一個保險櫃，但是沒有保險櫃的鑰匙也不能打開保險櫃。那我們就將對稱加密與非對稱加密結合起來，充分利用兩者各自的優勢，在交換密鑰環節使用非對稱加密方式，之後的建立通信交換報文階段則使用對稱加密方式。
具體做法是：發送密文的一方使用對方的公鑰進行加密處理「對稱的密鑰」，然後對方用自己的私鑰解密拿到「對稱的密鑰」，這樣可以確保交換的密鑰是安全的前提下，使用對稱加密方式進行通信。所以，HTTPS採用對稱加密和非對稱加密兩者並用的混合加密機制。
（二）解決報文可能遭篡改問題——數字簽名
網路傳輸過程中需要經過很多中間節點，雖然數據無法被解密，但可能被篡改，那如何校驗數據的完整性呢？----校驗數字簽名。
數字簽名有兩種功效：
- 能確定消息確實是由發送方簽名並發出來的，因為別人假冒不了發送方的簽名。
- 數字簽名能確定消息的完整性，證明數據是否未被篡改過。
數字簽名如何生成:
將一段文本先用Hash函數生成消息摘要，然後用發送者的私鑰加密生成數字簽名，與原文文一起傳送給接收者。接下來就是接收者校驗數字簽名的流程了。
校驗數字簽名流程：
接收者只有用發送者的公鑰才能解密被加密的摘要信息，然後用HASH函數對收到的原文產生一個摘要信息，與上一步得到的摘要信息對比。如果相同，則說明收到的信息是完整的，在傳輸過程中沒有被修改，否則說明信息被修改過，因此數字簽名能夠驗證信息的完整性。
假設消息傳遞在Kobe，James兩人之間發生。James將消息連同數字簽名一起發送給Kobe，Kobe接收到消息後，通過校驗數字簽名，就可以驗證接收到的消息就是James發送的。當然，這個過程的前提是Kobe知道James的公鑰。問題的關鍵的是，和消息本身一樣，公鑰不能在不安全的網路中直接發送給Kobe，或者說拿到的公鑰如何證明是James的。
此時就需要引入了證書頒發機構（Certificate Authority，簡稱CA），CA數量並不多，Kobe客戶端內置了所有受信任CA的證書。CA對James的公鑰（和其他信息）數字簽名後生成證書。
###（三）解決通信方身份可能被偽裝的問題——數字證書
數字證書認證機構處於客戶端與伺服器雙方都可信賴的第三方機構的立場上。我們來介紹一下數字證書認證機構的業務流程。
- 伺服器的運營人員向數字證書認證機構提出公開密鑰的申請
- 數字證書認證機構在判明提出申請者的身份之後，會對已申請的公開密鑰做數字簽名
- 然後分配這個已簽名的公開密鑰，並將該公開密鑰放入公鑰證書後綁定在一起
- 伺服器會將這份由數字證書認證機構頒發的公鑰證書發送給客戶端，以進行非對稱加密方式通信。公鑰證書也可叫做數字證書或直接稱為證書。
接到證書的客戶端可使用數字證書認證機構的公開密鑰，對那張證書上的數字簽名進行驗證，一旦驗證通過，客戶端便可明確兩件事：
一、認證伺服器的公開密鑰的是真實有效的數字證書認證機構。
二、伺服器的公開密鑰是值得信賴的。
四、 HTTPS工作流程
1.Client發起一個HTTPS（比如https://juejin.im/user/5a9a9cdcf265da238b7d771c）的請求，根據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」。
五、HTTP 與 HTTPS 的區別
- HTTP 是明文傳輸協議，HTTPS 協議是由 SSL+HTTP 協議構建的可進行加密傳輸、身份認證的網路協議，比 HTTP 協議安全。
關於安全性，用最簡單的比喻形容兩者的關係就是卡車運貨，HTTP下的運貨車是敞篷的，貨物都是暴露的。而https則是封閉集裝箱車，安全性自然提升不少。
- HTTPS比HTTP更加安全，對搜索引擎更友好，利於SEO，谷歌、百度優先索引HTTPS網頁;
- HTTPS需要用到SSL證書，而HTTP不用;
- HTTPS標準埠443，HTTP標準埠80;
- HTTPS基於傳輸層，HTTP基於應用層;
- HTTPS在瀏覽器顯示綠色安全鎖，HTTP沒有顯示;
六、為何不所有的網站都使用HTTPS
既然HTTPS那麼安全可靠，那為何不所有的Web網站都使用HTTPS？
首先，很多人還是會覺得HTTPS實施有門檻，這個門檻在於需要權威CA頒發的SSL證書。從證書的選擇、購買到部署，傳統的模式下都會比較耗時耗力。
其次，HTTPS普遍認為性能消耗要大於HTTP，因為與純文本通信相比，加密通信會消耗更多的CPU及內存資源。如果每次通信都加密，會消耗相當多的資源，平攤到一臺計算機上時，能夠處理的請求數量必定也會隨之減少。但事實並非如此，用戶可以通過性能優化、把證書部署在SLB或CDN，來解決此問題。舉個實際的例子，「雙十一」期間，全站HTTPS的淘寶、天貓依然保證了網站和移動端的訪問、瀏覽、交易等操作的順暢、平滑。通過測試發現，經過優化後的許多頁面性能與HTTP持平甚至還有小幅提升，因此HTTPS經過優化之後其實並不慢。
除此之外，想要節約購買證書的開銷也是原因之一。要進行HTTPS通信，證書是必不可少的。而使用的證書必須向認證機構（CA）購買。
最後是安全意識。相比國內，國外互聯網行業的安全意識和技術應用相對成熟，HTTPS部署趨勢是由社會、企業、政府共同去推動的。
參考文章與書籍
- 圖解HTTP
- 珠峯架構課(推薦)
- 數字簽名是什麼？(推薦)
- HTTPS工作原理
- HTTPS 原理詳解
- 詳解HTTPS是如何確保安全性的？
- [信息安全] 3.HTTPS工作流程
- 為什麼HTTPS比HTTP更安全
關於Fundebug
Fundebug專註於JavaScript、微信小程序、微信小遊戲、支付寶小程序、React Native、Node.js和Java線上應用實時BUG監控。 自從2016年雙十一正式上線，Fundebug累計處理了10億+錯誤事件，付費客戶有Google、360、金山軟體、百姓網等眾多品牌企業。歡迎大家免費試用！
推薦閱讀：
