試想?下，如果?客在??登陸?付寶的時候獲取到??賬?余額，甚?獲取到??的?付密碼，那太可怕了。

在互聯(lián)?上，明?傳輸是?較危險的事情 ?。?！

HTTPS就是在HTTP的基礎(chǔ)上進(jìn)?了加密，進(jìn)?步的來保證??的信息安全~

三、常見的加密方式

1. 對稱加密

• 采?單鑰密碼系統(tǒng)的加密?法，同?個密鑰可以同時?作信息的加密和解密，這種加密?法稱為對稱加密，也稱為單密鑰加密，特征：加密和解密所?的密鑰是相同的
• 常?對稱加密算法(了解)：DES、3DES、AES、TDEA、Blowfish、RC2等
• 特點：算法公開、計算量?、加密速度快、加密效率?

對稱加密其實就是通過同?個"密鑰"，把明?加密成密?，并且也能把密?解密成明?。
一個簡單的對稱加密，按位異或

假設(shè)明?a=1234,密鑰key=8888則加密a^key得到的密?b為9834
然后針對密?9834再次進(jìn)?運算b^key，得到的就是原來的明?1234，(對于字符串的對稱加密也是同理，每?個字符都可以表?成?個數(shù)字)
當(dāng)然,按位異或只是最簡單的對稱加密，HTTPS中并不是使?按位異或。

2 . 非對稱加密

? 需要兩個密鑰來進(jìn)?加密和解密，這兩個密鑰是公開密鑰public key，簡稱公鑰）和私有密鑰
（private key，簡稱私鑰）。
? 常??對稱加密算法(了解)：RSA，DSA，ECDSA
? 特點：算法強度復(fù)雜、安全性依賴于算法與密鑰但是由于其算法復(fù)雜，?使得加密解密速度沒有對稱加密解密的速度快。

?對稱加密要?到兩個密鑰，?個叫做"公鑰"，?個叫做"私鑰"。

公鑰和私鑰是配對的.最?的缺點就是運算速度?常慢，?對稱加密要慢很多。

? 通過公鑰對明?加密,變成密?
? 通過私鑰對密?解密,變成明?
也可以反著?
? 通過私鑰對明?加密，變成密?
? 通過公鑰對密?解密，變成明?

?對稱加密的數(shù)學(xué)原理?較復(fù)雜，涉及到?些數(shù)論相關(guān)的知識，這?舉?個簡單的?活上的例?:
A要給B?些重要的?件，但是B可能不在，于是A和B提前做出約定：
B說:我桌?上有個盒?，然后我給你?把鎖，你把?件放盒???鎖鎖上，然后我回頭拿著鑰匙來開鎖取?件，在這個場景中,這把鎖就相當(dāng)于公鑰,鑰匙就是私鑰.公鑰給誰都?(不怕泄露),但是私鑰只有B??持有,持有私鑰的?才能解密.

四、數(shù)據(jù)摘要(指紋)&&數(shù)字簽名

• 數(shù)字指紋(數(shù)據(jù)摘要),其基本原理是利?單向散列函數(shù)(Hash函數(shù))對信息進(jìn)?運算,?成?串固定?度的數(shù)字摘要。數(shù)字指紋并不是?種加密機制,但可以?來判斷數(shù)據(jù)有沒有被竄改。

• 摘要常?算法：有MD5、SHA1、SHA256、SHA512等，算法把?限的映射成有限，因此可能會有碰撞（兩個不同的信息，算出的摘要相同，但是概率?常低）

• 摘要特征：和加密算法的區(qū)別是，摘要嚴(yán)格意義不是加密，因為沒有解密，只不過從摘要很難反推原信息，通常?來進(jìn)?數(shù)據(jù)對?

數(shù)字簽名

摘要經(jīng)過加密，就得到數(shù)字簽名（后?細(xì)說）

五、HTTPS的工作過程探究

既然要保證數(shù)據(jù)安全,就需要進(jìn)?"加密".?絡(luò)傳輸中不再直接傳輸明?了,?是加密之后的"密?".

加密的?式有很多,但是整體可以分成兩?類:對稱加密和?對稱加密

方案（1）：只使用對稱加密

如果通信雙?都各?持有同?個密鑰X，且沒有別?知道，這兩?的通信安全當(dāng)然是可以被保證的（除?密鑰被破解）

引?對稱加密之后，即使數(shù)據(jù)被截獲，由于?客不知道密鑰是啥，因此就?法進(jìn)?解密，也就不知道請求的真實內(nèi)容是啥了

但事情沒這么簡單.服務(wù)器同?時刻其實是給很多客?端提供服務(wù)的，這么多客?端，每個??的秘鑰都必須是不同的(如果是相同那密鑰就太容易擴散了,?客就也能拿到了)，因此服務(wù)器就需要維護每個客?端和每個密鑰之間的關(guān)聯(lián)關(guān)系，這也是個很?煩的事情~

