HTTPS通信是什么原理？相信很多沒(méi)有經(jīng)驗(yàn)的人對(duì)此束手無(wú)策，為此本文總結(jié)了問(wèn)題出現(xiàn)的原因和解決方法，通過(guò)這篇文章希望你能解決這個(gè)問(wèn)題。

創(chuàng)新互聯(lián)公司從2013年開(kāi)始，先為文峰等服務(wù)建站，文峰等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為文峰企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問(wèn)題。

HTTPS通信原理是：HTTPS是“HTTP over SSL/TLS”，HTTPS相比HTTP多了一層“SSL/TLS”，HTTPS在傳輸數(shù)據(jù)之前需要客戶端與服務(wù)端之間進(jìn)行一次握手，在握手過(guò)程中將確立雙方加密傳輸數(shù)據(jù)的密碼信息。

簡(jiǎn)介：

HTTP 協(xié)議（HyperText Transfer Protocol，超文本傳輸協(xié)議）：是客戶端瀏覽器或其他程序與Web服務(wù)器之間的應(yīng)用層通信協(xié)議 。HTTPS（全稱：HyperText Transfer Protocol over Secure Socket Layer），可以理解為HTTP+SSL/TLS， 即 HTTP 下加入 SSL 層，HTTPS 的安全基礎(chǔ)是 SSL，因此加密的詳細(xì)內(nèi)容就需要 SSL，用于安全的 HTTP 數(shù)據(jù)傳輸。

HTTPS和HTTP的區(qū)別：

a. https協(xié)議需要到ca申請(qǐng)證書(shū)，一般免費(fèi)證書(shū)很少，需要交費(fèi)。

b. http是超文本傳輸協(xié)議，信息是明文傳輸；https 則是具有安全性的ssl加密傳輸協(xié)議。

c. http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。

d. http的連接很簡(jiǎn)單，是無(wú)狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議安全。

HTTPS的作用

     它的主要作用可以分為兩種：一種是建立一個(gè)信息安全通道，來(lái)保證數(shù)據(jù)傳輸?shù)陌踩涣硪环N就是確認(rèn)網(wǎng)站的真實(shí)性。

　a． 一般意義上的https，就是服務(wù)器有一個(gè)證書(shū)。主要目的是保證服務(wù)器就是他聲稱的服務(wù)器，這個(gè)跟第一點(diǎn)一樣；服務(wù)端和客戶端之間的所有通訊，都是加密的。

　b. 具體講，是客戶端產(chǎn)生一個(gè)對(duì)稱的密鑰，通過(guò)服務(wù)器的證書(shū)來(lái)交換密鑰，即一般意義上的握手過(guò)程。這部分會(huì)在下面詳細(xì)介紹。

　c. 接下來(lái)所有的信息往來(lái)就都是加密的。第三方即使截獲，也沒(méi)有任何意義，因?yàn)樗麤](méi)有密鑰，當(dāng)然篡改也就沒(méi)有什么意義了。

　d．少許對(duì)客戶端有要求的情況下，會(huì)要求客戶端也必須有一個(gè)證書(shū)。

為何需要HTTPS協(xié)議：

HTTP協(xié)議是沒(méi)有加密的明文傳輸協(xié)議，如果Client(APP、瀏覽器)采用HTTP傳輸數(shù)據(jù)，則會(huì)泄露傳輸內(nèi)容，可能被中間人劫持，修改傳輸?shù)膬?nèi)容。如下圖所示就是典型的APP HTTP通信被運(yùn)營(yíng)商劫持修改，插入廣告：

     

   

為了保護(hù)用戶的信息安全、保護(hù)自己的商業(yè)利益，減少攻擊面，我們需要保障通信信道的安全，采用開(kāi)發(fā)方便的HTTPS是比較好的方式。

HTTPS通信原理

HTTPS是HTTP over SSL/TLS，HTTP是應(yīng)用層協(xié)議，TCP是傳輸層協(xié)議，在應(yīng)用層和傳輸層之間，增加了一個(gè)安全套接層SSL/TLS：

如上圖所示 HTTPS 相比 HTTP 多了一層 SSL/TLS，SSL/TLS層負(fù)責(zé)客戶端和服務(wù)器之間的加解密算法協(xié)商、密鑰交換、通信連接的建立。

HTTPS在傳輸數(shù)據(jù)之前需要客戶端（瀏覽器）與服務(wù)端（網(wǎng)站）之間進(jìn)行一次握手，在握手過(guò)程中將確立雙方加密傳輸數(shù)據(jù)的密碼信息。TLS/SSL協(xié)議不僅僅是一套加密傳輸?shù)膮f(xié)議，更是一件經(jīng)過(guò)藝術(shù)家精心設(shè)計(jì)的藝術(shù)品，TLS/SSL中使用了非對(duì)稱加密，對(duì)稱加密以及HASH算法。握手過(guò)程如下：

(1).client_hello

