HTTPS協(xié)議和HTTP協(xié)議的區(qū)別

HTTPS 協(xié)議和 HTTP 都是應(yīng)用層協(xié)議，不過(guò)HTTP 協(xié)議內(nèi)容在傳輸時(shí)都是以文本方式進(jìn)行明文傳輸?shù)?，這就可能導(dǎo)致在傳輸過(guò)程中，數(shù)據(jù)被泄漏和篡改等問(wèn)題。所以HTTPS 協(xié)議是在HTTP 基礎(chǔ)上引入了一個(gè)加密層。

HTTPS （全稱：Hypertext Transfer Protocol Secure ），是以安全為目標(biāo)的 HTTP 通道，在HTTP的基礎(chǔ)上通過(guò)傳輸加密和身份認(rèn)證保證了傳輸過(guò)程的安全性 。

什么是“加密” 和“解密”

• 加密就是把明文經(jīng)過(guò)一系列變化（要傳輸?shù)男畔ⅲ?變成密文。
• 解密就是把密文再經(jīng)過(guò)一系列的變化，變成明文。

在加密和解密的過(guò)程中，通常需要用到一個(gè)或多個(gè)中間的數(shù)據(jù)，輔助進(jìn)行這個(gè)過(guò)程，這樣的數(shù)據(jù)稱為密鑰。

加密和解密的小故事

對(duì)傳輸?shù)臄?shù)據(jù)進(jìn)行加密和解密并不是計(jì)算機(jī)學(xué)科獨(dú)有的，只要是重要的信息，那就有加密的必要性。

五言律詩(shī)秘鑰加密法
北宋時(shí)期的《武經(jīng)總要》記錄了我國(guó)最早的軍事密碼本。

在軍隊(duì)發(fā)兵前，將戰(zhàn)場(chǎng)上經(jīng)常出現(xiàn)的40種戰(zhàn)斗情況編成序號(hào)，例如：1 請(qǐng)弓、2 請(qǐng)箭、3 請(qǐng)刀、4 請(qǐng)甲、5 請(qǐng)槍旗、6 請(qǐng)鍋幕、7 請(qǐng)馬、8
請(qǐng)衣賜、9 請(qǐng)糧料、10 請(qǐng)草料……

指揮部門與戰(zhàn)斗部門約定一首沒(méi)有重復(fù)文字的五言律詩(shī)，將其中的每一個(gè)字和這40種情況一一對(duì)應(yīng)，對(duì)應(yīng)順序隨機(jī)排列，前線負(fù)責(zé)戰(zhàn)斗的將領(lǐng)會(huì)講對(duì)應(yīng)關(guān)系爛熟于心，在戰(zhàn)斗過(guò)程中，只需幾個(gè)字就能傳遞大量的信息。

這種加密方法，敵人是非常難破譯的，五言律詩(shī)在這其中起到的是秘鑰的作用。

加密解密到如今已經(jīng)發(fā)展成?個(gè)獨(dú)立的學(xué)科:密碼學(xué)
而密碼學(xué)的奠基人,也正是計(jì)算機(jī)科學(xué)的祖師爺之?,艾倫·麥席森·圖靈

艾倫·麥席森·圖靈年少有為,不光奠定了計(jì)算機(jī),人工智能,密碼學(xué)的基礎(chǔ),并且在二戰(zhàn)中大破德軍的Enigma機(jī),使盟軍占盡情報(bào)優(yōu)勢(shì),才能扭轉(zhuǎn)戰(zhàn)局反敗為勝.但是因?yàn)?些原因,他遭到英國(guó)皇室的迫害,41歲就英年早逝了。
計(jì)算機(jī)領(lǐng)域中的最高榮譽(yù)就是以他名字命名的"圖靈獎(jiǎng)"。

為什么要進(jìn)行加密？

