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