?較理想的做法，就是能在客?端和服務(wù)器建?連接的時候,雙?協(xié)商確定這次的密鑰是啥~

但是如果直接把密鑰明?傳輸,那么?客也就能獲得密鑰了~~此時后續(xù)的加密操作就形同虛設(shè)了，
因此密鑰的傳輸也必須加密傳輸!

但是要想對密鑰進(jìn)?對稱加密,就仍然需要先協(xié)商確定?個"密鑰的密鑰".這就成了"先有雞還是先有蛋"的問題了.此時密鑰的傳輸再?對稱加密就?不通了.

方案（2）：只使用非對稱加密

鑒于?對稱加密的機制，如果服務(wù)器先把公鑰以明??式傳輸給瀏覽器，之后瀏覽器向服務(wù)器傳數(shù)據(jù)前都先?這個公鑰加密好再傳，從客?端到服務(wù)器信道似乎是安全的(有安全問題)，因為只有服務(wù)器有相應(yīng)的私鑰能解開公鑰加密的數(shù)據(jù)。

但是服務(wù)器到瀏覽器的這條路怎么保障安全？

如果服務(wù)器?它的私鑰加密數(shù)據(jù)傳給瀏覽器，那么瀏覽器?公鑰可以解密它，?這個公鑰是?開始通過明?傳輸給瀏覽器的，若這個公鑰被中間?劫持到了,那他也能?該公鑰解密服務(wù)器傳來的信息了。

方案（3）：雙方都使用非對稱加密

1. 服務(wù)端擁有公鑰S與對應(yīng)的私鑰S’，客?端擁有公鑰C與對應(yīng)的私鑰C’

2. 客?和服務(wù)端交換公鑰

3. 客?端給服務(wù)端發(fā)信息：先?S對數(shù)據(jù)加密，再發(fā)送，只能由服務(wù)器解密，因為只有服務(wù)器有私鑰S’

4. 服務(wù)端給客?端發(fā)信息：先?C對數(shù)據(jù)加密，在發(fā)送，只能由客?端解密，因為只有客?端有私鑰C’

這樣貌似也?啊，但是

• 效率太低
• 依舊有安全問題

方案（4）：非對稱加密+對稱加密

先解決效率問題

• 服務(wù)端具有?對稱公鑰S和私鑰S’
• 客?端發(fā)起https請求，獲取服務(wù)端公鑰S
• 客?端在本地?成對稱密鑰C,通過公鑰S加密，發(fā)送給服務(wù)器。
• 由于中間的?絡(luò)設(shè)備沒有私鑰,即使截獲了數(shù)據(jù),也?法還原出內(nèi)部的原?,也就?法獲取到對稱密鑰(真的嗎？)
• 服務(wù)器通過私鑰S’解密,還原出客?端發(fā)送的對稱密鑰C.并且使?這個對稱密鑰加密給客?端返回的響應(yīng)數(shù)據(jù).
• 后續(xù)客?端和服務(wù)器的通信都只?對稱加密即可.由于該密鑰只有客?端和服務(wù)器兩個主機知道,其
  他主機/設(shè)備不知道密鑰即使截獲數(shù)據(jù)也沒有意義。

由于對稱加密的效率??對稱加密?很多,因此只是在開始階段協(xié)商密鑰的時候使??對稱加密,后
續(xù)的傳輸仍然使?對稱加密.

雖然上?已經(jīng)?較接近答案了，但是依舊有安全問題
?案2，?案3，?案4都存在?個問題，如果最開始，中間?就已經(jīng)開始攻擊了呢？

中間人攻擊 —針對上面的場景

? Man-in-the-MiddleAttack，簡稱“MITM攻擊”
確實，在?案2/3/4中，客?端獲取到公鑰S之后，對客?端形成的對稱秘鑰X?服務(wù)端給客?端的公鑰S進(jìn)?加密，中間?即使竊取到了數(shù)據(jù)，此時中間?確實?法解出客?端形成的密鑰X，因為只有服務(wù)器有私鑰S’
但是中間?的攻擊，如果在最開始握?協(xié)商的時候就進(jìn)?了，那就不?定了，假設(shè)hacker已經(jīng)成功成為中間?