在互聯(lián)網(wǎng)上進(jìn)行信息加密的重要性肯定是不言而喻的，加密可以在一定程度上保護(hù)用戶的個(gè)人隱私，財(cái)產(chǎn)安全等。如果沒(méi)有信息傳輸?shù)募用芗夹g(shù)，那么每個(gè)人的信息就會(huì)在互聯(lián)網(wǎng)上“裸奔”。試想一下，如果一個(gè)黑客能隨意獲取你的支付寶，微信支付密碼等個(gè)人信息，從事一些違法行為，那網(wǎng)絡(luò)世界是非常可怕的。

這里舉一個(gè)客戶端和服務(wù)器在傳輸數(shù)據(jù)的過(guò)程中，因?yàn)閭鬏敂?shù)據(jù)沒(méi)有加密，被劫持（數(shù)據(jù)被篡改）的例子。

臭名昭著的“運(yùn)營(yíng)商劫持”事件

下載一個(gè)天天動(dòng)聽(tīng)
未被劫持的效果,點(diǎn)擊下載按鈕,就會(huì)彈出天天動(dòng)聽(tīng)的下載鏈接。

已被劫持的效果,點(diǎn)擊下載按鈕，會(huì)彈出QQ瀏覽器的下載鏈接

由于我們通過(guò)網(wǎng)絡(luò)傳輸?shù)娜魏蔚臄?shù)據(jù)包都會(huì)經(jīng)過(guò)運(yùn)營(yíng)商的網(wǎng)絡(luò)設(shè)備(路由器,交換機(jī)等),那么運(yùn)營(yíng)商的網(wǎng)絡(luò)設(shè)備就可以解析出你傳輸?shù)臄?shù)據(jù)內(nèi)容,并進(jìn)行篡改。

點(diǎn)擊"下載按鈕",其實(shí)就是在給服務(wù)器發(fā)送了?個(gè)HTTP請(qǐng)求,獲取到的HTTP響應(yīng)其實(shí)就包含了該APP的下載鏈接.運(yùn)營(yíng)商劫持之后,就發(fā)現(xiàn)這個(gè)請(qǐng)求是要下載天天動(dòng)聽(tīng),那么就自動(dòng)的把交給用戶的響應(yīng)給篡改成"QQ瀏覽器"的下載地址了。

還有就是大家平時(shí)在瀏覽網(wǎng)頁(yè)的時(shí)候，會(huì)莫名其妙彈出一些廣告，這可能不是該網(wǎng)站的問(wèn)題，而是你向服務(wù)端請(qǐng)求瀏覽該網(wǎng)頁(yè)的時(shí)候，在數(shù)據(jù)傳輸?shù)倪^(guò)程中，被劫持了，在返回?cái)?shù)據(jù)時(shí)，給你注入了一些廣告。

因?yàn)閔ttp的內(nèi)容是明文傳輸?shù)?，明文?shù)據(jù)會(huì)經(jīng)過(guò)路由器、wifi熱點(diǎn)、通信服務(wù)運(yùn)營(yíng)商、代理服務(wù)器等多個(gè)物理節(jié)點(diǎn)，如果信息在傳輸過(guò)程中被劫持，傳輸?shù)膬?nèi)容就完全暴露了。劫持者還可以篡改傳輸?shù)男畔⑶也槐浑p方察覺(jué)，這就是中間人攻擊 ，所以我們才需要對(duì)信息進(jìn)行加密。

所以，平時(shí)在下載應(yīng)該的時(shí)候最好去應(yīng)用官網(wǎng)下載，正規(guī)的官網(wǎng)都會(huì)使用一些加密技術(shù)和一些反劫持措施。比如，HTTPS加密連接：許多應(yīng)用官網(wǎng)采用了HTTPS協(xié)議，使用SSL/TLS加密通信，這可以防止運(yùn)營(yíng)商對(duì)網(wǎng)站流量進(jìn)行劫持和篡改。HTTPS協(xié)議確保通信的安全性和完整性。

不止運(yùn)營(yíng)商可以劫持,其他的黑客也可以用類似的手段進(jìn)行劫持,來(lái)竊取用戶隱私信息,或者篡改內(nèi)容。

在互聯(lián)網(wǎng)上,明文傳輸是比較危險(xiǎn)的事情!!!
HTTPS就是在HTTP的基礎(chǔ)上進(jìn)行了加密,進(jìn)?步的來(lái)保證用戶的信息安全。

