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