1. 服務(wù)器具有?對稱加密算法的公鑰S，私鑰S’
2. 中間?具有?對稱加密算法的公鑰M，私鑰M’
3. 客?端向服務(wù)器發(fā)起請求，服務(wù)器明?傳送公鑰S給客?端
4. 中間?劫持?jǐn)?shù)據(jù)報?，提取公鑰S并保存好，然后將被劫持報?中的公鑰S替換成為??的公鑰M，并將偽造報?發(fā)給客?端
5. 客?端收到報?，提取公鑰M(??當(dāng)然不知道公鑰被更換過了)，??形成對稱秘鑰X，?公鑰M加密X，形成報?發(fā)送給服務(wù)器
6. 中間?劫持后，直接???的私鑰M’進(jìn)?解密，得到通信秘鑰X，再?曾經(jīng)保存的服務(wù)端公鑰S加密后，將報?推送給服務(wù)器
7. 服務(wù)器拿到報?，???的私鑰S’解密，得到通信秘鑰X
8. 雙?開始采?X進(jìn)?對稱加密，進(jìn)?通信。但是?切都在中間?的掌握中，劫持?jǐn)?shù)據(jù)，進(jìn)?竊聽甚?修改，都是可以的

上?的攻擊?案，同樣適?于?案2，?案3
問題本質(zhì)出在哪?了呢？客?端?法確定收到的含有公鑰的數(shù)據(jù)報?，就是?標(biāo)服務(wù)器發(fā)送過來的！

這個時候就需要新的解決方案了，下面來引入證書。

六、什么是證書

引入證書

CA認(rèn)證

服務(wù)端在使?HTTPS前，需要向CA機構(gòu)申領(lǐng)?份數(shù)字證書，數(shù)字證書?含有證書申請者信息、公鑰信息等。服務(wù)器把證書傳輸給瀏覽器，瀏覽器從證書?獲取公鑰就?了，證書就如?份證，證明服務(wù)端公鑰的權(quán)威性.

這個證書可以理解成是?個結(jié)構(gòu)化的字符串,??包含了以下信息:

• 證書發(fā)布機構(gòu)
• 證書有效期
• 公鑰
• 證書所有者
• 簽名
• …

需要注意的是：申請證書的時候，需要在特定平臺?成查，會同時?成?對?密鑰對?，即公鑰和私鑰。這對密鑰對?就是?來在?絡(luò)通信中進(jìn)?明?加密以及數(shù)字簽名的。

其中公鑰會隨著CSR?件，?起發(fā)給CA進(jìn)?權(quán)威認(rèn)證，私鑰服務(wù)端??保留，?來后續(xù)進(jìn)?通信（其實主要就是?來交換對稱秘鑰）

?般認(rèn)證過程很繁瑣，?絡(luò)各種提供證書申請的服務(wù)商，?般真的需要，直接找平臺解決就?

理解數(shù)據(jù)簽名

簽名的形成是基于?對稱加密算法的，注意，?前暫時和https沒有關(guān)系，不要和https中的公鑰私鑰搞混了

當(dāng)服務(wù)端申請CA證書的時候，CA機構(gòu)會對該服務(wù)端進(jìn)?審核，并專?為該?站形成數(shù)字簽名，過程如
下：

1. CA機構(gòu)擁有?對稱加密的私鑰A和公鑰A’
2. CA機構(gòu)對服務(wù)端申請的證書明?數(shù)據(jù)進(jìn)?hash，形成數(shù)據(jù)摘要
3. 然后對數(shù)據(jù)摘要?CA私鑰A’加密，得到數(shù)字簽名S

服務(wù)端申請的證書明?和數(shù)字簽名S共同組成了數(shù)字證書，這樣?份數(shù)字證書就可以頒發(fā)給服務(wù)端了

七、最終方案

?對稱加密+對稱加密+證書認(rèn)證

在客?端和服務(wù)器剛?建?連接的時候,服務(wù)器給客?端返回?個證書，證書包含了之前服務(wù)端的公鑰,也包含了?站的?份信息.

客?端進(jìn)?認(rèn)證

當(dāng)客?端獲取到這個證書之后,會對證書進(jìn)?校驗(防?證書是偽造的).

• 判定證書的有效期是否過期
• 判定證書的發(fā)布機構(gòu)是否受信任(操作系統(tǒng)中已內(nèi)置的受信任的證書發(fā)布機構(gòu)).
• 驗證證書是否被篡改:從系統(tǒng)中拿到該證書發(fā)布機構(gòu)的公鑰,對簽名解密,得到?個hash值(稱為數(shù)據(jù)摘要),設(shè)為hash1.然后計算整個證書的hash值,設(shè)為hash2.對?hash1和hash2是否相等.如果相等,則說明證書是沒有被篡改過的.

查看瀏覽器的受信任證書發(fā)布機構(gòu)

選擇"設(shè)置",搜索"證書管理",即可看到以下界?.(如果沒有，在隱私設(shè)置和安全性->安全??找找)

八、問題解答

中間?有沒有可能篡改該證書？

• 中間?篡改了證書的明?
• 由于他沒有CA機構(gòu)的私鑰，所以?法hash之后?私鑰加密形成簽名，那么也就沒法辦法對篡改后的證書形成匹配的簽名
• 如果強?篡改，客?端收到該證書后會發(fā)現(xiàn)明?和簽名解密后的值不?致，則說明證書已被篡改，證書不可信，從?終?向服務(wù)器傳輸信息，防?信息泄露給中間?