客戶端發(fā)起請(qǐng)求，以明文傳輸請(qǐng)求信息，包含版本信息，加密套件候選列表，壓縮算法候選列表，隨機(jī)數(shù)，擴(kuò)展字段等信息，相關(guān)信息如下：

? 支持的最高TSL協(xié)議版本version，從低到高依次 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2，當(dāng)前基本不再使用低于 TLSv1 的版本;

? 客戶端支持的加密套件 cipher suites 列表， 每個(gè)加密套件對(duì)應(yīng)前面 TLS 原理中的四個(gè)功能的組合：認(rèn)證算法 Au (身份驗(yàn)證)、密鑰交換算法 KeyExchange(密鑰協(xié)商)、對(duì)稱加密算法 Enc (信息加密)和信息摘要 Mac(完整性校驗(yàn));

 ? 支持的壓縮算法 compression methods 列表，用于后續(xù)的信息壓縮傳輸;

 ? 隨機(jī)數(shù) random_C，用于后續(xù)的密鑰的生成;

 ? 擴(kuò)展字段 extensions，支持協(xié)議與算法的相關(guān)參數(shù)以及其它輔助信息等，常見(jiàn)的 SNI 就屬于擴(kuò)展字段，后續(xù)單獨(dú)討論該字段作用。

(2).server_hello+server_certificate+sever_hello_done

? server_hello, 服務(wù)端返回協(xié)商的信息結(jié)果，包括選擇使用的協(xié)議版本 version，選擇的加密套件 cipher suite，選擇的壓縮算法 compression method、隨機(jī)數(shù) random_S 等，其中隨機(jī)數(shù)用于后續(xù)的密鑰協(xié)商;

? server_certificates, 服務(wù)器端配置對(duì)應(yīng)的證書(shū)鏈，用于身份驗(yàn)證與密鑰交換;

? server_hello_done，通知客戶端 server_hello 信息發(fā)送結(jié)束;

(3).證書(shū)校驗(yàn)

客戶端驗(yàn)證證書(shū)的合法性，如果驗(yàn)證通過(guò)才會(huì)進(jìn)行后續(xù)通信，否則根據(jù)錯(cuò)誤情況不同做出提示和操作，合法性驗(yàn)證包括如下：

? [證書(shū)鏈]的可信性 trusted certificate path，方法如前文所述;

? 證書(shū)是否吊銷 revocation，有兩類方式離線 CRL 與在線 OCSP，不同的客戶端行為會(huì)不同;

? 有效期 expiry date，證書(shū)是否在有效時(shí)間范圍;

? 域名 domain，核查證書(shū)域名是否與當(dāng)前的訪問(wèn)域名匹配，匹配規(guī)則后續(xù)分析;

(4).client_key_exchange+change_cipher_spec+encrypted_handshake_message

(a) client_key_exchange，合法性驗(yàn)證通過(guò)之后，客戶端計(jì)算產(chǎn)生隨機(jī)數(shù)字 Pre-master，并用證書(shū)公鑰加密，發(fā)送給服務(wù)器;

(b) 此時(shí)客戶端已經(jīng)獲取全部的計(jì)算協(xié)商密鑰需要的信息：兩個(gè)明文隨機(jī)數(shù) random_C 和 random_S 與自己計(jì)算產(chǎn)生的 Pre-master，計(jì)算得到協(xié)商密鑰;

enc_key=Fuc(random_C, random_S, Pre-Master)

(c) change_cipher_spec，客戶端通知服務(wù)器后續(xù)的通信都采用協(xié)商的通信密鑰和加密算法進(jìn)行加密通信;

(d) encrypted_handshake_message，結(jié)合之前所有通信參數(shù)的 hash 值與其它相關(guān)信息生成一段數(shù)據(jù)，采用協(xié)商密鑰 session secret 與算法進(jìn)行加密，然后發(fā)送給服務(wù)器用于數(shù)據(jù)與握手驗(yàn)證;

(5).change_cipher_spec+encrypted_handshake_message

(a) 服務(wù)器用私鑰解密加密的Pre-master 數(shù)據(jù)，基于之前交換的兩個(gè)明文隨機(jī)數(shù) random_C 和 random_S，計(jì)算得到協(xié)商密鑰:enc_key=Fuc(random_C, random_S, Pre-Master);

(b) 計(jì)算之前所有接收信息的 hash 值，然后解密客戶端發(fā)送的 encrypted_handshake_message，驗(yàn)證數(shù)據(jù)和密鑰正確性;

(c) change_cipher_spec, 驗(yàn)證通過(guò)之后，服務(wù)器同樣發(fā)送 change_cipher_spec 以告知客戶端后續(xù)的通信都采用協(xié)商的密鑰與算法進(jìn)行加密通信;

(d) encrypted_handshake_message, 服務(wù)器也結(jié)合所有當(dāng)前的通信參數(shù)信息生成一段數(shù)據(jù)并采用協(xié)商密鑰enc_key與算法加密并發(fā)送到客戶端;

(6).握手結(jié)束

