HTTPS概述
宣告:本人的所有部落格皆為個人筆記,作為個人知識索引使用,因此在敘述上存在邏輯不通順、跨度大等問題,希望理解。分享出來僅供大家學習翻閱,若有錯誤希望指出,感謝!
HTTP的缺點
- 通訊使用明文(不加密),內容可能會被竊聽
- 不驗證通訊方的身份,有可能遭遇偽裝
- 無法證明報文的完整性,有可能被篡改
通訊使用明文可能被竊聽
通訊內容在所有通訊線路上都有可能遭到窺視
如果通訊經過加密,就有可能讓人無法破解報文資訊,但加密後的報文資訊本身還是會被看到
通訊的加密
- 使用SSL(安全套接層)或TLS(安全傳輸層協議)加密HTTP通訊
- 用SSL建立安全通訊線路後,就可以在這條線路上進行HTTP通訊了,與SSL組合使用的HTTP被稱為HTTPS
內容的加密
- 將參與通訊的內容本身進行加密
- 由於該方式不同於SSL直接對整個通訊線路進行加密,所以內容仍有被篡改的風險
不驗證通訊方的身份就可能遭遇偽裝
任何人都能發起請求
- 在HTTP通訊時,由於不存在確認通訊方的處理步驟,任何人都能發起請求
查明對方的證書
- 雖然使用HTTP協議無法確定通訊方,但如果使用SSL則可以
- SSL不僅提供加密處理,還使用了“證書”作為確定通訊方的手段
證書由值得信賴的第三方機構頒發,用以證明伺服器和客戶端是實際存在的
偽造證書從技術角度來說是一件異常困難的事
無法證明報文的完整性,可能已被篡改
沒有任何辦法確認,發出的請求/響應和接收到的請求/響應是前後相同的
防止篡改
- 常用MD5和SHA-1等雜湊值校驗的方法,以及用來確認檔案的數字簽名方法
- 這些方法依然無法百分百保證確認結果的正確性
- 僅靠HTTP確保完整性是非常困難的,需要配合其他協議,例如SSL
HTTPS
HTTPS=HTTP+加密+認證+完整性保護
HTTP並非是一種新協議,只是HTTP通訊介面部分用SSL和TLS協議替代而已
通常HTTP直接和TCP通訊,當使用SSL時,則演變成先和SSL通訊,再由SSL和TCP通訊
金鑰加密技術
SSL採用公開金鑰加密方式
近代加密方法中加密演算法是公開的,而金鑰卻是保密的。加密和解密都會用到金鑰,沒有金鑰就無法對金鑰解密。如果金鑰被攻擊者獲得,那金鑰就失去了意義
共享金鑰加密
- 加密和解密用同一個金鑰的方式稱為共享金鑰加密
- 以共享金鑰加密時必須將金鑰也傳送給對方,將金鑰安全的傳輸給對方是一個難以解決的問題
公開金鑰加密
- 公開金鑰加密使用一對非對稱的金鑰,一把叫做私有金鑰,一把叫做共開金鑰,私有金鑰不能讓任何人知道,而公開金鑰可以隨意釋出
- 傳送密文的一方使用對方的公開金鑰進行加密,對方收到被加密的資訊後,再使用自己的私有金鑰進行解密
- 利用這種方式,不需要傳送用來解密的私有金鑰,也不必擔心金鑰被攻擊者竊聽而盜走
HTTPS採用混合加密方式
- HTTPS採用共享金鑰加密和公開金鑰加密兩種方式並用的混合加密機制
- 在交換金鑰環節使用公開金鑰加密方式,之後建立通訊交換報文階段使用共享金鑰加密方式
公開金鑰加密處理起來比共享金鑰加密方式更復雜,因此若在通訊時使用公開金鑰加密方式,效率就很低
證明公開金鑰正確性的證書
證書是由權威的第三方機構簽發的,用於驗證公開金鑰的真實性,確保公開金鑰沒有被篡改
公開金鑰+數字簽名的運作方式如下:
- 伺服器把自己的公開金鑰登入至數字證書認證機構
- 數字證書認證機構用自己的私有金鑰向伺服器的公開金鑰部署數字簽名並頒發公鑰證書
- 客戶端拿到伺服器的公鑰證書後,使用數字證書認證機構的公開金鑰,向數字證書認證機構驗證公鑰證書上的數字簽名,以確定伺服器公開金鑰的真實性
- 使用伺服器的公開金鑰對報文加密後傳送
- 伺服器用私有金鑰對報文解密
EV SSL證書
- 證書的一個作用是用來證明作為通訊方的伺服器是否規範,另外一個作用是可確認對方伺服器背後運營的企業是否真實存在。
- EVSSL證書是基於國際標準的認證指導方針頒發的證書。因此,通過認證的Web網站能夠獲得更高的認可度(持有EVSSL證書的Web網站的瀏覽器位址列處的背景色是綠色的)
客戶端證書
-
HTTPS中還可以使用客戶端證書。以客戶端證書進行客戶端認證,證明伺服器正在通訊的對方始終是預料之內的客戶端,其作用跟伺服器證書如出一轍
-
客戶端證書仍存在幾處問題點。其中的一個問題點是證書的獲取及釋出。想獲取證書時,使用者得自行安裝客戶端證書。但客戶端證書是要付費購買的
-
客戶端證書存在的另一個問題點是, 客戶端證書只能用來證明客戶端實際存在,而不能用來證明使用者本人的真實有效性
自簽名證書
- 由自認證機構頒發的證書稱為自簽名證書
- 如果使用OpenSSL這套開源程式,每個人都可以構建一套屬於自己的認證機構,從而自己給自己頒發伺服器證書。但該伺服器證書在網際網路上不可作為證書使用,瀏覽器訪問該伺服器時,會顯示“無法確認連線安全性”或“該網站的安全證書存在問題”等警告
HTTPS安全通訊機制
- 客戶端通過傳送Client Hello報文開始SSL通訊。報文中包含客戶端支援的SSL的指定版本、加密元件列表(所使用的加密演算法及金鑰長度等)
- 伺服器可進行SSL通訊時,會以Server Hello報文作為應答。和客戶端一樣,在報文中包含SSL版本以及加密元件。伺服器的加密元件內容是從接收到的客戶端加密元件內篩選出來的
- 之後伺服器傳送Certificate報文。報文中包含公開金鑰證書
- 最後伺服器傳送Server Hello Done報文通知客戶端,最初階段的SSL握手協商部分結束
- SSL第一次握手結束之後,客戶端以Client Key Exchange報文作為回應。報文中包含通訊加密中使用的一種被稱為
Pre-master secret的隨機密碼串。該報文已用步驟3中的公開金鑰進行加密 - 接著客戶端繼續傳送Change Cipher Spec報文。該報文會提示伺服器,在此報文之後的通訊會採用Pre-master secret
金鑰加密 - 客戶端傳送 Finished報文。該報文包含連線至今全部報文的整體校驗值。這次握手協商是否能夠成功,要以伺服器是否能夠正確解密該報文作為判定標準
- 伺服器同樣傳送Change Cipher Spee報文
- 服務 器同樣傳送Finished報文
- 伺服器和客戶端的Fistled報文交換完畢之後,SSL連線就算建立完成。當然,通訊會受到SSL的保護。從此處開始進行應用層協議的通訊,即傳送HTTP請求
- 應用層協議通訊,即傳送HTTP響應
- 最後由客戶端斷開連線。斷開連線時,傳送close noify報文
以上流程中,應用層傳送資料時會附加一種叫做MAC的報文摘要,MAC能夠查知報文是否遭到篡改,從而保護報文的完整性
SSL缺點
- HTTPS由於使用了SSL,因此速度不如HTTP
- SSL的慢分兩種,一種是指通訊慢,另一種是指由於大量消耗CPU及記憶體資源(用於加密解密處理運算),導致處理速度變慢
為什麼不一直使用HTTPS
- 與純文字通訊相比,加密通訊會消耗更多的CPU及記憶體資源
- 購買證書也是一筆開銷
相關文章
- [前端 · 面試 ]HTTP 總結(十一)—— HTTPS 概述前端面試HTTP
- 概述
- JVM 概述JVM
- Java 概述Java
- mongodb 概述MongoDB
- Java概述Java
- TCP 概述TCP
- CloudHub概述Cloud
- ElasticSearch 概述Elasticsearch
- SparkSQL 概述SparkSQL
- Kafka 概述Kafka
- JDBC概述JDBC
- Promise 概述Promise
- GraphHttpClient概述HTTPclient
- FastDFS概述AST
- html概述HTML
- SurfaceView概述View
- uoj概述
- (1)概述
- httpsHTTP
- https學習,resin下配置httpsHTTP
- HTTPS那些事(一)HTTPS原理(轉載)HTTP
- DevOps概述dev
- Express 新手概述Express
- Android概述Android
- Redis Ziplist 概述Redis
- JavaScript物件概述JavaScript物件
- Docker 前沿概述Docker
- Web Storage概述Web
- 【Docker】Docker概述Docker
- Java 集合概述Java
- 9.3 parity概述
- JVM的概述JVM
- Redis的概述Redis
- XMLHttpRequest 物件概述XMLHTTP物件
- DTD – 元素概述
- XML 元素概述XML
- java集合概述Java