常見(jiàn)加密方式

為了能很好地對(duì)HTTPS的工作過(guò)程進(jìn)行探究，接下來(lái)先介紹一些相關(guān)知識(shí)。

對(duì)稱加密

• 采用單鑰密碼系統(tǒng)的加密方法，同一個(gè)密鑰可以同時(shí)用作信息的加密和解密，這種加密方式稱為對(duì)稱加密，特征：加密和解密所用的密鑰是相同的。
• 常見(jiàn)對(duì)稱加密算法：DES,3DES,AES,TDEA,Blowfish,RC2等
• 特點(diǎn)：算法公開、計(jì)算量小、加密速度快、加密效率高。

對(duì)稱加密其實(shí)就是通過(guò)同一個(gè)密鑰，把明文變成密文，再通過(guò)這個(gè)密鑰也能把密碼變成明文。

一個(gè)簡(jiǎn)單的對(duì)稱加密：按位異或
假設(shè) 明文 a = 1234 密鑰 k = 8888
a ^ k = 9834 ，此時(shí)9834是密文
再把9834 ^ 8888 ,得到的明文就是1234
此時(shí)的k 既能加密又能解密
當(dāng)然，這是最簡(jiǎn)單的對(duì)稱加密例子，實(shí)際中肯定比這更復(fù)雜

非對(duì)稱加密

• 需要兩個(gè)密鑰來(lái)進(jìn)行加密和解密，這兩個(gè)密鑰是公開密鑰（公鑰），和私有密鑰（私鑰）。

• 常見(jiàn)非對(duì)稱加密算法：RSA、DSA、ECDSA

• 特點(diǎn)：算法強(qiáng)度復(fù)雜、安全性依賴于算法與密鑰但是由于其算法復(fù)雜，而使得加密和解密速度沒(méi)有對(duì)稱加密解密的速度快。

• 通過(guò)公鑰對(duì)明文加密，變成密文

• 通過(guò)私鑰對(duì)密鑰解密，變成明文

也可以反著用

• 通過(guò)私鑰對(duì)明文加密，變成密文
• 通過(guò)公鑰對(duì)密鑰解密，變成明文

非對(duì)稱加密的數(shù)學(xué)原理比較復(fù)雜,涉及到?些數(shù)論相關(guān)的知識(shí)，這里舉?個(gè)簡(jiǎn)單的生活上的例?。
A要給B?些重要的文件,但是B可能不在。于是A和B提前做出約定:
B說(shuō):我桌子上有個(gè)盒子,然后我給你?把鎖,你把文件放盒子里用鎖鎖上,然后我回頭拿著鑰匙來(lái)開鎖取文件。
在這個(gè)場(chǎng)景中,這把鎖就相當(dāng)于公鑰,鑰匙就是私鑰。公鑰給誰(shuí)都行(不怕泄露),但是私鑰只有B自己持有.持有私鑰的人才能解密。

數(shù)據(jù)摘要

• 數(shù)據(jù)摘要（數(shù)字指紋），其基本原理就是用單向散列函數(shù)（Hash函數(shù)），對(duì)信息進(jìn)行運(yùn)算，生成一串固定長(zhǎng)度的數(shù)據(jù)摘要。這并不是一種加密加密，而是用來(lái)判斷有沒(méi)有被篡改
• 摘要常見(jiàn)算法：有MD5、SHA1、SHA256、SHA512等，算法把無(wú)限的映射成有限，因此可能會(huì)有碰撞（兩個(gè)不同的信息，算出的摘要相同，但是概率非常低）

哈希不可逆
哈希函數(shù)被稱為不可逆函數(shù)，是因?yàn)樗哪婧瘮?shù)難以計(jì)算。

當(dāng)我們給定一個(gè)輸入，通過(guò)哈希函數(shù)可以生成相應(yīng)的哈希值。但是，從給定的哈希值反推回原始輸入幾乎是不可能的。這是因?yàn)楣：瘮?shù)設(shè)計(jì)時(shí)候會(huì)考慮到散列算法的安全性，而故意進(jìn)行了復(fù)雜性的增加，使其難以逆向計(jì)算回原始數(shù)據(jù)。