中間?整個掉包證書？

• 因為中間?沒有CA私鑰，所以?法制作假的證書(為什么？)
• 所以中間?只能向CA申請真證書，然后???申請的證書進(jìn)?掉包
• 這個確實能做到證書的整體掉包，但是別忘記，證書明?中包含了域名等服務(wù)端認(rèn)證信息，如果整體掉包，客?端依舊能夠識別出來。
• 永遠(yuǎn)記?。褐虚g?沒有CA私鑰，所以對任何證書都?法進(jìn)?合法修改，包括??的

為什么摘要內(nèi)容在?絡(luò)傳輸?shù)臅r候?定要加密形成簽名?

常?的摘要算法有:MD5和SHA系列

以MD5為例,我們不需要研究具體的計算簽名的過程,只需要了解MD5的特點:

• 定?:?論多?的字符串,計算出來的MD5值都是固定?度(16字節(jié)版本或者32字節(jié)版本)
• 分散:源字符串只要改變?點點,最終得到的MD5值都會差別很?.
• 不可逆:通過源字符串?成MD5很容易,但是通過MD5還原成原串理論上是不可能的.

正因為MD5有這樣的特性,我們可以認(rèn)為如果兩個字符串的MD5值相同,則認(rèn)為這兩個字符串相同.
理解判定證書篡改的過程:(這個過程就好?判定這個?份證是不是偽造的?份證)

假設(shè)我們的證書只是?個簡單的字符串hello,對這個字符串計算hash值(?如md5),結(jié)果是BC4B2A76B9719D91

如果hello中有任意的字符被篡改了,?如變成了hella,那么計算的md5值就會變化很?.
BDBD6F9CF51F2FD8

然后我們可以把這個字符串hello和哈希值BC4B2A76B9719D91從服務(wù)器返回給客?端,此時客?端如何驗證hello是否是被篡改過?

那么就只要計算hello的哈希值,看看是不是BC4B2A76B9719D91即可.

但是還有個問題,如果?客把hello篡改了,同時也把哈希值重新計算下,客?端就分辨不出來了呀.

所以被傳輸?shù)墓Ｖ挡荒軅鬏斆?,需要傳輸密?.

所以，對證書明?(這?就是“hello”)hash形成散列摘要，然后CA使???的私鑰加密形成簽名，將hello和加密的簽名合起來形成CA證書，頒發(fā)給服務(wù)端，當(dāng)客?端請求的時候，就發(fā)送給客?端，中間?截獲了，因為沒有CA私鑰，就?法更改或者整體掉包，就能安全的證明，證書的合法性。

最后，客?端通過操作系統(tǒng)?已經(jīng)存的了的證書發(fā)布機構(gòu)的公鑰進(jìn)?解密,還原出原始的哈希值,再進(jìn)?校驗.

為什么簽名不直接加密，?是要先hash形成摘要?

縮?簽名密?的?度,加快數(shù)字簽名的驗證簽名的運算速度

完整流程

總結(jié)

HTTPS?作過程中涉及到的密鑰有三組.

第?組(?對稱加密):?于校驗證書是否被篡改.服務(wù)器持有私鑰(私鑰在形成CSR?件與申請證書時獲得),客?端持有公鑰(操作系統(tǒng)包含了可信的CA認(rèn)證機構(gòu)有哪些,同時持有對應(yīng)的公鑰).服務(wù)器在客?端請求是，返回攜帶簽名的證書.客?端通過這個公鑰進(jìn)?證書驗證，保證證書的合法性，進(jìn)?步保證證書中攜帶的服務(wù)端公鑰權(quán)威性。

第?組(?對稱加密):?于協(xié)商?成對稱加密的密鑰.客?端?收到的CA證書中的公鑰(是可被信任的)給隨機?成的對稱加密的密鑰加密,傳輸給服務(wù)器,服務(wù)器通過私鑰解密獲取到對稱加密密鑰.

第三組(對稱加密):客?端和服務(wù)器后續(xù)傳輸?shù)臄?shù)據(jù)都通過這個對稱密鑰加密解密.

其實?切的關(guān)鍵都是圍繞這個對稱加密的密鑰.其他的機制都是輔助這個密鑰?作的.文章來源地址http://www.zghlxwxcb.cn/news/detail-470589.html

1. 第?組?對稱加密的密鑰是為了讓客?端把這個對稱密鑰傳給服務(wù)器.
2. 第?組?對稱加密的密鑰是為了讓客?端拿到第?組?對稱加密的公鑰.

到了這里，關(guān)于【Linux網(wǎng)絡(luò)編程】HTTPS協(xié)議原理的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！