您好,登錄后才能下訂單哦!
HTTPS通信是什么原理?相信很多沒有經驗的人對此束手無策,為此本文總結了問題出現的原因和解決方法,通過這篇文章希望你能解決這個問題。
HTTPS通信原理是:HTTPS是“HTTP over SSL/TLS”,HTTPS相比HTTP多了一層“SSL/TLS”,HTTPS在傳輸數據之前需要客戶端與服務端之間進行一次握手,在握手過程中將確立雙方加密傳輸數據的密碼信息。
HTTP 協議(HyperText Transfer Protocol,超文本傳輸協議):是客戶端瀏覽器或其他程序與Web服務器之間的應用層通信協議 。HTTPS(全稱:HyperText Transfer Protocol over Secure Socket Layer),可以理解為HTTP+SSL/TLS, 即 HTTP 下加入 SSL 層,HTTPS 的安全基礎是 SSL,因此加密的詳細內容就需要 SSL,用于安全的 HTTP 數據傳輸。
HTTPS和HTTP的區別:
a. https協議需要到ca申請證書,一般免費證書很少,需要交費。
b. http是超文本傳輸協議,信息是明文傳輸;https 則是具有安全性的ssl加密傳輸協議。
c. http和https使用的是完全不同的連接方式,用的端口也不一樣,前者是80,后者是443。
d. http的連接很簡單,是無狀態的;HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議,比http協議安全。
它的主要作用可以分為兩種:一種是建立一個信息安全通道,來保證數據傳輸的安全;另一種就是確認網站的真實性。
a. 一般意義上的https,就是服務器有一個證書。主要目的是保證服務器就是他聲稱的服務器,這個跟第一點一樣;服務端和客戶端之間的所有通訊,都是加密的。
b. 具體講,是客戶端產生一個對稱的密鑰,通過服務器的證書來交換密鑰,即一般意義上的握手過程。這部分會在下面詳細介紹。
c. 接下來所有的信息往來就都是加密的。第三方即使截獲,也沒有任何意義,因為他沒有密鑰,當然篡改也就沒有什么意義了。
d.少許對客戶端有要求的情況下,會要求客戶端也必須有一個證書。
為何需要HTTPS協議:
HTTP協議是沒有加密的明文傳輸協議,如果Client(APP、瀏覽器)采用HTTP傳輸數據,則會泄露傳輸內容,可能被中間人劫持,修改傳輸的內容。如下圖所示就是典型的APP HTTP通信被運營商劫持修改,插入廣告:
為了保護用戶的信息安全、保護自己的商業利益,減少攻擊面,我們需要保障通信信道的安全,采用開發方便的HTTPS是比較好的方式。
HTTPS是HTTP over SSL/TLS,HTTP是應用層協議,TCP是傳輸層協議,在應用層和傳輸層之間,增加了一個安全套接層SSL/TLS:
如上圖所示 HTTPS 相比 HTTP 多了一層 SSL/TLS,SSL/TLS層負責客戶端和服務器之間的加解密算法協商、密鑰交換、通信連接的建立。
HTTPS在傳輸數據之前需要客戶端(瀏覽器)與服務端(網站)之間進行一次握手,在握手過程中將確立雙方加密傳輸數據的密碼信息。TLS/SSL協議不僅僅是一套加密傳輸的協議,更是一件經過藝術家精心設計的藝術品,TLS/SSL中使用了非對稱加密,對稱加密以及HASH算法。握手過程如下:
客戶端發起請求,以明文傳輸請求信息,包含版本信息,加密套件候選列表,壓縮算法候選列表,隨機數,擴展字段等信息,相關信息如下:
? 支持的最高TSL協議版本version,從低到高依次 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2,當前基本不再使用低于 TLSv1 的版本;
? 客戶端支持的加密套件 cipher suites 列表, 每個加密套件對應前面 TLS 原理中的四個功能的組合:認證算法 Au (身份驗證)、密鑰交換算法 KeyExchange(密鑰協商)、對稱加密算法 Enc (信息加密)和信息摘要 Mac(完整性校驗);
? 支持的壓縮算法 compression methods 列表,用于后續的信息壓縮傳輸;
? 隨機數 random_C,用于后續的密鑰的生成;
? 擴展字段 extensions,支持協議與算法的相關參數以及其它輔助信息等,常見的 SNI 就屬于擴展字段,后續單獨討論該字段作用。
? server_hello, 服務端返回協商的信息結果,包括選擇使用的協議版本 version,選擇的加密套件 cipher suite,選擇的壓縮算法 compression method、隨機數 random_S 等,其中隨機數用于后續的密鑰協商;
? server_certificates, 服務器端配置對應的證書鏈,用于身份驗證與密鑰交換;
? server_hello_done,通知客戶端 server_hello 信息發送結束;
客戶端驗證證書的合法性,如果驗證通過才會進行后續通信,否則根據錯誤情況不同做出提示和操作,合法性驗證包括如下:
? [證書鏈]的可信性 trusted certificate path,方法如前文所述;
? 證書是否吊銷 revocation,有兩類方式離線 CRL 與在線 OCSP,不同的客戶端行為會不同;
? 有效期 expiry date,證書是否在有效時間范圍;
? 域名 domain,核查證書域名是否與當前的訪問域名匹配,匹配規則后續分析;
(a) client_key_exchange,合法性驗證通過之后,客戶端計算產生隨機數字 Pre-master,并用證書公鑰加密,發送給服務器;
(b) 此時客戶端已經獲取全部的計算協商密鑰需要的信息:兩個明文隨機數 random_C 和 random_S 與自己計算產生的 Pre-master,計算得到協商密鑰;
enc_key=Fuc(random_C, random_S, Pre-Master)
(c) change_cipher_spec,客戶端通知服務器后續的通信都采用協商的通信密鑰和加密算法進行加密通信;
(d) encrypted_handshake_message,結合之前所有通信參數的 hash 值與其它相關信息生成一段數據,采用協商密鑰 session secret 與算法進行加密,然后發送給服務器用于數據與握手驗證;
(a) 服務器用私鑰解密加密的Pre-master 數據,基于之前交換的兩個明文隨機數 random_C 和 random_S,計算得到協商密鑰:enc_key=Fuc(random_C, random_S, Pre-Master);
(b) 計算之前所有接收信息的 hash 值,然后解密客戶端發送的 encrypted_handshake_message,驗證數據和密鑰正確性;
(c) change_cipher_spec, 驗證通過之后,服務器同樣發送 change_cipher_spec 以告知客戶端后續的通信都采用協商的密鑰與算法進行加密通信;
(d) encrypted_handshake_message, 服務器也結合所有當前的通信參數信息生成一段數據并采用協商密鑰enc_key與算法加密并發送到客戶端;
客戶端計算所有接收信息的 hash 值,并采用協商密鑰解密 encrypted_handshake_message,驗證服務器發送的數據和密鑰,驗證通過則握手完成;
開始使用協商密鑰與算法進行加密通信。時序圖如下:
在(3)證書校驗中,客戶端會對服務端發送過來的證書做校驗,下面我們具體看下該過程做了哪些工作
1、驗證頒發者、有效期
2、驗證是否在信任列表中
2、驗證合法性
驗證證書時,客戶端讀取證書中的相關的明文信息,采用相同的散列函數計算得到信息摘要,然后,利用對應CA的公鑰(從本地取出)解密簽名數據,對比證書的信息摘要,如果一致,則可以確認證書的合法性,即公鑰合法;
申請者公鑰、申請者的組織信息和個人信息、簽發機構 CA的信息、有效時間、證書序列號等信息的明文,同時包含一個簽名;
簽名的產生:使用散列函數計算公開的明文信息的信息摘要,然后,采用 CA的私鑰對信息摘要進行加密,密文即簽名。
Tips;
1、Client使用Server發送的公鑰加密數據,將加密數據發送給Server,Server使用私鑰進行解密,是為非對稱加密
2、當Client、Server均掌握了協商密鑰enc_key后,雙方均用該密鑰進行加密、解密,是為對稱加密
TLS/SSL的功能實現主要依賴于三類基本算法:散列函數 Hash、對稱加密和非對稱加密,其利用非對稱加密實現身份認證和密鑰協商,對稱加密算法采用協商的密鑰對數據加密,基于散列函數驗證信息的完整性。
有流式、分組兩種,加密和解密都是使用的同一個密鑰。
例如:DES、AES-GCM、ChaCha20-Poly1305等
加密使用的密鑰和解密使用的密鑰是不相同的,分別稱為:公鑰、私鑰,公鑰和算法都是公開的,私鑰是保密的。非對稱加密算法性能較低,但是安全性超強,由于其加密特性,非對稱加密算法能加密的數據長度也是有限的。
例如:RSA、DSA、ECDSA、 DH、ECDHE
將任意長度的信息轉換為較短的固定長度的值,通常其長度要比信息小得多,且算法不可逆。
例如:MD5、SHA-1、SHA-2、SHA-256 等
簽名就是在信息的后面再加上一段內容(信息經過hash后的值),可以證明信息沒有被修改過。hash值一般都會加密后(也就是簽名)再和信息一起發送,以保證這個hash值不被修改。
雙向驗證:
服務器也可以要求驗證客戶端,即雙向認證,可以在過程2要發送 client_certificate_request 信息,客戶端在過程4中先發送 client_certificate與certificate_verify_message 信息,證書的驗證方式基本相同,certificate_verify_message 是采用client的私鑰加密的一段基于已經協商的通信信息得到數據,服務器可以采用對應的公鑰解密并驗證。
看完上述內容,你們掌握HTTPS通信是什么原理的方法了嗎?如果還想學到更多技能或想了解更多相關內容,歡迎關注億速云行業資訊頻道,感謝各位的閱讀!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。