哈希函數(shù)的主要目的是提供數(shù)據(jù)的唯一標(biāo)識(shí)和用于驗(yàn)證數(shù)據(jù)完整性的校驗(yàn)值。它們廣泛應(yīng)用于密碼學(xué)、數(shù)據(jù)摘要、數(shù)字簽名等領(lǐng)域。

盡管哈希函數(shù)不可逆，也就是無(wú)法準(zhǔn)確地從哈希值回推出原輸入，但是在實(shí)際應(yīng)用中，可以使用暴力破解或碰撞攻擊等技術(shù)來(lái)嘗試破解哈希值，特別是對(duì)于較弱的哈希函數(shù)和短哈希值來(lái)說(shuō)。因此，在選擇哈希函數(shù)時(shí)，需要選擇具有足夠的安全性和抗碰撞性能的函數(shù)來(lái)保護(hù)數(shù)據(jù)的安全性。

• 摘要特征：和加密算法的區(qū)別是，摘要嚴(yán)格意義不是加密，因?yàn)闆](méi)有解密，只不過(guò)從摘要很難反推原信息，通常用來(lái)進(jìn)行數(shù)據(jù)對(duì)比

數(shù)字簽名

摘要經(jīng)過(guò)加密就能得到數(shù)字簽名（文章后面詳細(xì)介紹）

HTTPS工作過(guò)程探究

既然要保證數(shù)據(jù)安全, 就需要進(jìn)行 “加密”.
網(wǎng)絡(luò)傳輸中不再直接傳輸明文了, 而是加密之后的 “密文”.
加密的方式有很多, 但是整體可以分成兩大類: 對(duì)稱加密 和 非對(duì)稱加密

方案 1 ： 只使用對(duì)稱加密

如果通信雙方都使用一把密鑰，且沒(méi)有其他人知道，這兩方的通信安全當(dāng)然是可以被保證的（除非密鑰被破解）

引入對(duì)稱加密以后，即使數(shù)據(jù)被截獲，黑客也不知道密鑰是什么，因此無(wú)法進(jìn)行解密。
但是實(shí)際情況并沒(méi)有這么簡(jiǎn)單，我們知道，服務(wù)器是要為很多客戶端服務(wù)的。那么如果采用上面的做法，每臺(tái)客戶端和服務(wù)器用的密鑰必須是不同的（如果密鑰都是相同的話，那么黑客就能利用這相同密鑰截獲并解密其他客戶端的請(qǐng)求了）。因此服務(wù)器就要維護(hù)每個(gè)客戶端和服務(wù)器的密鑰的關(guān)聯(lián)關(guān)系，這是非常麻煩的。

比較理想的做法,就是能在客戶端和服務(wù)器建立連接的時(shí)候,雙方協(xié)商確定這次的密鑰是什么。

但是問(wèn)題來(lái)了，先不管服務(wù)器是只為一臺(tái)客戶端服務(wù)，還是為多臺(tái)客戶端服務(wù)。服務(wù)器要怎么安全地把密鑰傳輸給客戶端？
如果把密鑰進(jìn)行明文傳輸給客戶端，那么黑客也能截獲。
因此該密鑰還是要加密，如果該密鑰還是對(duì)稱加密，該怎么把密鑰的密鑰傳輸給客戶端？因此這種只使用對(duì)稱加密方式存在的問(wèn)題是無(wú)法把約定好的密鑰通過(guò)網(wǎng)絡(luò)的方式安全地交給對(duì)方。

方案2 ： 只使用非對(duì)稱加密

