探祕HTTPS
大 廠 技 術 堅 持 周 更 精 選 好 文
今天給大家分享下HTTPS的相關知識。作為前端工程師,對於天天打交道的HTTP我們肯定都熟得不能再熟了,每一次通過瀏覽器發出的請求都是需要符合HTTP協議的。那麼HTTPS和HTTP的區別大家瞭解嗎?
這是一個經典的面試題,大部分人會這麼回答
-
HTTPS比HTTP多了一個S(Secure),也就是説HTTPS是安全版的HTTP
-
端口號不同。HTTP使用80端口,HTTPS使用443端口
-
HTTPS用的是非對稱加密算法
上面的回答能給幾分?等看完本文我們可以再回頭來看下這個回答
那麼,HTTPS是如何實現安全的數據傳輸呢?想徹底搞明白這個問題,就需要了解HTTP的發展歷程、HTTP遇到的問題、對稱與非對稱加密算法、數字簽名、第三方證書頒發機構等概念。
所以,想要全面瞭解HTTPS,還是要從HTTP的發展歷程説起......
I.HTTP
HTTP是Hypertext Transfer Protocal 的縮寫,中文全稱是超文本傳輸協議。
-
超文本是指包含但不限於文本外的圖片、音頻、視頻等多媒體資源。
-
協議是通信雙方約定好的數據傳輸格式以及通信規則。
HTTP是TCP/IP協議簇的最高層--應用層協議。
瀏覽器和服務器在使用HTTP協議相互傳遞超文本數據時,將數據放入報文體內,同時填充首部(請求頭或響應頭)構成完整HTTP報文並交到下層傳輸層,之後每一層加上相應的首部(控制部分)便一層層的下發,最終由物理層將二進制數據以電信號的形式發送出去。HTTP報文結構如下:point_down:
![](http://mdimg.wxwenku.com/getimg/6b990ce30fa9193e296dd37902816f4b3dd1665239fa85fc5bfc10258dd3c941baec93a0f415172607bdc3999d3c8954.jpg)
-
HTTP發展歷程如下:point_down:
版本 | 產生時間 | 內容概括 | 發展現狀 |
---|---|---|---|
HTTP/0.9 | 1991年 | 不涉及數據包傳輸,規定客户端和服務器之間通信格式,只能GET請求 | 非正式標準 |
HTTP/1.0 | 1996年 | 傳輸內容、格式、首部和數組大小不限制,增加POST、PUT、PATCH、HEAD、 OPTIONS、DELETE方式 | 正式標準,廣泛使用 |
HTTP/1.1 | 1997年 | 持久連接(長連接)、節約帶寬、HOST域、管道機制、分塊傳輸編碼 | 最為廣泛 |
HTTP/2 | 2015年 | 多路複用、服務器推送、頭信息壓縮、二進制協議等。必須搭配TLS,也就是默認使用HTTPS | 逐漸興起 |
由HTTP的發展歷程來看,最開始版本的HTTP(HTTP1.0)在每次建立TCP連接後只能發起一次HTTP請求,請求完畢就釋放TCP連接。我們都知道TCP連接的建立需要經過三次握手的過程,而每次發送HTTP請求都需要重新建立TCP連接,毫無疑問是很低效的。所以HTTP1.1改善了這一點,使用長連接的機制,也就是“一次TCP連接,N次HTTP請求”。
HTTP協議的長連接和短連接,實質上是 TCP 協議的長連接和短連接。
在使用長連接的情況下,當一個網頁打開完成後,客户端和服務器之間用於傳輸HTTP數據的TCP連接不會關閉,客户端再次訪問這個服務器時,會繼續使用這一條已經建立的連接。Keep-Alive不會永久保持連接,它有一個保持時間,可以在不同的服務器軟件(如Apache)中設定這個時間。實現長連接需要客户端和服務端都支持長連接。
(HTTP1.0若要開啟長連接,需要加上Connection: keep-alive請求頭)
-
隨着HTTP越來越廣泛的使用,HTTP的安全性問題也逐漸暴露。
回憶一下多年前遍地都是的 運營商劫持 ,當你訪問一個本來很正常的網頁,但頁面上卻莫名其妙出現了一些廣告標籤、跳轉腳本、欺騙性的紅包按鈕,甚至有時候本來要下載一個文件,最後下載下來卻變成了另外一個完全不同的東西,這些都是被運營商劫持了HTTP明文數據的現象。
HTTP有以下3點安全性問題:
-
數據保密性問題
因為HTTP無狀態,而且又是明文傳輸,所有數據內容都在網絡中裸奔,包用户括身份信息、支付賬號與密碼。這些敏感信息極易泄露造成安全隱患。
-
數據完整性問題
HTTP數據包在到達目的主機前會經過很多轉發設備,每一個設備節點都可能會篡改或調包信息,無法驗證數據的完整性。
-
身份校驗問題
有可能遭受中間人攻擊,我們無法驗證通信的另一方就是我們的目標對象。
因此,為了保證數據傳輸的安全性,必須要對HTTP數據進行加密。
II.加密方式
加密方式分為三種:對稱加密、非對稱加密、數字摘要。前兩種適合數據傳輸加密,而數字摘要不可逆的特性常被用於數字簽名。
對稱加密
對稱加密也稱為密鑰加密或單向加密,就是使用同一套密鑰來進行加密和解密。密鑰可以理解為加密算法。對稱加密圖示如下:point_down:
![](http://mdimg.wxwenku.com/getimg/ccdf080c7af7e8a10e9b88444af983934c18eef28a3f12e9a02f11a5ac8f5d77c6fe8c61b0bf9d80875a070ebbc66a40.jpg)
廣泛使用的對稱加密有:
DES(Data Encryption Standard) | 數據加密標準,速度較快,適用於加密大量數據的場合。目前DES已經不是一種安全的加密方法,主要因為它使用的56位密鑰過短 |
---|---|
3DES(Triple DES) | 基於DES,對一塊數據用三個不同的密鑰進行三次加密,強度更高。可以解決因計算機運算能力的增強,DES容易被暴力破解的問題 |
AES(Advanced Encryption Standard) | 高級加密標準,是下一代的加密算法標準,速度快,安全級別高,支持128、192、256、512位密鑰的加密 |
-
優點:算法公開、簡單,加密解密容易,加密速度快,效率高。
-
缺點:相對來説不算特別安全,只有一把鑰匙,密文如果被攔截,且密鑰也被劫持,那麼,信息很容易被破譯。
-
適用場景:加解密速度快、效率高,因此適用於大量數據的加密場景。由於如何傳輸密鑰是較為頭痛的問題,因此適用於無需進行密鑰交換的場景,如內部系統,事先就可以直接確定密鑰。
可以在線體驗:point_right: 對稱加密 [1]
P.S. base64編碼也屬於對稱加密哦
非對稱加密
非對稱加密使用一對密鑰(公鑰和私鑰)進行加密和解密。非對稱加密可以在不直接傳遞密鑰的情況下,完成解密,具體步驟如下:point_down::
-
乙方生成兩把密鑰(公鑰和私鑰)。公鑰是公開的,任何人都可以獲得,私鑰則是保密的。
-
甲方獲取乙方的公鑰,然後用它對信息加密。
-
乙方得到加密後的信息,用私鑰解密。
以最典型的非對稱加密算法--RSA算法舉個例子:
想要徹底搞懂RSA,需要了解數論的知識,全部推導過程 RSA加密算法 [2] 。本文簡單介紹思路:使用兩個超大質數以及其乘積作為生成公鑰和私鑰的材料,想要從公鑰推算出私鑰是非常困難的(需要對超大數因式分解為兩個很大質數的乘積)。目前被破解的最長RSA密鑰是768個二進制位。也就是説,長度超過768位的密鑰,還無法破解(至少沒人公開宣佈)。因此可以認為,1024位的RSA密鑰基本安全,2048位的密鑰極其安全。
-
優點:強度高、安全性強於對稱加密算法、無需傳遞私鑰導致沒有密鑰泄露風險
-
缺點:計算量大、速度慢
-
適用場景:適用於需要密鑰交換的場景,如互聯網應用,無法事先約定密鑰。可以與對稱加密算法結合:
-
利用非對稱加密算法安全性較好的特點來傳遞對稱加密算法的密鑰。
-
利用對稱加密算法加解密速度快的特點,進行數據內容比較大的加密場景的加密。如HTTPS。
如何選擇?
-
選擇對稱加密:HTTP請求方使用對稱算法加密數據,那麼為了接收方能夠解密,發送方還需要把密鑰一同傳遞到接收方。在傳遞密鑰的過程中還是可能遭到嗅探攻擊,攻擊者竊取密鑰後依然可以解密從而得到發送的數據,所以這種方案不可行
-
選擇非對稱加密:接收方保留私鑰,把公鑰傳遞給發送方。發送方用公鑰來加密數據。接收方使用私鑰解密數據。攻擊者雖然不能直接獲取這些數據(因為沒有私鑰),但是可以通過攔截傳遞的公鑰,然後把自己的公鑰傳給發送方,再用自己的私鑰對發送方發送數據進行解密。整個過程通信雙方都不知道中間人的存在,但是中間人能夠獲得完整的數據信息
![](http://mdimg.wxwenku.com/getimg/6b990ce30fa9193e296dd37902816f4bad22abe5b3d4090869ae940039b0f4e98fe11a8ae44c6c9bcd543eb89935c45a.jpg)
-
兩種混合:先使用非對稱加密算法加密並傳遞對稱加密的密鑰,然後雙方通過對稱加密方式加密要發送的數據。 看起來沒什麼問題,但事實是這樣嗎? 中間人依然可以攔截公鑰的傳遞,並以自己的公鑰作為替換,治標不治本。
想要治本,就要找到一個第三方公證人來證明公鑰沒有被替換,因此就引出了 CA 的概念
III.CA
CA就是 Certificate Authority,頒發數字證書的機構。作為受信任的第三方,CA承擔公鑰體系中公鑰的合法性檢驗的責任。證書就是源服務器向可信任的第三方機構申請的數據文件。這個證書除了表明這個域名是屬於誰的,頒發日期等,還包括了第三方證書的私鑰。服務器將公鑰放在數字證書中,只要證書是可信的,公鑰就是可信的。下圖是飛書域名的證書中部分內容的信息:point_down:
數字簽名
-
摘要算法一般用哈希函數來實現,可以理解成一種定長的壓縮算法,它能把任意長度的數據壓縮到固定長度。這好比是給數據加了一把鎖,對數據有任何微小的改動都會使摘要變得截然不同。
-
通常情況下,數字證書的申請人(服務器)將生成由私鑰和公鑰以及證書請求文件(Certificate Signing Request,CSR)組成的密鑰對。CSR是一個編碼的文本文件,其中包含公鑰和其他將包含在證書中的信息(例如域名,組織,電子郵件地址等)。密鑰對和CSR生成通常在將要安裝證書的服務器上完成,並且 CSR 中包含的信息類型取決於證書的驗證級別。與公鑰不同,申請人的私鑰是安全的,永遠不要向 CA(或其他任何人)展示。
-
生成 CSR 後,申請人將其發送給 CA,CA 會驗證其包含的信息是否正確,如果正確,則使用頒發的私鑰對證書進行數字簽名,然後將簽名放在證書內隨證書一起發送給申請人。
![](http://mdimg.wxwenku.com/getimg/356ed03bdc643f9448b3f6485edc229bfc3f729e975672fb8d55dbd49e7f6725440e72a37732e2f34a4087d03f1f4985.jpg)
-
在SSL握手階段,瀏覽器在收到服務器的證書後,使用CA的公鑰進行解密,取出證書中的數據、數字簽名以及服務器的公鑰。如果解密成功,則可驗證服務器身份真實。之後瀏覽器再對數據做Hash運算,將結果與數字簽名作對比,如果一致則可以認為內容沒有收到篡改。
-
對稱加密和非對稱加密是 公鑰加密,私鑰解密, 而數字簽名正好相反,是 私鑰加密(簽名),公鑰解密(驗證)
![](http://mdimg.wxwenku.com/getimg/6b990ce30fa9193e296dd37902816f4b430166667ebcdfcd5f7ca1d64177d4f473cb266c3e73c8faba0d1a842352349e.jpg)
IV.HTTPS
《圖解HTTP》書中提到HTTPS就是身披SSL外殼的HTTP。
![](http://mdimg.wxwenku.com/getimg/ccdf080c7af7e8a10e9b88444af983935c2a75a96f1b87dee0b5dd3061b22d9cc672c6b4d0940c4d12a85019e2208119.jpg)
SSL 在1999年被更名為 TLS
所以説,HTTPS 並不是一項新的應用層協議,只是 HTTP 通信接口部分由 SSL 和 TLS 替代而已。HTTP 會先直接和 TCP 進行通信。而HTTPS 會演變為先和 SSL 進行通信,然後再由 SSL 和 TCP 進行通信。SSL 是一個獨立的協議,不只有 HTTP 可以使用,其他應用層協議也可以使用,比如FTP、SMTP都可以使用SSL來加密。
![](http://mdimg.wxwenku.com/getimg/356ed03bdc643f9448b3f6485edc229bfa97793d106607adf29117b33a3c1be10323720943a27285022a316269e12045.jpg)
HTTPS請求全流程如下圖:point_down:
![](http://mdimg.wxwenku.com/getimg/6b990ce30fa9193e296dd37902816f4b9a0b8cbca85fa8ebde33812f7283c93a07897c0a10a945d4975300aab4ce4267.jpg)
-
用户在瀏覽器發起HTTPS請求,默認使用服務端的443端口進行連接;
-
HTTPS需要使用一套 CA 數字證書 ,證書內會附帶一個服務器的 公鑰Pub ,而與之對應的 私鑰Private 保留在服務端不公開;
-
服務端收到請求,返回配置好的包含 公鑰Pub 的證書給客户端;
-
客户端收到 證書 ,校驗合法性,主要包括是否在有效期內、證書的域名與請求的域名是否匹配,上一級證書是否有效(遞歸判斷,直到判斷到系統內置或瀏覽器配置好的根證書),如果不通過,則顯示HTTPS警告信息,如果通過則繼續;
-
客户端生成一個用於對稱加密的 隨機Key ,並用證書內的 公鑰Pub 進行加密,發送給服務端;
-
服務端收到 隨機Key 的密文,使用與 公鑰Pub 配對的 私鑰Private 進行解密,得到客户端真正想發送的 隨機Key ;
-
服務端使用客户端發送過來的 隨機Key 對要傳輸的HTTP數據進行對稱加密,將密文返回客户端;
-
客户端使用 隨機Key 對稱解密密文,得到HTTP數據明文;
-
後續HTTPS請求使用之前交換好的 隨機Key 進行對稱加解密。
HTTPS確實解決了HTTP的三個安全性問題:
(1) 保密性:結合非對稱加密和對稱加密實現保密性。用非對稱加密方式加密對稱加密的祕鑰,再用對稱加密方式加密數據
(2) 完整性:通過第三方CA的數字簽名解決完整性問題
(3) 身份校驗:通過第三方CA的數字證書驗證服務器的身份
最後我們總結一下HTTPS的優缺點:point_down:
HTTPS優點 | HTTPS缺點 |
---|---|
使用 HTTPS 協議可認證用户和服務器,確保數據發送到正確的客户機和服務器 | HTTPS時間是HTTP的2-100倍,因為需要經歷SSL(TLS)握手,且非對稱加密速度較慢 |
安全可靠,防止數據在傳輸過程中被竊取、改變,確保數據的完整性 | HTTPS 協議的安全是有範圍的,在黑客攻擊、拒絕服務攻擊和服務器劫持等方面幾乎起不到什麼作用 |
HTTPS 是現行架構下最安全的解決方案,雖然不是絕對安全,但它大幅增加了中間人攻擊的成本 | SSL 證書的信用鏈體系並不安全。特別是在某些國家可以控制 CA根證書的情況下,中間人攻擊一樣可行 |
可以看到,HTTPS的確是當今安全傳輸HTTP的最優解,但他並不是完美的,仍會有漏洞
參考
《圖解HTTP》
RSA算法原理 [3]
HTTPS升級指南 [4]
SSL/TLS協議運行機制的概述 [5]
參考資料
對稱加密: http://www.jsons.cn/textencrypt/
RSA加密算法: http://www.ruanyifeng.com/blog/2013/07/rsa_algorithm_part_two.html
RSA算法原理: http://www.ruanyifeng.com/blog/2013/06/rsa_algorithm_part_one.html
HTTPS升級指南: http://www.ruanyifeng.com/blog/2016/08/migrate-from-http-to-https.html
SSL/TLS協議運行機制的概述: http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html
:heart: 謝謝支持
以上便是本次分享的全部內容,希望對你有所幫助^_^
喜歡的話別忘了 分享、點贊、收藏 三連哦~。
歡迎關注公眾號 ELab團隊 收穫 大廠一手好文章~
我們來自字節跳動,是旗下大力教育前端部門,負責字節跳動教育全線產品前端開發工作。
我們圍繞產品品質提升、開發效率、創意與前沿技術等方向沉澱與傳播專業知識及案例,為業界貢獻經驗價值。包括但不限於性能監控、組件庫、多端技術、Serverless、可視化搭建、音視頻、人工智能、產品設計與營銷等內容。
歡迎感興趣的同學在評論區或使用內推碼內推到作者部門拍磚哦
字節跳動校/社招投遞鏈接:
http://jobs.bytedance.com/campus/position/7055504585763064095/detail?referral_code=65SKBPJ
內推碼:65SKBPJ
- 使用 WebAssembly 打造定製 JS Runtime
- 前端也要懂算法,不會算法也能微調一個 NLP 預訓練模型
- 聯機遊戲原理入門即入土 -- 入門篇
- Plasmo Framework:次世代的瀏覽器插件開發框架
- 深入理解 Mocha 測試框架:從零實現一個 Mocha
- Single Source of Truth:XCode SwiftUI 的界面編輯的設計理念
- 深入理解 D3.js 可視化庫之力導向圖原理與實現
- 淺析神經網絡 Neural Networks
- Cutter - Web視頻剪輯工具原理淺析
- 你可能需要一個四捨五入的工具函數
- 淺析eslint原理
- 最小編譯器the-super-tiny-compiler
- Git存儲原理及部分實現
- 淺談短鏈的設計
- Web組件構建庫-Lit
- 使用Svelte開發Chrome Extension
- Web3.0開發入門
- vscode插件原理淺析與實戰
- 深入淺出 Web Audio API
- 探祕HTTPS