客戶端計(jì)算所有接收信息的 hash 值，并采用協(xié)商密鑰解密 encrypted_handshake_message，驗(yàn)證服務(wù)器發(fā)送的數(shù)據(jù)和密鑰，驗(yàn)證通過(guò)則握手完成;

(7).加密通信

開(kāi)始使用協(xié)商密鑰與算法進(jìn)行加密通信。時(shí)序圖如下：

驗(yàn)證證書(shū)

在（3）證書(shū)校驗(yàn)中，客戶端會(huì)對(duì)服務(wù)端發(fā)送過(guò)來(lái)的證書(shū)做校驗(yàn)，下面我們具體看下該過(guò)程做了哪些工作

1、驗(yàn)證頒發(fā)者、有效期

2、驗(yàn)證是否在信任列表中

2、驗(yàn)證合法性

驗(yàn)證證書(shū)時(shí)，客戶端讀取證書(shū)中的相關(guān)的明文信息，采用相同的散列函數(shù)計(jì)算得到信息摘要，然后，利用對(duì)應(yīng)CA的公鑰(從本地取出)解密簽名數(shù)據(jù)，對(duì)比證書(shū)的信息摘要，如果一致，則可以確認(rèn)證書(shū)的合法性，即公鑰合法;

證書(shū)內(nèi)容：

申請(qǐng)者公鑰、申請(qǐng)者的組織信息和個(gè)人信息、簽發(fā)機(jī)構(gòu) CA的信息、有效時(shí)間、證書(shū)序列號(hào)等信息的明文，同時(shí)包含一個(gè)簽名;

簽名的產(chǎn)生：使用散列函數(shù)計(jì)算公開(kāi)的明文信息的信息摘要，然后，采用 CA的私鑰對(duì)信息摘要進(jìn)行加密，密文即簽名。

   

Tips;

1、Client使用Server發(fā)送的公鑰加密數(shù)據(jù)，將加密數(shù)據(jù)發(fā)送給Server，Server使用私鑰進(jìn)行解密，是為非對(duì)稱加密

2、當(dāng)Client、Server均掌握了協(xié)商密鑰enc_key后，雙方均用該密鑰進(jìn)行加密、解密，是為對(duì)稱加密

加密算法概述

TLS/SSL的功能實(shí)現(xiàn)主要依賴于三類基本算法：散列函數(shù) Hash、對(duì)稱加密和非對(duì)稱加密，其利用非對(duì)稱加密實(shí)現(xiàn)身份認(rèn)證和密鑰協(xié)商，對(duì)稱加密算法采用協(xié)商的密鑰對(duì)數(shù)據(jù)加密，基于散列函數(shù)驗(yàn)證信息的完整性。

1、對(duì)稱加密

有流式、分組兩種，加密和解密都是使用的同一個(gè)密鑰。

例如：DES、AES-GCM、ChaCha20-Poly1305等

2、非對(duì)稱加密

加密使用的密鑰和解密使用的密鑰是不相同的，分別稱為：公鑰、私鑰，公鑰和算法都是公開(kāi)的，私鑰是保密的。非對(duì)稱加密算法性能較低，但是安全性超強(qiáng)，由于其加密特性，非對(duì)稱加密算法能加密的數(shù)據(jù)長(zhǎng)度也是有限的。

例如：RSA、DSA、ECDSA、 DH、ECDHE

3、哈希算法

將任意長(zhǎng)度的信息轉(zhuǎn)換為較短的固定長(zhǎng)度的值，通常其長(zhǎng)度要比信息小得多，且算法不可逆。

例如：MD5、SHA-1、SHA-2、SHA-256 等

4、數(shù)字簽名

簽名就是在信息的后面再加上一段內(nèi)容（信息經(jīng)過(guò)hash后的值），可以證明信息沒(méi)有被修改過(guò)。hash值一般都會(huì)加密后（也就是簽名）再和信息一起發(fā)送，以保證這個(gè)hash值不被修改。

雙向驗(yàn)證：

服務(wù)器也可以要求驗(yàn)證客戶端，即雙向認(rèn)證，可以在過(guò)程2要發(fā)送 client_certificate_request 信息，客戶端在過(guò)程4中先發(fā)送 client_certificate與certificate_verify_message 信息，證書(shū)的驗(yàn)證方式基本相同，certificate_verify_message 是采用client的私鑰加密的一段基于已經(jīng)協(xié)商的通信信息得到數(shù)據(jù)，服務(wù)器可以采用對(duì)應(yīng)的公鑰解密并驗(yàn)證。

看完上述內(nèi)容，你們掌握HTTPS通信是什么原理的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！

當(dāng)前文章：HTTPS通信是什么原理
網(wǎng)站鏈接：http://chinadenli.net/article44/ipsdee.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供面包屑導(dǎo)航、營(yíng)銷型網(wǎng)站建設(shè)、自適應(yīng)網(wǎng)站、用戶體驗(yàn)、搜索引擎優(yōu)化、軟件開(kāi)發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)