這里只使用非對(duì)稱加密，此時(shí)假如只有服務(wù)器擁有私鑰，而公鑰是公開的，意外著客戶端和黑客都有能力拿到公鑰。
客戶端可以用公鑰進(jìn)行加密傳輸，此時(shí)就算被黑客截獲也沒(méi)關(guān)系，因?yàn)橹挥兴借€才能進(jìn)行解密，而私鑰只有服務(wù)器擁有，此時(shí)由客戶端向服務(wù)器傳輸數(shù)據(jù)的過(guò)程似乎是安全的（這里還是有安全問(wèn)題，后面會(huì)講）。
但是服務(wù)器到瀏覽器傳輸數(shù)據(jù)的過(guò)程無(wú)法保證安全。
如果服務(wù)器用公鑰加密，那么就不僅僅黑客無(wú)法解密，瀏覽器也無(wú)法解密，因?yàn)闆](méi)有私鑰。如果用私鑰進(jìn)行加密，那么公鑰就可以解密，雖然瀏覽器可以解密，但是黑客也有公鑰，也能解密。

方案 3 ：雙方都使用非對(duì)稱加密

方案2的解決方法很容易想到，那就是雙方都使用非對(duì)稱加密。

• 服務(wù)端擁有公鑰S和私鑰S’，客戶端擁有公鑰C和私鑰C’
• 服務(wù)端和黑客都能拿到公鑰C，客戶端和黑客都能拿到公鑰S
• 當(dāng)客戶端向服務(wù)端發(fā)送數(shù)據(jù)時(shí)，如方案2
• 當(dāng)服務(wù)端向客戶端發(fā)送數(shù)據(jù)時(shí)，先用公鑰C進(jìn)行加密，加密后的數(shù)據(jù)只有客戶端能進(jìn)行解密

但是這種做法 效率太低，更重要的還是有安全問(wèn)題。

方案 4 ： 對(duì)稱加密 + 非對(duì)稱加密

我們先來(lái)解決效率問(wèn)題，
在方案1中的的對(duì)稱加密方案效率是很高的，但是不能保證密鑰能安全送到對(duì)方手上。而非對(duì)稱加密方案可以做到只有擁有私鑰的客戶端或服務(wù)器能解密，但是效率不行。所以可以將這兩種方案結(jié)合起來(lái)。

• 服務(wù)端擁有公鑰S和私鑰S’，客戶端擁有密鑰C’。
• 客戶端和黑客都能獲取服務(wù)端的公鑰S
• 服務(wù)器用公鑰S加密自己的密鑰C’，發(fā)送給服務(wù)端，此時(shí)因?yàn)橹挥蟹?wù)端有私鑰S’，只有服務(wù)端能解密，黑客不能解密。
• 當(dāng)服務(wù)器解密以后，獲取到了客戶端的密鑰C’，之后就可以使用C’進(jìn)行加密通信了，黑客沒(méi)有密鑰C’，只有客戶端和服務(wù)器有密鑰C’，所以黑客即使劫持到也無(wú)法解密。

由于只是在開始協(xié)商密鑰的時(shí)候使用了非對(duì)稱加密，而后面可以一直使用對(duì)稱加密，所以效率提高了很多。

中間人攻擊

Man-in-the-MiddleAttack，簡(jiǎn)稱“MITM攻擊”

在不斷改正的方案中，從方案2的單向非對(duì)稱加密，到方案3的雙向非對(duì)稱加密，最后到方案4的對(duì)稱加密和非對(duì)稱加密結(jié)合的方式，我們討論的都是雙方在協(xié)商完密鑰之后，黑客再進(jìn)行劫持，試圖解密獲取信息，這樣黑客確實(shí)不能解密。

但是MITM攻擊，如果是在最開始握手協(xié)商的時(shí)候就進(jìn)行了，那上面的方案可能就沒(méi)用了，因?yàn)楹诳鸵呀?jīng)成為中間人。

我們拿方案4舉例

• 服務(wù)器具有非對(duì)稱加密算法的公鑰S和私鑰S’

• 中間人具有非對(duì)稱加密算法的公鑰M和私鑰M’

• 客戶端向服務(wù)器發(fā)起請(qǐng)求，服務(wù)器明文將公鑰S給送給客戶端

