Linux中的HTTPS協(xié)議原理分析
不是有了HTTP了嗎？？為什么還要有HTTPS呢？？
——>HTTPS也是一個(gè)應(yīng)用層協(xié)議，是在HTTP協(xié)議的基礎(chǔ)上引入的一個(gè)加密層，他的產(chǎn)生是由于HTTP協(xié)議內(nèi)容都是按照文本的形式明文傳輸?shù)?，這就導(dǎo)致在傳輸過程中可能會(huì)出現(xiàn)被人篡改的問題！！
一、什么是加密和解密？
加密就是把 明文（要傳輸?shù)男畔ⅲ┻M(jìn)行一系列變換，生成 密文
解密就是把 密文 再進(jìn)行一系列變換，還原成 明文
而在加密和解密的過程中，往往需要一個(gè)或多個(gè)中間數(shù)據(jù)來輔助進(jìn)行這個(gè)過程，那么這樣的數(shù)據(jù)就叫做 密鑰
- 案例：83版《火燒圓明園》，有人要謀反干掉慈禧太后，恭親王奕?給慈禧遞了折子，折子內(nèi)容只是扯了扯家常，套上一張挖了洞的紙就能看到其中的關(guān)鍵字信息！
- 明文：“當(dāng)心肅順，端華，戴恒”（這幾個(gè)人都是當(dāng)時(shí)的權(quán)臣，后來被慈禧一鍋端）
- 密文：整個(gè)奏折
- 密鑰：挖了洞的紙
但是現(xiàn)如今加密和解密已經(jīng)發(fā)展成一個(gè)獨(dú)立的學(xué)科了：密碼學(xué)
而密碼學(xué)的奠基人，也正是計(jì)算機(jī)科學(xué)的祖師爺之一：艾倫·?席森·圖靈
另?位祖師爺馮諾依曼
一旦掌握了敵方密碼的解密方式！可以說是在戰(zhàn)場(chǎng)的情報(bào)獲取上占據(jù)了先機(jī)，戰(zhàn)場(chǎng)之間不僅僅是軍人的較量，背后也有情報(bào)部門針對(duì)情報(bào)做加密解密的較量！
圖靈大佬年少有為，不光奠定了計(jì)算機(jī)、人工智能、密碼學(xué)的基礎(chǔ)，并且在二戰(zhàn)中打破德軍的Enigma機(jī)，使得盟軍占盡情報(bào)優(yōu)勢(shì)，才能扭轉(zhuǎn)占據(jù)反敗為勝，但是因?yàn)橐恍┰颍允艿搅擞适业钠群Γ?1歲便英年早逝。
計(jì)算機(jī)領(lǐng)域中的最高榮譽(yù)“圖靈獎(jiǎng)”就是以他的名字命名的??！
二、為什么需要加密？
首先我們要知道，很多東西的形成并不是一開始就能考慮得很完美（http），都是在不斷實(shí)踐中暴露出來的諸多問題從而需要有新的解決方案！！
運(yùn)營商劫持事件：
下載天天動(dòng)聽，如果未被劫持，那么點(diǎn)擊下載按鈕，就會(huì)彈出天天動(dòng)聽的下載鏈接
????????????????????????????????????????????????????
而如果被劫持的話，那么點(diǎn)擊下載按鈕，就會(huì)彈出qq瀏覽器的下載鏈接！！
問題1：為什么會(huì)出現(xiàn)這種情況呢？？
——>這是因?yàn)槲覀兺ㄟ^網(wǎng)絡(luò)傳輸?shù)娜魏蔚臄?shù)據(jù)包都必然需要經(jīng)過運(yùn)營商的網(wǎng)絡(luò)設(shè)備（路由器、交換機(jī)），那么運(yùn)營商的網(wǎng)絡(luò)設(shè)備就可以解析出你傳輸?shù)臄?shù)據(jù)內(nèi)容，并進(jìn)行篡改！！
就是當(dāng)我們客戶端向服務(wù)端發(fā)送下載請(qǐng)求的時(shí)候，當(dāng)服務(wù)端將下載鏈接通過HTTP響應(yīng)發(fā)送會(huì)客戶端的時(shí)候，被運(yùn)營商給截取到了（也可以是一些不法分子），就發(fā)現(xiàn)這個(gè)請(qǐng)求是要下載天天動(dòng)聽，那么就自動(dòng)的把交給用戶的響應(yīng)篡改成了“qq瀏覽器的下載地址”
所以由于HTTP的內(nèi)容是明文傳輸?shù)?，所以明文?shù)據(jù)會(huì)經(jīng)過路由器、wifi熱點(diǎn)、通信服務(wù)運(yùn)營商、代理器等多個(gè)物理節(jié)點(diǎn)那么信息必然有可能在這個(gè)傳輸?shù)倪^程中被截獲，
一方面可以導(dǎo)致客戶端的隱私信息暴露，另一方面可以篡改響應(yīng)。同時(shí)在這個(gè)過程中劫持者還可以不被雙方察覺，這就是中間人攻擊（針對(duì)客戶端信息的監(jiān)視和攻擊）??！因此這說明HTTP必須要想辦法解決這個(gè)問題，所以就有了ssl這樣的加密解密方案??！他會(huì)在HTTP協(xié)議和傳輸層之間存在，而我們把HTTP加上ssl的加密解密方案統(tǒng)稱為HTTPS
注：大多數(shù)的截獲都是為了獲利，因此如果截獲的成本比收益大的話一般是不會(huì)有人這么做的
問題2：為什么運(yùn)營商要劫持呢？
——> 肯定是當(dāng)時(shí)有的運(yùn)營商發(fā)現(xiàn)了這個(gè)漏洞，然后試圖從中盈利，但是不僅僅是運(yùn)營商可以劫持，還有其他的一些黑客也可以使用類似的方法進(jìn)行劫持（比如最常見的就是一些釣魚wifi），試想一下你登錄支付寶時(shí)他獲取了你的支付密碼，那會(huì)是一件很可怕的事情！所以明文傳輸真的很危險(xiǎn)！
問題3：ssl絕對(duì)安全嗎？？我可不可以自己去設(shè)置一個(gè)加密協(xié)議？
——>其實(shí)ssl并不是絕對(duì)安全的！！因?yàn)槭褂肏TTPS的人太多了，樹大招風(fēng)，所以嘗試去攻破的人也很多，因此在現(xiàn)如今計(jì)算機(jī)算力不斷增強(qiáng)的情況下，是很有可能得，所以需要有很多程序員去維護(hù)，去不斷地更新。當(dāng)然我們自己寫的話可能就比較低調(diào)，可以這樣的話我們就必須自己去維護(hù)了！
三、常見的加密方式
3.1 對(duì)稱加密
采?單鑰密碼系統(tǒng)的加密?法，同?個(gè)密鑰可以同時(shí)用作信息的加密和解密，這種加密方法稱為對(duì)稱加密，也稱為單密鑰加密，
特征：加密和解密所用的密鑰是相同的，其實(shí)就是通過同?個(gè)"密鑰"，把明文加密成密文，并且也能把密文解密成明文.
常?對(duì)稱加密算法(了解)：DES、3DES、AES、TDEA、Blowfish、RC2等
特點(diǎn)：算法公開、計(jì)算量小、加密速度快、加密效率高
?個(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中并不是使?按位異或.
3.2非對(duì)稱加密
需要兩個(gè)密鑰來進(jìn)行加密和解密，這兩個(gè)密鑰是公開密鑰（public key，簡稱公鑰）和私有密鑰 （private key，簡稱私鑰）。
特點(diǎn)：算法強(qiáng)度復(fù)雜、安全性依賴于算法與密鑰但是由于其算法復(fù)雜，而使得加密解密速度沒有對(duì)稱加密解密的速度快。
常??對(duì)稱加密算法(了解)：RSA，DSA，ECDSA
公鑰和私鑰是配對(duì)的.最?的缺點(diǎn)就是運(yùn)算速度?常慢，?對(duì)稱加密要慢很多.
（1）可以通過公鑰對(duì)明?加密，變成密?——通過私鑰對(duì)密?解密，變成明?
（2）通過私鑰對(duì)明?加密，變成密?——通過公鑰對(duì)密?解密，變成明?
非對(duì)稱加密的數(shù)學(xué)原理?較復(fù)雜，涉及到?些數(shù)論相關(guān)的知識(shí).這?舉?個(gè)簡單的生活上的例?
- A要給B?些重要的?件，但是B可能不在.于是A和B提前做出約定:
- B說:我桌?上有個(gè)盒?，然后我給你?把鎖，你把?件放盒???鎖鎖上，然后我回頭拿著鑰匙來開鎖 取?件.
在這個(gè)場(chǎng)景中，這把鎖就相當(dāng)于公鑰，鑰匙就是私鑰.公鑰給誰都行(不怕泄露)，但是私鑰只有B自己持 有.持有私鑰的人才能解密.
四、加密過程中需要用到的技術(shù)
4.1 數(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ì)比
應(yīng)用場(chǎng)景1：session id——>判斷是否是合法用戶
其實(shí)我們的session id就是通過這種方式將用戶名和密碼變成一個(gè)唯一的標(biāo)識(shí)（兩個(gè)人的密碼可能一樣，但是在注冊(cè)的時(shí)候用戶名必須不一樣），然后存儲(chǔ)在服務(wù)端的數(shù)據(jù)庫中，而未來當(dāng)你去登錄這個(gè)網(wǎng)頁時(shí)，會(huì)將這個(gè)信息轉(zhuǎn)化成摘要然后由服務(wù)端在數(shù)據(jù)庫中去搜索，確認(rèn)你是一個(gè)合法用戶了，然后就會(huì)讓你登錄。
應(yīng)用場(chǎng)景2：百度網(wǎng)盤上傳資源
我們的百度網(wǎng)盤經(jīng)常會(huì)上傳各種各樣的資源，而這些資源都是應(yīng)該上傳到服務(wù)端保存起來的，但難道我客戶每上傳一個(gè)文件百度網(wǎng)盤就都要進(jìn)行下載嗎？？？
其實(shí)也不是的??！就比方說我在網(wǎng)上下載了一個(gè)《蜘蛛俠》的電影，然后我把這份資源傳給了班級(jí)里的50個(gè)人，那難道每個(gè)人保存的時(shí)候都要上傳到網(wǎng)盤么？？這文件本身就是一樣的，存儲(chǔ)多份顯然是效率低下且沒有意義的事情??！
因此我們每次上傳文件到網(wǎng)盤的時(shí)候，會(huì)先生成數(shù)據(jù)摘要，然后到網(wǎng)盤服務(wù)端的數(shù)據(jù)庫去搜索，如果發(fā)現(xiàn)了相同的摘要，那么說明這個(gè)資源在服務(wù)端已經(jīng)存在了，那么就不需要上傳了，你在客戶端那邊就可以很快看到保存成功，可如果不存在，那么服務(wù)端就需要上傳該文件并存儲(chǔ)他的摘要，此時(shí)你在客戶端那邊看到保存成功的提示可能就會(huì)稍微慢一點(diǎn)?。?/p>
4.2 數(shù)字簽名
將數(shù)字摘要進(jìn)行加密，就叫做數(shù)字簽名?。?/strong>（這是為后期的證書認(rèn)真準(zhǔn)備的，隨后會(huì)在HTTPS的方案探究中進(jìn)行說明?。?/p>
五、HTTPS方案的探究
對(duì)http進(jìn)?對(duì)稱加密，是否能解決數(shù)據(jù)通信安全的問題？問題是什么？
為何要用非對(duì)稱加密？為何不全用非對(duì)稱加密？
接下來會(huì)逐步解決這兩個(gè)問題??！
5.1 方案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ù)端想要修改秘鑰的話，那么就必須強(qiáng)迫客戶端也去修改秘鑰，顯然是難以做到的
?較理想的做法，就是能在客戶端和服務(wù)器建立連接的時(shí)候，雙方協(xié)商確定這次的密鑰是啥~
但是如果直接把密鑰明?傳輸，那么?客也就能獲得密鑰了~~此時(shí)后續(xù)的加密操作就形同虛設(shè)了
因此密鑰的傳輸也必須加密傳輸!
但是要想對(duì)密鑰進(jìn)?對(duì)稱加密，就仍然需要先協(xié)商確定?個(gè)"密鑰的密鑰".這就成了"先有雞還是先有蛋"的問題了.顯然無論是哪一方去生成這個(gè)秘鑰，都需要通過網(wǎng)絡(luò)傳輸給另一方，那么這個(gè)過程就有可能產(chǎn)生數(shù)據(jù)泄漏??！
5.2 方案2：只使用非對(duì)稱加密
鑒于非對(duì)稱加密的機(jī)制，如果服務(wù)器先把公鑰以明文方式傳輸給瀏覽器，之后瀏覽器向服務(wù)器傳數(shù)據(jù)前都先用這個(gè)公鑰加密好再傳，從客戶端到服務(wù)器信道似乎是安全的(有安全問題)，因?yàn)橹挥蟹?wù)器有相應(yīng)的私鑰能解開公鑰加密的數(shù)據(jù)。
但是服務(wù)器到瀏覽器的這條路怎么保障安全？
如果服務(wù)器?它的私鑰加密數(shù)據(jù)傳給瀏覽器，那么瀏覽器?公鑰可以解密它，?這個(gè)公鑰是?開始通過明?傳輸給瀏覽器的，若這個(gè)公鑰被中間?劫持到了，那他也能?該公鑰解密服務(wù)器傳來的信息了。因此還是不安全?。?/p>
5.3方案3：雙方都使用非對(duì)稱加密
1. 服務(wù)端擁有公鑰S與對(duì)應(yīng)的私鑰S'，客?端擁有公鑰C與對(duì)應(yīng)的私鑰C'
2. 客?和服務(wù)端交換公鑰
3. 客?端給服務(wù)端發(fā)信息：先?S對(duì)數(shù)據(jù)加密，再發(fā)送，只能由服務(wù)器解密，因?yàn)橹挥蟹?wù)器有私鑰 S'
4. 服務(wù)端給客?端發(fā)信息：先?C對(duì)數(shù)據(jù)加密，在發(fā)送，只能由客?端解密，因?yàn)橹挥锌?端有私鑰 C'
這樣好像可以誒！我們保留自己的私鑰，交換雙方的公鑰，所以只有我們雙方可以解析對(duì)方的信息，中間人看到了公鑰也沒有絲毫作用??！ 可是這樣效率太低了！！
5.4 方案4：非對(duì)稱加密+對(duì)稱加密
解決效率問題！
1、服務(wù)端具有非對(duì)稱公鑰S和私鑰S‘
2、客?端發(fā)起https請(qǐng)求，獲取服務(wù)端公鑰S
3、客?端在本地?成對(duì)稱密鑰C，通過公鑰S加密，發(fā)送給服務(wù)器.
- 由于中間的?絡(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ì)稱加密.
這個(gè)方案看似已經(jīng)完美了，但還是有問題??！
5.5 中間人攻擊
?案2，?案3，?案4都存在?個(gè)問題，如果最開始，中間?就已經(jīng)開始攻擊了呢？
Man-in-the-MiddleAttack，簡稱“MITM攻擊”
確實(shí)，在?案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)成功成為中間?
- 1. 服務(wù)器具有非對(duì)稱加密算法的公鑰S，私鑰S'
- 2. 中間?具有非對(duì)稱加密算法的公鑰M，私鑰M'
- 3. 客?端向服務(wù)器發(fā)起請(qǐng)求，服務(wù)器明?傳送公鑰S給客?端
- 4. 中間?劫持?jǐn)?shù)據(jù)報(bào)?，提取公鑰S并保存好，然后將被劫持報(bào)?中的公鑰S替換成為??的公鑰M， 并將偽造報(bào)?發(fā)給客?端
- 5. 客?端收到報(bào)?，提取公鑰M(??當(dāng)然不知道公鑰被更換過了)，??形成對(duì)稱秘鑰X，?公鑰M加密X，形成報(bào)?發(fā)送給服務(wù)器
- 6. 中間?劫持后，直接???的私鑰M'進(jìn)?解密，得到通信秘鑰X，再?曾經(jīng)保存的服務(wù)端公鑰S加 密后，將報(bào)?推送給服務(wù)器
- 7. 服務(wù)器拿到報(bào)?，用自己的私鑰S'解密，得到通信秘鑰X
- 8. 雙?開始采?X進(jìn)?對(duì)稱加密，進(jìn)?通信。但是?切都在中間?的掌握中，劫持?jǐn)?shù)據(jù)，進(jìn)行竊 聽甚至修改，都是可以的
問題本質(zhì)出在哪里了呢？客戶端無法確定收到的含有公鑰的數(shù)據(jù)報(bào)文，就是目標(biāo)服務(wù)器發(fā)送過來的！-->所以問題變成了我們?nèi)绾伪ＷC公鑰的合法性？？
5.6 引入CA證書
關(guān)于CA的生態(tài)推薦可以去了解一些人物和故事??！
首先我們要知道，任何技術(shù)的產(chǎn)生都離不開實(shí)際場(chǎng)景的應(yīng)用，比如學(xué)碩（學(xué)習(xí)科學(xué)前沿技術(shù)，研究更多深入的論文），專碩（如何將目前已有的前沿技術(shù)轉(zhuǎn)化為生產(chǎn)力），所以HTTPS也是一項(xiàng)技術(shù)，那么他也必須結(jié)合自己的實(shí)際應(yīng)用場(chǎng)景去研究（（萬維網(wǎng)綁定的一種網(wǎng)絡(luò)通信協(xié)議，確保雙方進(jìn)行資源獲取或數(shù)據(jù)提交時(shí)的安全問題））。而針對(duì)“中間人攻擊”的漏洞，他也必須在發(fā)展過程中探索出自己強(qiáng)有力的解決方案?。∷砸肓薈A這個(gè)第三方機(jī)構(gòu)來解決這個(gè)問題。未來你想入網(wǎng)，你就必須申請(qǐng)CA證書。
CA認(rèn)證：服務(wù)端在使用HTTPS前，需要向CA機(jī)構(gòu)申領(lǐng)?份數(shù)字證書，數(shù)字證書里含有證書申請(qǐng)者信息、公鑰信息等。服務(wù)器把證書傳輸給瀏覽器，瀏覽器從證書里獲取公鑰就行了，證書就如身份證，證明服務(wù)端公鑰的權(quán)威性（當(dāng)然CA證書不是掛在墻上的，而是被安裝在服務(wù)器上的）
---->所以研究保證公鑰的合法性 轉(zhuǎn)化為了研究保證證書的合法性！因?yàn)橄嘈抛C書就是相信公鑰！
問題1：如何申請(qǐng)認(rèn)證呢？？
-——>需要確認(rèn)自己的域名（唯一）、公司主體、法人之類的申請(qǐng)信息，然后還需要有一對(duì)公私鑰匙，通過這些生成一個(gè)CSR的請(qǐng)求文件，然后向CA機(jī)構(gòu)申請(qǐng)證書，由他審核，通過后給你頒發(fā)證書，需要注意的是：申請(qǐng)證書的時(shí)候，需要在特定平臺(tái)查，會(huì)同時(shí)生成?對(duì)密鑰對(duì)，即公鑰和私 鑰。這對(duì)密鑰對(duì)就是用來在網(wǎng)絡(luò)通信中進(jìn)行明文加密以及數(shù)字簽名的。
CSR在線生成
可以使?在線?成CSR和私鑰：CSR在線生成工具
形成CSR之后，后續(xù)就是向CA進(jìn)行申請(qǐng)認(rèn)證，不過?般認(rèn)證過程很繁瑣，?絡(luò)各種提供證書申請(qǐng)的服務(wù)商，?般真的需要，直接找平臺(tái)解決就行
其中公鑰會(huì)隨著CSR?件，?起發(fā)給CA進(jìn)行權(quán)威認(rèn)證，私鑰服務(wù)端自己保留，用來后續(xù)進(jìn)行通信（其 實(shí)主要就是?來交換對(duì)稱秘鑰）
問題2：審核通過后，CA證書又是怎么形成的？？
-——>CA證書是由認(rèn)證信息和數(shù)字簽名（簽名的形成是基于非對(duì)稱加密算法的
這里的簽名者，其實(shí)就是指的就是CA機(jī)構(gòu)，而CA機(jī)構(gòu)是有自己的公鑰和私鑰的，這和我們所講的服務(wù)端和客戶端毫無任何關(guān)系?。《菍儆诘谌剑。?/strong>
當(dāng)服務(wù)端申請(qǐng)CA證書的時(shí)候，CA機(jī)構(gòu)會(huì)對(duì)該服務(wù)端進(jìn)?審核，并專?為該?站形成數(shù)字簽名，過程如下：
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ù)端了
他會(huì)將你的認(rèn)證信息先轉(zhuǎn)化成數(shù)據(jù)摘要，然后用CA的私鑰進(jìn)行加密，我們把他叫做數(shù)字簽名，然后公開的認(rèn)證信息和這個(gè)數(shù)字簽名共同形成了證書！！
問題3：形成證書之后又是如何審核的呢？？
——>這樣形成證書的目的，其實(shí)也是為了后來的審核??！所謂審核，其實(shí)就是研究該證書是否合法，因?yàn)橐坏┧戏四敲淳涂梢韵嘈抛C書里面的秘鑰了??！ 所以我們的審核需要面臨兩個(gè)問題（1）機(jī)構(gòu)是否權(quán)威 （2）是否被篡改過
驗(yàn)證時(shí)他會(huì)將你帶有數(shù)字簽名的證書給拆成簽名和認(rèn)證信息，形成認(rèn)證信息的散列值和簽名進(jìn)行對(duì)比，如果是相等的說明該證書沒有被篡改過，如果不相等那么說明被篡改過了，則說明證書已被篡改， 證書不可信，從?終?向服務(wù)器傳輸信息，防?信息泄露給中間?
問題4：為什么客戶端可以解開用CA私鑰加密過的簽名呢？？
——>因?yàn)榭蛻舳藭?huì)內(nèi)置很多CA機(jī)構(gòu)的公鑰，也就是說client只信任CA的公鑰?。?/strong>這同時(shí)也可以認(rèn)為只有CA能夠進(jìn)行證書的簽發(fā)?。∫?yàn)橹挥蠧A自己有私鑰??！中間人沒有資格進(jìn)行證書的全新形成
問題5：驗(yàn)證是否真的可以防住中間人
——>
情況1：篡改明文信息
那么在驗(yàn)證的時(shí)候只要明文信息和簽名的序列不匹配，客戶端就會(huì)發(fā)現(xiàn)問題。
情況2：篡改明文信息+篡改簽名
就是篡改明文信息后，然后將新的明文信息形成新的簽名替換過去，可是由于中間人沒有CA的私鑰！！所以他根本形成不了有效的簽名，因?yàn)閏lient只認(rèn)CA的公鑰??！
情況3：篡改簽名
這其實(shí)就沒有啥意義了，不改明文的話好像也沒啥好處可圖，無非就是讓別人發(fā)現(xiàn)被篡改了。
問題6：如果中間人申請(qǐng)了自己的證書然后把你的證書給掉包了呢？？
——>因?yàn)橹虚g?沒有CA私鑰，所以?法制作假的證書???????，但是一般來說黑客是不太敢提交真信息給CA弄真證書，如果被發(fā)現(xiàn)了容易被溯源找到，而且前提是得合法機(jī)構(gòu)才能申請(qǐng)到，就算真的申請(qǐng)到了，一般由于域名具有唯一性，也是很容易被用戶發(fā)現(xiàn)的，除非得偽裝成一個(gè)假網(wǎng)站。如果真的是這樣的話就防不了了，因?yàn)檫@個(gè)屬于客戶端的問題。但是一旦被發(fā)現(xiàn)，很容易被公安部門查處！！
問題7：為什么摘要內(nèi)容在網(wǎng)絡(luò)傳輸?shù)臅r(shí)候一定要加密形成簽名？？
——>常?的摘要算法有:MD5和SHA系列以MD5為例，我們不需要研究具體的計(jì)算簽名的過程，只需要了解MD5的特點(diǎn):
(1)定?:?論多?的字符串，計(jì)算出來的MD5值都是固定?度(16字節(jié)版本或者32字節(jié)版本)
(2)分散:源字符串只要改變?點(diǎn)點(diǎn)，最終得到的MD5值都會(huì)差別很大
(3)不可逆:通過源字符串?成MD5很容易，但是通過MD5還原成原串理論上是不可能的.
正因?yàn)镸D5有這樣的特性，我們可以認(rèn)為如果兩個(gè)字符串的MD5值相同，則認(rèn)為這兩個(gè)字符串相同.
但是還有個(gè)問題，如果?客把hello篡改了，同時(shí)也把哈希值重新計(jì)算下，客?端就分辨不出來了呀.
所以被傳輸?shù)墓Ｖ挡荒軅鬏斆?，需要傳輸密?
所以，對(duì)證書明?(這?就是“hello”)hash形成散列摘要，然后CA使用自己的私鑰加密形成簽名，將 hello和加密的簽名合起來形成CA證書，頒發(fā)給服務(wù)端，當(dāng)客戶端請(qǐng)求的時(shí)候，就發(fā)送給客戶端，中間?截獲了，因?yàn)闆]有CA私鑰，就?法更改或者整體掉包，就能安全的證明，證書的合法性。最后，客戶端通過操作系統(tǒng)?已經(jīng)存的了的證書發(fā)布機(jī)構(gòu)的公鑰進(jìn)?解密，還原出原始的哈希值，再進(jìn)行校驗(yàn).
問題8：為什么簽名不直接加密，而是要先hash形成數(shù)字摘要？？
-——>當(dāng)然更主要的是為了方便傳輸（固定大?。┖捅葘?duì)（只要比較哈希值）！縮小簽名密文的?度，加快數(shù)字簽名的驗(yàn)證簽名的運(yùn)算速度
5.7最終方案：非對(duì)稱加密+對(duì)稱加密+證書認(rèn)證
客?端進(jìn)?認(rèn)證
當(dāng)客?端獲取到這個(gè)證書之后，會(huì)對(duì)證書進(jìn)?校驗(yàn)(防?證書是偽造的).
1、判定證書的有效期是否過期
2、判定證書的發(fā)布機(jī)構(gòu)是否受信任(操作系統(tǒng)中已內(nèi)置的受信任的證書發(fā)布機(jī)構(gòu)).
3、驗(yàn)證證書是否被篡改:從系統(tǒng)中拿到該證書發(fā)布機(jī)構(gòu)的公鑰，對(duì)簽名解密，得到?個(gè)hash值(稱為數(shù) 據(jù)摘要)，設(shè)為hash1.然后計(jì)算整個(gè)證書的hash值，設(shè)為hash2.對(duì)?hash1和hash2是否相等.如果相等，則說明證書是沒有被篡改過的
查看瀏覽器的受信任證書發(fā)布機(jī)構(gòu)：Chrome瀏覽器，點(diǎn)擊右上?的
選擇"設(shè)置"，搜索"證書管理"，即可看到以下界?.(如果沒有，在隱私設(shè)置和安全性->安全??找找)
5.8基于HTTPS的一些思考
問題1：如何成為中間人？？(了解)
——>
（1）ARP欺騙：在局域網(wǎng)中，hacker經(jīng)過收到ARPRequest?播包，能夠偷聽到其它節(jié)點(diǎn)的(IP，MAC)地址。例如黑客收到兩個(gè)主機(jī)A，B的地址，告訴B(受害者)，??是A，使得B在發(fā)送給A的數(shù)據(jù)包都被黑客截取
（2）ICMP攻擊：由于ICMP協(xié)議中有重定向的報(bào)?類型，那么我們就可以偽造?個(gè)ICMP信息然后發(fā)送給 局域?中的客?端，并偽裝??是?個(gè)更好的路由通路。從?導(dǎo)致?標(biāo)所有的上?流量都會(huì)發(fā)送到 我們指定的接?上，達(dá)到和ARP欺騙同樣的效果
（3）假wifi&&假網(wǎng)站等
問題2：完整流程
——>左側(cè)都是客?端做的事情，右側(cè)都是服務(wù)器做的事情
問題3：秘鑰的總結(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ì)稱加密):客戶端和服務(wù)器后續(xù)傳輸?shù)臄?shù)據(jù)都通過這個(gè)對(duì)稱密鑰加密解密.
- 其實(shí)?切的關(guān)鍵都圍繞這個(gè)對(duì)稱加密的密鑰.其他的機(jī)制都是輔助這個(gè)密鑰?作的.
- 第?組非對(duì)稱加密的密鑰是為了讓客戶端把這個(gè)對(duì)稱密鑰傳給服務(wù)器.
- 第?組非對(duì)稱加密的密鑰是為了讓客戶端拿到第?組非對(duì)稱加密的公鑰.
問題4：HTTPS就一定安全嗎？？？
——>HTTPS并不一定真正安全，因?yàn)樗行У胤乐沽酥虚g人的攻擊，而中間人的出現(xiàn)一般是為了竊取客戶端信息的，但是不排除在有些情況下黑客會(huì)以客戶端的身份來分析你服務(wù)端的數(shù)據(jù)（因?yàn)閷?duì)稱密鑰的形成是在客戶端形成的，所以服務(wù)端拿到后會(huì)和你通信進(jìn)行交互，然后他就可以對(duì)服務(wù)端發(fā)來的信息做分析）然后對(duì)服務(wù)端做一些更深入的攻擊，因此在大多數(shù)情況下我們的服務(wù)端還需要基于https來做一些二次加密，防止黑客對(duì)服務(wù)端的攻擊。
問題5：為什么HTTP必須放在應(yīng)用層去實(shí)現(xiàn)？？
------->應(yīng)用層涉及到的知識(shí)點(diǎn)非常多（序列化反序列化、報(bào)文的正確讀取和正確寫入、協(xié)議、加密……）而應(yīng)用層必須放在用戶層實(shí)現(xiàn)，是因?yàn)椴煌娜藢?duì)協(xié)議有不同的定制需求，有不同的定制需求，有不同的序列化反序列化的方案，有不同的加密解密方案（不同的安全級(jí)別），所以上述所有的東西都不可能在內(nèi)核里實(shí)現(xiàn)統(tǒng)一，否則一旦其中一個(gè)出現(xiàn)了問題，那么整個(gè)內(nèi)核都得被改變。
總結(jié)
以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。
相關(guān)文章
如何搭建并配置HTTPD文件服務(wù)及訪問權(quán)限控制
這篇文章主要介紹了如何搭建并配置HTTPD文件服務(wù)及訪問權(quán)限控制的問題,具有很好的參考價(jià)值,希望對(duì)大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2025-06-06
Linux中出現(xiàn)“No space left on device”錯(cuò)誤的排查與解決方法
這篇文章主要給大家介紹了關(guān)于在Linux中出現(xiàn)"No space left on device"錯(cuò)誤的排查與解決方法，文中通過示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面來一起看看吧。2017-09-09
Ubuntu 14.04下Django和MySQL環(huán)境部署全過程
這篇文章主要介紹了Ubuntu 14.04下Django和MySQL環(huán)境部署全過程，文中通過一步步的安裝步驟介紹的很詳細(xì)，相信對(duì)大家具有一定的參考借鑒價(jià)值，有需要的朋友們下面來一起來看看吧。2017-02-02
Linux find命令如何根據(jù)時(shí)間篩選出文件進(jìn)行刪除
這篇文章主要介紹了Linux find命令如何根據(jù)時(shí)間篩選出文件進(jìn)行刪除的實(shí)現(xiàn)方式,具有很好的參考價(jià)值,希望對(duì)大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2025-07-07
在Linux中設(shè)置別名永久生效的步驟包括：在/root/.bashrc文件中配置別名,保存并退出,然后使用source命令（或點(diǎn)命令）使配置立即生效,這樣,別名設(shè)置就不會(huì)在通過SSH重新登錄時(shí)丟失2025-01-01
這篇文章主要介紹了Linux 掛載分區(qū)的方法，小編覺得挺不錯(cuò)的，現(xiàn)在分享給大家，也給大家做個(gè)參考。一起跟隨小編過來看看吧2018-08-08
這篇文章主要介紹了如何在Apache中設(shè)置目錄禁止訪問，非常的簡單實(shí)用，有需要的朋友可以參考下2014-11-11
centos中NAT模式下靜態(tài)IP連接外網(wǎng)
這篇文章主要介紹了centos中NAT模式下靜態(tài)IP連接外網(wǎng)，具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下2017-06-06
Linux printf如何將十進(jìn)制轉(zhuǎn)換為十六進(jìn)制
文章總結(jié)：介紹了十進(jìn)制、十六進(jìn)制和八進(jìn)制之間的轉(zhuǎn)換方法,包括使用\b命令和bc工具進(jìn)行轉(zhuǎn)換的技巧2024-12-12
本文為大家介紹了ssh連接超時(shí)的解決方法, 另外提供一種不修改配置文件就可以解決連接超時(shí)的方法，大家參考使用吧2014-01-01