歡迎來(lái)到我的頻道【點(diǎn)擊跳轉(zhuǎn)專欄】本文所有代碼已托管至碼云【點(diǎn)此轉(zhuǎn)跳】文章目錄1. HTTPS 是什么1.1 什么是加密1.2 為什么要加密1.3 常?的加密?式1.3.1 對(duì)稱加密1.3.2 ?對(duì)稱加密1.4 數(shù)據(jù)摘要 數(shù)據(jù)指紋1.5 數(shù)字指紋Hash摘要 vs 密鑰1.6 什么是數(shù)字簽名2. HTTPS 的?作過(guò)程探究2.1 只使?對(duì)稱加密行不通2.2 只使??對(duì)稱加密只保障單向相對(duì)安全2.3 雙?都使??對(duì)稱加密效率低2.4 ?對(duì)稱加密 對(duì)稱加密接近答案了但是依舊有安全問(wèn)題2.4.1 中間?攻擊針對(duì)方案2、3、42.4.2 理解數(shù)字簽名2.4.3 證書(shū)2.4.4 中間?有沒(méi)有可能篡改該證書(shū)2.4.5 那么中間?整個(gè)掉包證書(shū)2.4.6 認(rèn)識(shí)中間證書(shū) 和 根證書(shū)2.5 ?對(duì)稱加密 對(duì)稱加密 證書(shū)認(rèn)證(正確方案)2.5.2 那為什么不直接對(duì)明文進(jìn)行加密要先通過(guò)形成指紋再加密3. HTTPS完整流程圖總結(jié)1. HTTPS 是什么HTTPS 也是?個(gè)應(yīng)?層協(xié)議. 是在 HTTP 協(xié)議的基礎(chǔ)上引?了?個(gè)加密層因?yàn)镠TTP 協(xié)議內(nèi)容都是按照?本的?式明?傳輸?shù)? 這就導(dǎo)致在傳輸過(guò)程中出現(xiàn)?些被篡改的情況1.1 什么是加密加密就是把明文(要傳輸?shù)男畔?進(jìn)行一系列變換,生成密文.解密就是把密文再進(jìn)行一系列變換,還原成明文.在這個(gè)加密和解密的過(guò)程中,往往需要一個(gè)或者多個(gè)中間的數(shù)據(jù),輔助進(jìn)行這個(gè)過(guò)程,這樣的數(shù)據(jù)稱為密鑰.83版火燒圓明園,有人要謀反干掉慈禧太后.恭親王奕?給慈禧遞的折子.折子內(nèi)容只是扯一扯家常,套上一張挖了洞的紙就能看到真實(shí)要表達(dá)的意思.明文:“當(dāng)心肅順,端華,戴恒” (這幾個(gè)人都是當(dāng)時(shí)的權(quán)臣,后來(lái)被慈禧一鍋端).密文:奏折全文密鑰:挖了洞的紙.加密解密到如今已經(jīng)發(fā)展成?個(gè)獨(dú)?的學(xué)科:密碼學(xué)?密碼學(xué)的奠基?, 也正是計(jì)算機(jī)科學(xué)的祖師爺之?,艾倫·?席森·圖靈1.2 為什么要加密比如臭名昭著的 “運(yùn)營(yíng)商劫持”:下載?個(gè) 天天動(dòng)聽(tīng),未被劫持的效果, 點(diǎn)擊下載按鈕, 就會(huì)彈出天天動(dòng)聽(tīng)的下載鏈接已被劫持的效果, 點(diǎn)擊下載按鈕, 就會(huì)彈出 QQ 瀏覽器的下載鏈接:由于我們通過(guò)?絡(luò)傳輸?shù)娜魏蔚臄?shù)據(jù)包都會(huì)經(jīng)過(guò)運(yùn)營(yíng)商的?絡(luò)設(shè)備(路由器, 交換機(jī)等), 那么運(yùn)營(yí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瀏覽器” 的下載地址了.所以因?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)?加密。為啥運(yùn)營(yíng)商要進(jìn)?劫持?一個(gè)字錢不?運(yùn)營(yíng)商可以劫持, 其他的?客也可以?類似的?段進(jìn)?劫持, 來(lái)竊取??隱私信息, 或者篡改內(nèi)容在互聯(lián)?上, 明?傳輸是?較危險(xiǎn)的事情!!!HTTPS就是在HTTP的基礎(chǔ)上進(jìn)?了加密, 進(jìn)?步的來(lái)保證??的信息安全1.3 常?的加密?式1.3.1 對(duì)稱加密采用單鑰密碼系統(tǒng)的加密方法同一個(gè)密鑰可以同時(shí)用作信息的加密和解密這種加密方法稱為對(duì)稱加密也稱為單密鑰加密特征加密和解密所用的密鑰是相同的常見(jiàn)對(duì)稱加密算法(了解)DES、3DES、AES、TDEA、Blowfish、RC2等特點(diǎn)算法公開(kāi)、計(jì)算量小、加密速度快、加密效率高對(duì)稱加密其實(shí)就是通過(guò)同一個(gè) “密鑰” ,把明文加密成密文,并且也能把密文解密密成明文。一個(gè)簡(jiǎn)單的對(duì)稱加密按位異或:假設(shè) 明文a 1234密鑰key 8888則加密a ^ key得到的密文b 為 9834。然后針對(duì)密文9834再次進(jìn)行運(yùn)算b ^ key得到的就是原來(lái)的明文1234。(對(duì)于字符串的對(duì)稱加密也是同理每一個(gè)字符都可以表示成一個(gè)數(shù)字)當(dāng)然按位異或只是最簡(jiǎn)單的對(duì)稱加密. HTTPS 中并不是使用按位異或。1.3.2 ?對(duì)稱加密需要兩個(gè)密鑰來(lái)進(jìn)行加密和解密這兩個(gè)密鑰是公開(kāi)密鑰public key簡(jiǎn)稱公鑰和私有密鑰private key簡(jiǎn)稱私鑰。常見(jiàn)非對(duì)稱加密算法(了解)RSADSAECDSA特點(diǎn)算法強(qiáng)度復(fù)雜、安全性依賴于算法與密鑰但是由于其算法復(fù)雜而使得加密解密速度沒(méi)有對(duì)稱加密解密的速度快。非對(duì)稱加密要用到兩個(gè)密鑰一個(gè)叫做 “公鑰”一個(gè)叫做 “私鑰”。公鑰和私鑰是配對(duì)的。最大的缺點(diǎn)就是運(yùn)算速度非常慢比對(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)開(kāi)鎖取文件。在這個(gè)場(chǎng)景中這把鎖就相當(dāng)于公鑰鑰匙就是私鑰.公鑰給誰(shuí)都行(不怕泄露)但是私鑰只有 B 自己持有. 持有私鑰的人才能解密。1.4 數(shù)據(jù)摘要 數(shù)據(jù)指紋數(shù)字指紋(數(shù)據(jù)摘要),其基本原理是利用單向散列函數(shù)(Hash函數(shù))對(duì)信息進(jìn)行運(yùn)算,生成一串固定長(zhǎng)度的數(shù)字摘要。數(shù)字指紋并不是一種加密機(jī)制,但可以用來(lái)判斷數(shù)據(jù)有沒(méi)有被篡改。摘要常見(jiàn)算法有MD5、SHA1、SHA256、SHA512等算法把無(wú)限的映射成有限因此可能會(huì)有碰撞兩個(gè)不同的信息算出的摘要相同但是概率非常低摘要特征和加密算法的區(qū)別是摘要嚴(yán)格意義不是加密因?yàn)闆](méi)有解密只不過(guò)從摘要很難反推原信息通常用來(lái)進(jìn)行數(shù)據(jù)對(duì)比Hash 摘要數(shù)字指紋的核心特性輸入任意長(zhǎng)短的內(nèi)容都會(huì)輸出固定長(zhǎng)度的指紋無(wú)法反向解密出原文哈希我們可以通過(guò)Value映射到對(duì)應(yīng)下標(biāo)但是你向只通過(guò)Key推出Value具體是多少是做不到的只要原文改動(dòng)一點(diǎn)點(diǎn)生成的指紋就會(huì)完全變樣生活類比快遞包裹的稱重 校驗(yàn)碼假設(shè)有一份文檔內(nèi)容為我要轉(zhuǎn)賬100元給張三把這句話傳入SHA256 這類 Hash 函數(shù)就可以計(jì)算出一串指紋abc123xyz。之后我們把這份文檔連同指紋一起發(fā)送出去如果數(shù)據(jù)沒(méi)有被篡改接收方拿到文檔后自己重新計(jì)算 Hash得到的指紋依舊是abc123xyz和收到的指紋保持一致就能夠確認(rèn)文件沒(méi)有被改動(dòng)如果有中間人截獲消息把原文篡改為我要轉(zhuǎn)賬10000元給張三哪怕是一丁點(diǎn)的修改此時(shí)重新計(jì)算得到的指紋會(huì)變成qwe789rty和原來(lái)的abc123xyz完全不同接收方對(duì)比指紋不一致就可以發(fā)現(xiàn)內(nèi)容遭到了篡改。??MD5 哈希函數(shù) 已經(jīng)被人為制造碰撞即不同內(nèi)容可能出現(xiàn)相同指紋SHA256 現(xiàn)實(shí)中幾乎碰不到。1.5 數(shù)字指紋Hash摘要 vs 密鑰對(duì)比項(xiàng)密鑰對(duì)稱/非對(duì)稱加密用數(shù)字指紋(Hash摘要)作用用來(lái)加密、解密密文可以還原回明文用來(lái)校驗(yàn)防篡改只做比對(duì)不能解密還原原文輸入輸出明文密鑰 → 密文密文密鑰 → 明文任意原文 → 固定長(zhǎng)度指紋指紋不能變回原文是否可逆可逆有密鑰就能解開(kāi)單向不可逆沒(méi)有解密過(guò)程人為是否需要保管要保密對(duì)稱密鑰、私鑰必須嚴(yán)防泄露指紋可以公開(kāi)不怕別人看到改動(dòng)影響密鑰不同加密結(jié)果不同原文改密文也改原文改一點(diǎn)點(diǎn)指紋完全大變不依賴密鑰普通hash典型算法AES、RSA、DESMD5、SHA256、SHA5121.6 什么是數(shù)字簽名摘要經(jīng)過(guò)加密就得到數(shù)字簽名2. HTTPS 的?作過(guò)程探究2.1 只使?對(duì)稱加密行不通如果通信雙?都各?持有同?個(gè)密鑰X且沒(méi)有別?知道這兩?的通信安全當(dāng)然是可以被保證的除?密鑰被破解引?對(duì)稱加密之后, 即使數(shù)據(jù)被截獲, 由于?客不知道密鑰是啥, 因此就?法進(jìn)?解密, 也就不知道請(qǐng)求真實(shí)內(nèi)容是啥了但事情沒(méi)這么簡(jiǎn)單. 服務(wù)器同?時(shí)刻其實(shí)是給很多客?端提供服務(wù)的. 這么多客?端, 每個(gè)??的秘鑰都必須是不同的(如果是相同那密鑰就太容易擴(kuò)散了, ?客就也能拿到了). 因此服務(wù)器就需要維護(hù)每個(gè)客?端和每個(gè)密鑰之間的關(guān)聯(lián)關(guān)系, 這也是個(gè)很?煩的事情~?較理想的做法, 就是能在客?端和服務(wù)器建?連接的時(shí)候, 雙?協(xié)商確定這次的密鑰是啥!??但是如果直接把密鑰明?傳輸, 那么?客也就能獲得密鑰了~~ 此時(shí)后續(xù)的加密操作就形同虛設(shè)了.因此密鑰的傳輸也必須加密傳輸?shù)且雽?duì)密鑰進(jìn)?對(duì)稱加密, 就仍然需要先協(xié)商確定?個(gè) “密鑰的密鑰”. 這就成了 “先有雞還是先有蛋” 的問(wèn)題了. 此時(shí)密鑰的傳輸再?對(duì)稱加密就?不通了2.2 只使??對(duì)稱加密只保障單向相對(duì)安全鑒于?對(duì)稱加密的機(jī)制如果服務(wù)器先把公鑰以明??式傳輸給瀏覽器之后瀏覽器向服務(wù)器傳數(shù)據(jù)前都先?這個(gè)公鑰加密好再傳從客?端到服務(wù)器信道似乎是安全的(其實(shí)是有安全問(wèn)題中間人攻擊)因?yàn)橹挥蟹?wù)器有相應(yīng)的私鑰能解開(kāi)公鑰加密的數(shù)據(jù)。但是服務(wù)器到瀏覽器的這條路怎么保障安全如果服務(wù)器?它的私鑰加密數(shù)據(jù)傳給瀏覽器那么瀏覽器?公鑰可以解密它?這個(gè)公鑰是?開(kāi)始通過(guò)明?傳輸給瀏覽器的若這個(gè)公鑰被中間?劫持到了那他也能?該公鑰解密服務(wù)器傳來(lái)的信息了。2.3 雙?都使??對(duì)稱加密效率低服務(wù)端擁有公鑰S與對(duì)應(yīng)的私鑰S’客戶端擁有公鑰C與對(duì)應(yīng)的私鑰C’客戶和服務(wù)端交換公鑰客戶端給服務(wù)端發(fā)信息先用S對(duì)數(shù)據(jù)加密再發(fā)送只能由服務(wù)器解密因?yàn)橹挥蟹?wù)器有私鑰S’服務(wù)端給客戶端發(fā)信息先用C對(duì)數(shù)據(jù)加密在發(fā)送只能由客戶端解密因?yàn)橹挥锌蛻舳擞兴借€C’但是效率太低因?yàn)榉菍?duì)稱加密解密速度慢用戶體驗(yàn)差依舊有安全問(wèn)題中間人攻擊2.4 ?對(duì)稱加密 對(duì)稱加密接近答案了但是依舊有安全問(wèn)題先解決效率問(wèn)題服務(wù)端具有非對(duì)稱公鑰S和私鑰S客戶端發(fā)起https請(qǐng)求獲取服務(wù)端公鑰S公開(kāi)客戶端在本地生成對(duì)稱密鑰C通過(guò)公鑰S加密發(fā)送給服務(wù)器。由于中間的網(wǎng)絡(luò)設(shè)備沒(méi)有私鑰即使截獲了數(shù)據(jù)也無(wú)法還原出內(nèi)部的原文也就無(wú)法獲取到對(duì)稱密鑰(真的嗎)服務(wù)器通過(guò)私鑰S解密還原出客戶端發(fā)送的對(duì)稱密鑰C。并且使用這個(gè)對(duì)稱密鑰加密給客戶端返回的響應(yīng)數(shù)據(jù)。后續(xù)客戶端和服務(wù)器的通信都只用對(duì)稱加密即可.由于該密鑰只有客戶端和服務(wù)器兩個(gè)主機(jī)知道其他主機(jī)/設(shè)備不知道密鑰即使截獲數(shù)據(jù)也沒(méi)有意義。由于對(duì)稱加密的效率??對(duì)稱加密?很多, 因此只是在開(kāi)始階段協(xié)商密鑰的時(shí)候使??對(duì)稱加密, 后續(xù)的傳輸仍然使?對(duì)稱加密雖然上?已經(jīng)?較接近答案了但是依舊有安全問(wèn)題2.4.1 中間?攻擊針對(duì)方案2、3、4在?案2/3/4中客?端獲取到公鑰S之后對(duì)客?端形成的對(duì)稱秘鑰X?服務(wù)端給客?端的公鑰S進(jìn)?加密中間?即使竊取到了數(shù)據(jù)此時(shí)中間?確實(shí)?法解出客?端形成的密鑰X因?yàn)橹挥蟹?wù)器有私鑰S’但是中間?的攻擊如果在最開(kāi)始握?協(xié)商的時(shí)候就進(jìn)?了那就不?定了假設(shè)hacker已經(jīng)成功成為中間?服務(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(自己當(dāng)然不知道公鑰被更換過(guò)了)自己形成對(duì)稱秘鑰X用公鑰M加密X形成報(bào)文發(fā)送給服務(wù)器中間人劫持后直接用自己的私鑰M進(jìn)行解密得到通信秘鑰X再用曾經(jīng)保存的服務(wù)端公鑰S加密后將報(bào)文推送給服務(wù)器服務(wù)器拿到報(bào)文用自己的私鑰S解密得到通信秘鑰X雙方開(kāi)始采用X進(jìn)行對(duì)稱加密進(jìn)行通信。但是一切都在中間人的掌握中劫持?jǐn)?shù)據(jù)進(jìn)行竊聽(tīng)甚至修改都是可以的??問(wèn)題本質(zhì)出在哪?了呢客?端?法確定收到的含有公鑰的數(shù)據(jù)報(bào)?就是?標(biāo)服務(wù)器發(fā)送過(guò)來(lái)的2.4.2 理解數(shù)字簽名簽名的形成是基于?對(duì)稱加密算法的注意?前暫時(shí)和https沒(méi)有關(guān)系不要和https中的公鑰私鑰搞混了。左邊是簽名發(fā)送者先對(duì)原始數(shù)據(jù)計(jì)算散列值可以理解為數(shù)據(jù)的“指紋”再用自己的私鑰對(duì)這個(gè)散列值進(jìn)行簽名可以理解成用類似的私鑰進(jìn)行加密得到“簽名”最后把數(shù)據(jù)、簽名、SSL證書(shū) 一起發(fā)送。右邊是驗(yàn)證接收者對(duì)收到的數(shù)據(jù)也計(jì)算一次散列值同時(shí)用發(fā)送者證書(shū)中的公鑰驗(yàn)證簽名得到原來(lái)的散列值如果兩個(gè)散列值一致說(shuō)明數(shù)據(jù)傳輸途中沒(méi)有被修改并且簽名確實(shí)來(lái)自對(duì)應(yīng)私鑰的持有者。證書(shū)的作用是證明這個(gè)公鑰確實(shí)屬于發(fā)送者。??通過(guò)內(nèi)置式的強(qiáng)制使用我的公鑰A公開(kāi)的可以理解成通過(guò)域名匹配特定公鑰即 證書(shū)進(jìn)行對(duì)簽名的解密 這樣就會(huì)導(dǎo)致 中間人 篡改服務(wù)器傳給我的數(shù)據(jù)把我傳的公鑰C用于加密對(duì)稱加密密鑰的換成自己的公鑰D 拿自己的私鑰B去加密篡改后數(shù)據(jù)形成的指紋的簽名從而騙取對(duì)稱加密算法密鑰的行為是不可能成功了 因?yàn)槲覀冇脩舳耸遣徽J(rèn)可你的私鑰B加密的因?yàn)檫@個(gè)世界只有我有私鑰A意味著只有我有對(duì)數(shù)據(jù)進(jìn)行簽名的權(quán)利2.4.3 證書(shū)CA認(rèn)證服務(wù)端在使?HTTPS前需要向CA機(jī)構(gòu)申領(lǐng)?份數(shù)字證書(shū)SSL證書(shū)數(shù)字證書(shū)?含有證書(shū)申請(qǐng)者信息、公鑰信息等。CA服務(wù)器把證書(shū)傳輸給瀏覽器瀏覽器從證書(shū)?獲取公鑰就?了證書(shū)就如?份證證明服務(wù)端公鑰的權(quán)威性而所謂的證書(shū)就是明文信息證書(shū)發(fā)布機(jī)構(gòu)、證書(shū)有效期、公鑰等 簽名由CA機(jī)構(gòu)簽名因?yàn)樗借€只有CA機(jī)構(gòu)擁有所以證書(shū)的明文信息是無(wú)法被篡改的所以為了保證證書(shū)的安全客戶端還會(huì)對(duì)證書(shū)進(jìn)行驗(yàn)證驗(yàn)證成功則代表公鑰可信任那么CA公鑰保存在哪里??而CA 公鑰以根證書(shū)的形式是提前預(yù)裝在客戶端本地操作系統(tǒng)或者瀏覽器內(nèi)部不是通信時(shí)從網(wǎng)絡(luò)傳過(guò)來(lái)的中間人無(wú)法替換本地預(yù)裝的CA公鑰。PS:如果你真的NB到能入侵電腦并入侵操作系統(tǒng)修改CA公鑰那還說(shuō)啥了給你了真出現(xiàn)這種情況就已經(jīng)不單單是HTTPS安全問(wèn)題了都能獲得管理員權(quán)限修改你的系統(tǒng)了這個(gè)得請(qǐng)360老祖出山了我們可以在瀏覽器中查詢證書(shū)這些是系統(tǒng)自帶的這些則是chrome內(nèi)置的證書(shū)的申請(qǐng)申請(qǐng)證書(shū)的時(shí)候需要先在特定平臺(tái)?成推薦離線 平臺(tái)會(huì)同時(shí)?成?對(duì)?密鑰對(duì)?即公鑰和私鑰。這對(duì)密鑰對(duì)?就是?來(lái)在?絡(luò)通信中進(jìn)?明?加密以及數(shù)字簽名的。其中公鑰會(huì)隨著CSR?件?起發(fā)給CA進(jìn)?權(quán)威認(rèn)證私鑰服務(wù)端??保留?來(lái)后續(xù)進(jìn)?通信其實(shí)主要就是?來(lái)交換對(duì)稱秘鑰推薦一個(gè)網(wǎng)站可以幫你快速生成證書(shū)請(qǐng)求文件https://myssl.com/csr_create.html該網(wǎng)站可以低限制的申領(lǐng)SSL證書(shū)該平臺(tái)提供免費(fèi) SSL 證書(shū)的申請(qǐng)、管理、自動(dòng)續(xù)期服務(wù)https://console.letsssl.cn/2.4.4 中間?有沒(méi)有可能篡改該證書(shū)中間人如果篡改證書(shū)的明文由于沒(méi)有CA機(jī)構(gòu)的私鑰無(wú)法對(duì)篡改后的證書(shū)生成匹配的簽名若強(qiáng)行篡改客戶端校驗(yàn)時(shí)會(huì)發(fā)現(xiàn)證書(shū)明文與簽名解密后的值不一致判定證書(shū)不可信隨即終止通信以此防止信息泄露給中間人。2.4.5 那么中間?整個(gè)掉包證書(shū)中間人沒(méi)有CA私鑰因此無(wú)法制作假證書(shū)只能向CA申請(qǐng)真實(shí)證書(shū)來(lái)做證書(shū)整體掉包但由于證書(shū)明文中攜帶域名等服務(wù)端認(rèn)證信息比如中間人的是www.woshishabi.com客戶端依舊可以識(shí)別出這種攻擊(因?yàn)榭蛻舳嗽L問(wèn)的域名是www.woshishuaige.com)!也就是說(shuō)中間人沒(méi)有CA私鑰就無(wú)法對(duì)任何證書(shū)進(jìn)行合法修改即便是自己申請(qǐng)的證書(shū)。ps:若CA機(jī)構(gòu)被劫持私鑰泄漏難度不亞于你騎著母豬把白宮打下來(lái)那確實(shí)會(huì)出現(xiàn)信息泄漏的情況但是有這能力劫持你的本地機(jī)子不是更方便那不怕CA機(jī)構(gòu)作為中間人嘛首先你肯定相信中國(guó)中國(guó)認(rèn)證的CA機(jī)構(gòu)說(shuō)明被我們國(guó)家信賴這種情況是不可能發(fā)生的正是因?yàn)槲覀兿嘈盼覀兊膰?guó)家所以我們一定可以相信這些CA機(jī)構(gòu)2.4.6 認(rèn)識(shí)中間證書(shū) 和 根證書(shū)一般情況下CA機(jī)構(gòu)正統(tǒng)CA機(jī)構(gòu)的根證書(shū)會(huì)寫在OS里面會(huì)授權(quán)部分子機(jī)構(gòu)擁有頒發(fā)中間證書(shū)的能力即 我的信息安全由子機(jī)構(gòu)證明子機(jī)構(gòu)的信息安全由CA機(jī)構(gòu)證明那么此時(shí)Web端就會(huì)返回SSL證書(shū)、中間證書(shū)、以及內(nèi)容、簽名系統(tǒng)自帶根證書(shū)確認(rèn)中間證書(shū)的合法性中間證書(shū)確實(shí)SSL證書(shū)的合法性SSL證書(shū)解析簽名為指紋指紋確保傳輸?shù)膬?nèi)容是正確的 這也就給了我們普通人去申請(qǐng)證書(shū)的機(jī)會(huì)2.5 ?對(duì)稱加密 對(duì)稱加密 證書(shū)認(rèn)證(正確方案)在客?端和服務(wù)器剛?建?連接的時(shí)候, 服務(wù)器給客?端返回?個(gè)證書(shū)證書(shū)包含了之前服務(wù)端的公鑰, 也包含了?站的?份信息最后我梳理一遍完整的流程服務(wù)器把攜帶自身公鑰、經(jīng)CA簽名的SSL證書(shū)、發(fā)給客戶端客戶端用本地預(yù)裝的CA公鑰校驗(yàn)證書(shū)簽名與域名確認(rèn)服務(wù)器不是偽造的中間人身份校驗(yàn)通過(guò)后客戶端利用非對(duì)稱加密用服務(wù)器公鑰加密生成的隨機(jī)會(huì)話密鑰并傳給服務(wù)端只有服務(wù)器的私鑰可以解密得到該會(huì)話密后續(xù)傳輸業(yè)務(wù)數(shù)據(jù)就使用這個(gè)會(huì)話密鑰做對(duì)稱加密完成加解密對(duì)稱加密加解密速度快以此兼顧身份安全校驗(yàn)與傳輸性能。2.5.2 那為什么不直接對(duì)明文進(jìn)行加密要先通過(guò)形成指紋再加密縮?簽名密?的?度,加快數(shù)字簽名的驗(yàn)證簽名的運(yùn)算速度因?yàn)樾谐傻暮灻枪潭ǖ拈L(zhǎng)度而明文數(shù)據(jù)是長(zhǎng)短不一的3. HTTPS完整流程圖左側(cè)都是客?端做的事情, 右側(cè)都是服務(wù)器做的事情總結(jié)HTTPS 工作過(guò)程中涉及到的密鑰有三組第一組非對(duì)稱加密用于校驗(yàn)證書(shū)是否被篡改服務(wù)器持有私鑰私鑰在形成 CSR 文件與申請(qǐng)證書(shū)時(shí)獲得客戶端持有公鑰操作系統(tǒng)包含了可信任的 CA 認(rèn)證機(jī)構(gòu)有哪些同時(shí)持有對(duì)應(yīng)的公鑰服務(wù)器在客戶端請(qǐng)求時(shí)返回?cái)y帶簽名的證書(shū)客戶端通過(guò)這個(gè)公鑰進(jìn)行證書(shū)驗(yàn)證保證證書(shū)的合法性進(jìn)一步保證證書(shū)中攜帶的服務(wù)端公鑰權(quán)威性。第二組非對(duì)稱加密用于協(xié)商生成對(duì)稱加密的密鑰客戶端用收到的CA 證書(shū)中的公鑰是可被信任的給隨機(jī)生成的對(duì)稱加密的密鑰加密傳輸給服務(wù)器服務(wù)器通過(guò)私鑰解密獲取到對(duì)稱加密密鑰。第三組對(duì)稱加密用于后續(xù)業(yè)務(wù)數(shù)據(jù)的加解密客戶端和服務(wù)器后續(xù)傳輸?shù)臄?shù)據(jù)都通過(guò)這個(gè)對(duì)稱密鑰加密解密。其實(shí)一切的關(guān)鍵都是圍繞這個(gè)對(duì)稱加密的密鑰其他的機(jī)制都是輔助這個(gè)密鑰工作的第二組非對(duì)稱加密的密鑰是為了讓客戶端把這個(gè)對(duì)稱密鑰傳給服務(wù)器第一組非對(duì)稱加密的密鑰是為了讓客戶端拿到第二組非對(duì)稱加密的公鑰。