• 中間人劫持?jǐn)?shù)據(jù)報(bào)文，提取公鑰S并將其保存好，然后將被劫持報(bào)文中的公鑰S換成自己的公鑰M，并將偽造報(bào)文發(fā)送給客戶端
  

  • 客戶端收到報(bào)文后，提取到M（客戶端自然是不知道M是中間人的公鑰，以為是服務(wù)器的公鑰）直接用M對(duì)自己的對(duì)稱密鑰加密，形成報(bào)文發(fā)送給服務(wù)器。

  • 中間人劫持以后，直接用自己的私鑰M’進(jìn)行解密，獲取到客戶端的對(duì)稱加密的密鑰C’，再用曾經(jīng)保存的服務(wù)器的公鑰S進(jìn)行加密，將報(bào)文推送給服務(wù)器。

  • 服務(wù)器拿到報(bào)文，進(jìn)行用私鑰S’進(jìn)行解密后，得到通信密鑰C’。

  • 雙方開始采用密鑰C’進(jìn)行對(duì)稱加密，進(jìn)行通信。但是一切都在中間人的掌控之中，因?yàn)樗灿袑?duì)應(yīng)的密鑰C’，劫持后，可以解密，獲取到信息，可以篡改數(shù)據(jù)，甚至雙方都毫不知情。
    
    這種攻擊方式，同樣適用于方案2/3 。

問(wèn)題的本質(zhì)在于：客戶端無(wú)法確定自己收到的含有公鑰的數(shù)據(jù)報(bào)文，就是目標(biāo)服務(wù)器發(fā)來(lái)的。

引入證書

CA認(rèn)證

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

CA認(rèn)證，即電子認(rèn)證服務(wù) ，是指為電子簽名相關(guān)各方提供真實(shí)性、可靠性驗(yàn)證的活動(dòng)。
證書頒發(fā)機(jī)構(gòu)（CA, Certificate Authority）即頒發(fā)數(shù)字證書的機(jī)構(gòu)。是負(fù)責(zé)發(fā)放和管理數(shù)字證書的權(quán)威機(jī)構(gòu)，并作為電子商務(wù)交易中受信任的第三方，承擔(dān)公鑰體系中公鑰的合法性檢驗(yàn)的責(zé)任。

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

• 簽發(fā)機(jī)構(gòu)
• 有效時(shí)間
• 擴(kuò)展信息
• 域名（域名是唯一的）
• 申請(qǐng)者
• 公鑰

需要注意的是：申請(qǐng)證書的時(shí)候，需要在特定平臺(tái)生成，會(huì)同時(shí)生成?對(duì)密鑰對(duì)，即公鑰和私鑰。這對(duì)密鑰對(duì)就是用來(lái)在網(wǎng)絡(luò)通信中進(jìn)行明文加密以及數(shù)字簽名的。
其中公鑰會(huì)隨著CSR文件，?起發(fā)給CA進(jìn)行權(quán)威認(rèn)證，私鑰服務(wù)端自己保留，用來(lái)后續(xù)進(jìn)行通信（其實(shí)主要就是用來(lái)交換對(duì)稱秘鑰）

可以使用在線生成CSR和私鑰：
在線生成CSR和私鑰

形成CSR之后，后續(xù)就是向CA進(jìn)行申請(qǐng)認(rèn)證。

理解數(shù)字簽名

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

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

1. CA機(jī)構(gòu)擁有非對(duì)稱加密的私鑰A和公鑰A’

2. CA機(jī)構(gòu)對(duì)服務(wù)端申請(qǐng)的證書明文數(shù)據(jù)進(jìn)行hash，形成數(shù)據(jù)摘要

3. 然后對(duì)數(shù)據(jù)摘要用CA私鑰A’加密，得到數(shù)字簽名S
   服務(wù)端申請(qǐng)的證書明文和數(shù)字簽名S共同組成了數(shù)字證書，這樣?份數(shù)字證書就可以頒發(fā)給服務(wù)端了

方案 5 ： 對(duì)稱加密 + 非對(duì)稱加密 + 證書認(rèn)證

在客戶端和服務(wù)器建立連接的時(shí)候，服務(wù)器給客戶端返回一個(gè)證書，證書包含了服務(wù)端的公鑰，也包含了網(wǎng)站的身份信息

客戶端進(jìn)行認(rèn)證
當(dāng)客戶端獲取到這個(gè)證書之后，會(huì)對(duì)證書進(jìn)行校驗(yàn)（防止證書是偽造的）

• 判定證書的有效期是否過(guò)期
• 判斷證書的發(fā)布機(jī)構(gòu)是否受信任（操作系統(tǒng)中已內(nèi)置的受信任的證書發(fā)布機(jī)構(gòu)）
• 驗(yàn)證證書是否被篡改：從系統(tǒng)中拿到該證書發(fā)布機(jī)構(gòu)的公鑰，對(duì)簽名解密，得到一個(gè)hash值（稱為數(shù)據(jù)摘要），設(shè)為hash1 。然后計(jì)算整個(gè)證書的hash值，設(shè)為hash2 。對(duì)比hash2和hash1 是否相等，如果相等，則說(shuō)明證書是沒(méi)有被篡改過(guò)的。

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

方案5的一些問(wèn)題解答

 中間人有沒(méi)有可能篡改該證書

• 假如篡改了證書的明文

• 由于他沒(méi)有CA機(jī)構(gòu)的私鑰，所以無(wú)法hash之后用私鑰加密形成簽名，那么也就沒(méi)辦法對(duì)篡改后的證書形成匹配后的簽名。

• 如果強(qiáng)行篡改，客戶端收到該證書后會(huì)發(fā)現(xiàn)明文和簽名解密后的值不一致，則說(shuō)明證書已被篡改，證書不可信，從而終止向服務(wù)器傳輸信息，防止信息泄露給中間人

  那中間人把整個(gè)證書都掉包了呢?
  

• 因?yàn)橹虚g人沒(méi)有CA私鑰，所以無(wú)法制作假的證書。

• 所以中間人只能向CA申請(qǐng)真證書，然后用自己申請(qǐng)的證書進(jìn)行掉包

• 這個(gè)確實(shí)能做到證書的整體掉包，但是別忘記，證書明文中包含了域名等服務(wù)端認(rèn)證信息，如果整體掉包，客戶端依舊能識(shí)別出來(lái)。而出如果被識(shí)別出來(lái)了，那么就可以根據(jù)域名等認(rèn)證信息，順著找到該中間人，對(duì)于中間人來(lái)說(shuō)，這是不利的。

• 永遠(yuǎn)記?。褐虚g人沒(méi)有CA私鑰，所以對(duì)任何證書都無(wú)法進(jìn)行合法修改，包括自己的。

常見(jiàn)問(wèn)題

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

常?的摘要算法有:MD5和SHA系列
以MD5為例,我們不需要研究具體的計(jì)算簽名的過(guò)程,只需要了解MD5的特點(diǎn):

? 定?:?論多?的字符串,計(jì)算出來(lái)的MD5值都是固定?度(16字節(jié)版本或者32字節(jié)版本)

? 分散:源字符串只要改變?點(diǎn)點(diǎn),最終得到的MD5值都會(huì)差別很?.

? 不可逆:通過(guò)源字符串?成MD5很容易,但是通過(guò)MD5還原成原串理論上是不可能的.

正因?yàn)镸D5有這樣的特性,我們可以認(rèn)為如果兩個(gè)字符串的MD5值相同,則認(rèn)為這兩個(gè)字符串相同.

理解判定證書篡改的過(guò)程:(這個(gè)過(guò)程就好?判定這個(gè)?份證是不是偽造的?份證)

假設(shè)我們的證書只是?個(gè)簡(jiǎn)單的字符串hello,對(duì)這個(gè)字符串計(jì)算hash值(?如md5),結(jié)果為
BC4B2A76B9719D91
如果hello中有任意的字符被篡改了,?如變成了hella,那么計(jì)算的md5值就會(huì)變化很?.
BDBD6F9CF51F2FD8
然后我們可以把這個(gè)字符串hello和哈希值BC4B2A76B9719D91從服務(wù)器返回給客戶端,此時(shí)客戶端
如何驗(yàn)證hello是否是被篡改過(guò)?
那么就只要計(jì)算hello的哈希值,看看是不是BC4B2A76B9719D91即可.

但是還有個(gè)問(wèn)題,如果黑客把hello篡改了,同時(shí)也把哈希值重新計(jì)算下,客戶端就分辨不出來(lái)了呀.

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

所以，對(duì)證書明?(這?就是“hello”)hash形成散列摘要，然后CA使???的私鑰加密形成簽名，將hello和加密的簽名合起來(lái)形成CA證書，頒發(fā)給服務(wù)端，當(dāng)客戶端請(qǐng)求的時(shí)候，就發(fā)送給客戶端，中間?截獲了，因?yàn)闆](méi)有CA私鑰，就?法更改或者整體掉包，就能安全的證明，證書的合法性。最后，客戶端通過(guò)操作系統(tǒng)?已經(jīng)存的了的證書發(fā)布機(jī)構(gòu)的公鑰進(jìn)?解密,還原出原始的哈希值,再進(jìn)?校驗(yàn).

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

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

如何成為中間?

? ARP欺騙：在局域?中，hacker經(jīng)過(guò)收到ARP Request?播包，能夠偷聽(tīng)到其它節(jié)點(diǎn)的(IP,MAC)地址。例，?客收到兩個(gè)主機(jī)A,B的地址，告訴B(受害者)，??是A，使得B在發(fā)送給A的數(shù)據(jù)包都被?客截取

? ICMP攻擊：由于ICMP協(xié)議中有重定向的報(bào)?類型，那么我們就可以偽造?個(gè)ICMP信息然后發(fā)送給局域?中的客?端，并偽裝??是?個(gè)更好的路由通路。從?導(dǎo)致?標(biāo)所有的上?流量都會(huì)發(fā)送到我們指定的接?上，達(dá)到和ARP欺騙同樣的效果
? 假wifi&&假?站等

完整流程

左側(cè)是客戶端要做的事情，右側(cè)是服務(wù)端要做的事情

總結(jié)

HTTPS工作過(guò)程中涉及到的密鑰有三組
第?組(非對(duì)稱加密):用于校驗(yàn)證書是否被篡改.服務(wù)器持有私鑰(私鑰在形成CSR文件與申請(qǐng)證書時(shí)獲得),客戶端持有公鑰(操作系統(tǒng)包含了可信任的CA認(rèn)證機(jī)構(gòu)有哪些,同時(shí)持有對(duì)應(yīng)的公鑰).服務(wù)器在客戶端請(qǐng)求時(shí)，返回?cái)y帶簽名的證書.客戶端通過(guò)這個(gè)公鑰進(jìn)行證書驗(yàn)證,保證證書的合性，進(jìn)?步保證證書中攜帶的服務(wù)端公鑰權(quán)威性。
第?組(非對(duì)稱加密):用于協(xié)商生成對(duì)稱加密的密鑰.客戶端用收到的CA證書中的公鑰(是可被信任的)給隨機(jī)?成的對(duì)稱加密的密鑰加密,傳輸給服務(wù)器,服務(wù)器通過(guò)私鑰解密獲取到對(duì)稱加密密鑰.
第三組(對(duì)稱加密):客戶端和服務(wù)器后續(xù)傳輸?shù)臄?shù)據(jù)都通過(guò)這個(gè)對(duì)稱密鑰加密解密.

其實(shí)?切的關(guān)鍵都是圍繞這個(gè)對(duì)稱加密的密鑰.其他的機(jī)制都是輔助這個(gè)密鑰?作的.
第?組非對(duì)稱加密的密鑰是為了讓客戶端把這個(gè)對(duì)稱密鑰傳給服務(wù)器. 第?組非對(duì)稱加密的密鑰是為了讓客戶端拿到第?組非對(duì)稱加密的公鑰.文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-620478.html

到了這里，關(guān)于【Linux 網(wǎng)絡(luò)】 HTTPS協(xié)議原理 && 對(duì)稱加密 && 非對(duì)稱加密 && 數(shù)字證書的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！