柚子快報激活碼778899分享：網絡協(xié)議 HTTPS

http://yzkb.51969.com/

目錄

HTTPS協(xié)議原理

什么是加密

為什么要加密

常見的加密方式

1.對稱加密：

2.非對稱加密：

3.數據摘要&&數據指紋

數字簽名

HTTPS的工作過程探究

方案1：只使用對稱加密

方案2：只使用非對稱加密

方案3：雙方都使用非對稱加密

方案4：非對稱加密 + 對稱加密

中間人攻擊 - 針對上面的場景

引入證書

CA認證

自己使用Linux生成一對密鑰和CSR文件：

生成CSR文件

進行CA認證

理解數據簽名(數字簽名)

方案5：非對稱加密 + 對稱加密 + 證書認證

中間人有沒有可能篡改該證書？

中間人整個掉包證書？

為什么數據摘要內容在網絡傳輸的時候一定要加密形成簽名?

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

如何成為中間人 - 了解

完整流程

HTTPS協(xié)議原理

HTTPS是什么，HTTPS也是?個應?層協(xié)議，是在HTTP協(xié)議的基礎上引?了?個加密層。 HTTP協(xié)議內容都是按照?本的?式明?傳輸的，這就導致在傳輸過程中出現?些被篡改(被抓包修改)的情況。

HTTPS（Hypertext Transfer Protocol Secure）是一種用于安全傳輸數據的通信協(xié)議。它是在HTTP協(xié)議的基礎上引入了加密層，通過使用SSL（Secure Socket Layer）或其繼任者TLS（Transport Layer Security）協(xié)議來保護數據傳輸的安全性和完整性。HTTPS主要解決了HTTP在傳輸過程中可能遇到的被篡改、竊聽等安全問題。

下面是HTTPS的一些主要原理和特點：

加密通信： HTTPS使用SSL/TLS協(xié)議對傳輸的數據進行加密，這樣即使被第三方截獲了通信內容，也無法解讀其具體內容。這為用戶和網站提供了更高的安全性。身份驗證： HTTPS通過證書機制對通信的雙方進行身份驗證。網站必須使用由可信證書頒發(fā)機構（CA）簽發(fā)的數字證書，這樣客戶端才能驗證網站的真實性。這防止了中間人攻擊，確保用戶連接的是合法的服務器。數據完整性： 除了加密通信外，HTTPS還通過哈希函數等機制保證數據的完整性。這確保在傳輸過程中數據沒有被篡改。HTTPS握手過程： 當客戶端和服務器建立HTTPS連接時，它們會執(zhí)行一種稱為“握手”的過程。在握手過程中，雙方協(xié)商密鑰、驗證證書、選擇加密算法等，確保建立一個安全的通信通道。使用443端口： 默認情況下，HTTPS使用TCP的443端口進行通信，與HTTP的80端口相對應。這樣使得HTTP和HTTPS可以共存于同一服務器，通過端口的不同來區(qū)分。

總的來說，HTTPS通過加密、身份驗證和數據完整性保護了用戶和網站之間的通信，提高了網絡傳輸的安全性。在現代互聯網中，許多網站都采用了HTTPS以確保用戶的隱私和安全。

什么是加密

加密是一種將明文（原始數據或信息）經過一系列變換生成密文的過程，而解密則是將密文再經過相應的變換還原成明文的過程。在這個過程中，通常需要使用一個或多個中間的數據，這些數據稱為密鑰。

加密過程：

明文輸入： 原始的、未經加密的數據稱為明文。加密算法： 使用特定的加密算法對明文進行變換，產生密文。密鑰： 加密算法通常需要一個密鑰，這個密鑰是用來影響加密算法行為的參數。

解密過程：

密文輸入： 經過加密得到的數據稱為密文。解密算法： 使用相應的解密算法對密文進行變換，還原成明文。密鑰： 解密算法通常也需要使用與加密時相同的密鑰。

密鑰在加密和解密的過程中起到關鍵的作用，它是影響加密算法行為的參數，同時也是確保只有合法用戶能夠正確解密數據的重要因素。密鑰可以分為對稱密鑰和非對稱密鑰兩種類型：

對稱密鑰（Symmetric Key）： 加密和解密使用相同的密鑰。這意味著發(fā)送方和接收方在通信中都需要共享同一個密鑰。對稱加密算法效率高，但密鑰管理相對復雜。非對稱密鑰（Asymmetric Key）： 加密和解密使用不同的密鑰，一把用于加密，另一把用于解密。這種方法解決了對稱密鑰的密鑰分發(fā)問題，但相對來說計算成本較高。

加密技術在信息安全領域中扮演著重要的角色，用于保護數據的機密性、完整性和可用性。常見的加密算法包括DES、AES、RSA等。

為什么要加密

臭名昭著的"運營商劫持"，比如下載?個天天動聽

未被劫持的效果，點擊下載按鈕，就會彈出天天動聽的下載鏈接：

已被劫持的效果，點擊下載按鈕，就會彈出QQ瀏覽器的下載鏈接：

由于我們通過?絡傳輸的任何的數據包都會經過運營商的?絡設備(路由器。交換機等)，那么運營商的?絡設備就可以解析出你傳輸的數據內容，并進?篡改。點擊"下載按鈕"，其實就是在給服務器發(fā)送了?個HTTP請求，獲取到的HTTP響應其實就包含了該APP的下載鏈接，運營商劫持之后，就發(fā)現這個請求是要下載天天動聽，那么就?動的把交給??的響應給篡改成"QQ瀏覽器"的下載地址了。

所以：因為http的內容是明文傳輸的，明文數據會經過路由器、wifi熱點、通信服務運營商、代理服務器等多個物理節(jié)點，如果信息在傳輸過程中被劫持，傳輸的內容就完全暴露了。劫持者還可以篡改傳輸的信息且不被雙方察覺，這就是|中間人攻擊，所以我們才需要對信息進行加密。

思考下，為啥運營商要進行劫持?

廣告注入： 運營商可能通過劫持HTTP流量來注入廣告，以獲取額外的廣告收入。這種行為可能對用戶體驗產生負面影響，因為用戶在訪問網站時會看到未經請求的廣告。流量監(jiān)控和分析： 運營商可能對用戶的網絡活動進行監(jiān)控和分析，以了解用戶的興趣、行為模式和使用習慣。這樣的信息可以用于制定精準的廣告投放策略，但也引發(fā)了隱私問題。提供增值服務： 運營商可能通過劫持流量來提供一些增值服務，例如壓縮圖像以節(jié)省用戶的帶寬費用。然而，這樣的操作可能違反用戶的隱私權和網絡中立性原則。內容過濾和審查： 在某些國家，運營商可能被要求履行政府的審查義務，對特定的網站或內容進行過濾和審查。劫持流量是一種實施這種審查的方式。提高服務質量： 有時，運營商可能劫持流量以優(yōu)化網絡性能，例如通過壓縮圖片或視頻來提高加載速度。然而，這也可能導致對原始內容的質量損失。

不止運營商可以劫持，其他的黑客也可以用類似的手段進行劫持，來竊取用戶隱私信息，或者篡改內容。試想一下,如果黑客在用戶登陸支付寶的時候獲取到用戶賬戶余額,甚至獲取到用戶的支付密碼....在互聯網上,明文傳輸是比較危險的事情!

HTTPS就是在HTTP的基礎上進行了加密,進一步的來保證用戶的信息安全

常見的加密方式

常見的加密方式可以分為對稱加密和非對稱加密兩大類，以及哈希函數。以下是一些常見的加密方式：

1.對稱加密：

對稱加密是一種加密方法，它采用單一密鑰進行加密和解密。這意味著相同的密鑰用于對信息進行加密和解密操作，因此也被稱為單密鑰加密。以下是對稱加密的一些關鍵特征和常見算法的簡要說明：

特征：

同一密鑰用于加密和解密： 對稱加密使用相同的密鑰來執(zhí)行加密和解密操作，這是其主要特征。算法公開： 加密和解密所使用的算法是公開的，只有密鑰是保密的。計算量?。?對稱加密通常具有較小的計算量，這使得它們在資源受限的環(huán)境中表現優(yōu)越。加密速度快： 由于只涉及單一密鑰，對稱加密通常能夠提供快速的加密速度。

常見對稱加密算法：

DES（Data Encryption Standard）： 使用56位密鑰，但由于密鑰長度短，安全性受到質疑，已經不再推薦使用。3DES（Triple DES）： 是對DES的改進，對數據執(zhí)行三次DES操作，提高了安全性。AES（Advanced Encryption Standard）： 目前廣泛使用的對稱加密算法，支持不同的密鑰長度，包括128位、192位和256位。TDEA（Triple Data Encryption Algorithm）： 也稱為Triple DES，是3DES的縮寫，是對DES的三次迭代。Blowfish： 一種對稱加密算法，以其簡單、高效、可靠而聞名。RC2（Rivest Cipher 2）： 由Ron Rivest設計，是對稱加密算法之一。

對稱加密其實就是通過同一個"密鑰"，把明文加密成密文，并且也能把密文解密成明文。

一個簡單的對稱加密，按位異或：

假設明文a=1234,密鑰key = 8888則加密 a^ key得到的密文b為9834。

然后針對密文9834再次進行運算b ^ key,得到的就是原來的明文1234。(對于字符串的對稱加密也是同理,每一個字符都可以表示成一個數字)當然,按位異或只是最簡單的對稱加密.HTTPS中并不是使用按位異或。

2.非對稱加密：

非對稱加密使用一對密鑰，分別是公開秘鑰(全網公開，簡稱公鑰，翻譯為 public key)和私有秘鑰(只能自己擁有，簡稱私鑰，翻譯為 private key)。公鑰用于加密，私鑰用于解密，或者，私鑰用于加密，公鑰用于解密。信息被使用接收者的公鑰加密后變成密文，只能使用相應的私鑰進行解密變成明文。非對稱加密提供了更高的安全性，尤其是在密鑰傳遞的過程中，因為公鑰可以被分享而私鑰必須保持私密。常見的非對稱加密算法包括RSA、DSA和ECDSA等。

公鑰和私鑰配對： 非對稱加密使用一對密鑰，分別是公鑰和私鑰。這兩個密鑰是數學上相關聯的，任何用公鑰加密的信息只能用相應的私鑰解密，反之亦然。常見算法： 你提到的RSA、DSA和ECDSA是常見的非對稱加密算法。它們在實現上有一些不同，但都符合非對稱加密的基本原理。復雜的算法強度： 非對稱加密算法通常較為復雜，其安全性取決于算法的復雜性和密鑰的長度。較長的密鑰通常提供更高的安全性，但也會增加加密和解密的計算成本。運算速度慢： 非對稱加密的主要缺點之一是運算速度相對較慢，尤其是與對稱加密相比。因此，在實際應用中，通常會使用對稱加密算法來加密長文本，而對稱加密算法的密鑰則使用非對稱加密算法進行安全地傳輸。

RSA（Rivest–Shamir–Adleman）： 一種常見的非對稱加密算法，用于加密和數字簽名。基于公鑰和私鑰的概念。ECC（Elliptic Curve Cryptography）： 使用橢圓曲線的非對稱加密算法，相較于RSA，在相同的安全級別下，使用更短的密鑰長度。

非對稱加密的數學原理比較復雜,涉及到一些數論相關的知識，這里舉一個簡單的生活上的例子，A要給B一些重要的文件，但是B可能不在，于是A和B提前做出約定：

B說：我桌子上有個盒子,然后我給你一把鎖，你把文件放盒子里用鎖鎖上，然后我回頭拿著鑰匙來開鎖取文件。在這個場景中，這把鎖就相當于公鑰，鑰匙就是私鑰，公鑰給誰都行(不怕泄露)，但是私鑰只有B自己持有，持有私鑰的人才能解密。

3.數據摘要&&數據指紋

數字指紋(數據摘要)，其基本原理是利用單向散列函數(Hash函數)對信息進行運算,生成一串固定長度的數字摘要。數字指紋并不是一種加密機制,但可以用來判斷數據有沒有被竄改。

基本原理：

Hash函數： 數字指紋的生成依賴于單向散列函數，也稱為Hash函數。這類函數具有一個關鍵特征，即對于輸入數據的微小改變，輸出的摘要應該發(fā)生巨大變化。這使得通過比較摘要可以檢測數據是否被篡改。不可逆性： Hash函數是不可逆的，即從摘要難以反推出原始數據。這增加了數字指紋在確保數據完整性方面的可靠性。和加密算法的區(qū)別是，摘要嚴格意義不是加密，因為沒有解密，只不過從摘要很難反推原信息，通常?來進行數據對比。

數據摘要（Data Digest）：

定義： 數據摘要是一種通過對原始數據應用哈希函數來生成固定長度摘要的技術。這個摘要通常被稱為哈希值或摘要值。過程： 哈希函數將任意大小的數據映射為固定大小的哈希值。即使原始數據的微小變化，也會導致哈希值的巨大變化，因此通過比較哈希值，可以檢測到數據的任何變化。應用： 數據摘要常用于驗證文件的完整性、密碼存儲、數字簽名等場景。在密碼學中，數據摘要是一種單向函數，不可逆。

數據指紋（Data Fingerprint）：

定義： 數據指紋是通過對原始數據應用某種算法生成的唯一標識符，類似于人類的指紋。這個標識符通常更注重數據的唯一性，而不僅僅是完整性。過程： 數據指紋生成過程可能包括使用特定的算法，如哈希函數，但也可能涉及更復雜的技術，例如使用唯一的硬件特征或基于數據內容的算法。應用： 數據指紋的應用范圍廣泛，包括數字水印、數字版權保護、防偽等。數據指紋通常用于識別特定數據的來源和完整性，并在需要追蹤或驗證數據時發(fā)揮作用。

常見算法：

MD5（Message Digest Algorithm 5）： 生成128位（16字節(jié)）的摘要，已經被認為是不安全的，因為存在碰撞風險。SHA-1（Secure Hash Algorithm 1）： 生成160位（20字節(jié)）的摘要，也因碰撞問題逐漸不再被推薦使用。SHA-256、SHA-512等： 這些是SHA-2系列的變種，分別生成256位和512位的摘要，目前被廣泛應用，相對較安全。

碰撞：

碰撞概率： 由于Hash函數將無限的輸入空間映射到有限的輸出空間，存在碰撞（兩個不同的輸入產生相同的摘要）的可能性。然而，對于安全的Hash函數，碰撞的概率非常低，確保在實際應用中極少發(fā)生。

應用：

數據完整性驗證： 數字指紋主要用于驗證數據在傳輸或存儲中是否被篡改。接收方可以重新計算數據的數字指紋并與發(fā)送方提供的數字指紋進行比較，以確定數據是否安全。密碼存儲： 在密碼學中，數字指紋也用于存儲密碼的安全哈希，以防止密碼泄露時暴露用戶的真實密碼。

總結：

共同點： 數據摘要和數據指紋都是用于確保數據完整性和唯一性的技術，它們通過生成固定長度的標識符來實現這一目標。區(qū)別： 數據摘要更注重完整性驗證，而數據指紋更注重數據的唯一性和標識。

這兩種技術都在信息安全和數據管理領域中發(fā)揮著關鍵作用，確保數據在傳輸和存儲中不受損壞或篡改。

數字簽名

摘要經過加密，就得到數字簽名（下面進行解釋）。

HTTPS的工作過程探究

既然要保證數據安全，就需要進行"加密"。

網絡傳輸中不再直接傳輸明文了，而是加密之后的"密文"。

加密的方式有很多，但是整體可以分成兩大類：對稱加密 和 非對稱加密。

方案1：只使用對稱加密

如果通信雙方都各自持有同一個密鑰X，且沒有別人知道，這兩方的通信安全當然是可以被保證的(除非密鑰被破解)

引入對稱加密之后,即使數據被截獲,由于黑客不知道密鑰是啥,因此就無法進行解密,也就不知道請求的真實內容是啥了。

但事情沒這么簡單，服務器同一時刻其實是給很多客戶端提供服務的，這么多客戶端，每個人用的秘鑰都必須是不同的(如果是相同那密鑰就太容易擴散了，黑客就也能拿到了)，因此服務器就需要維護每個客戶端和每個密鑰之間的關聯關系,這也是個很麻煩的事情。

?較理想的做法,就是能在客?端和服務器建?連接的時候,雙?協(xié)商確定這次的密鑰是啥。

但是如果直接把密鑰明文傳輸，那么黑客也就能獲得密鑰了，此時后續(xù)的加密操作就形同虛設了。因此密鑰的傳輸也必須加密傳輸!

但是要想對密鑰進行對稱加密,就仍然需要先協(xié)商確定一個"密鑰的密鑰"這就成了"先有雞還是先有蛋"的問題了.此時密鑰的傳輸再用對稱加密就行不通了。

方案2：只使用非對稱加密

鑒于非對稱加密的機制，如果服務器先把公鑰以明文方式傳輸給瀏覽器，之后瀏覽器向服務器傳數據前都先用這個公鑰加密好再傳，從客戶端到服務器信道似乎是安全的(有安全問題)，因為只有服務器有相應的私鑰能解開公鑰加密的數據。

但是服務器到瀏覽器的這條路怎么保障安全?

如果服務器用它的私鑰加密數據傳給瀏覽器，那么瀏覽器用公鑰可以解密它，而這個公鑰是一開始通過明文傳輸給瀏覽器的，若這個公鑰被中間人劫持到了，那他也能用該公鑰解密服務器傳來的信息了。

所以方案2和方案1存在一樣的問題，只能保證單向通信的安全。

方案3：雙方都使用非對稱加密

服務端擁有公鑰S與對應的私鑰S，客戶端擁有公鑰C與對應的私鑰C?？蛻艉头斩私粨Q公鑰客戶端給服務端發(fā)信息：先用公鑰S對數據加密，再發(fā)送，只能由服務器解密，因為只有服務器有私鑰S服務端給客戶端發(fā)信息：先用公鑰C對數據加密，在發(fā)送，只能由客戶端解密，因為只有客戶端有私鑰C這樣貌似也行啊，但是效率太低(因為運算速度慢，對于網絡通信是一件不友好的事)依舊有安全問題

方案4：非對稱加密 + 對稱加密

先解決效率問題

服務端具有非對稱公鑰S和私鑰S?？蛻舳税l(fā)起https請求，獲取服務端公鑰S?？蛻舳嗽诒镜厣蓪ΨQ密鑰C，通過公鑰S加密，發(fā)送給服務器。由于中間的網絡設備沒有私鑰,即使截獲了數據,也無法還原出內部的原文,也就無法獲取到對稱密鑰(真的嗎？存在安全問題)。服務器通過私鑰S解密，還原出客戶端發(fā)送的對稱密鑰C，并且使用這個對稱密鑰加密給客戶端返回的響應數據。后續(xù)客戶端和服務器的通信都只用對稱加密即可，由于該對稱密鑰只有客戶端和服務器兩個主機知道，其他主機/設備不知道密鑰即使截獲數據也沒有意義(解決效率問題)。

中間人攻擊 - 針對上面的場景

Man-in-the-MiddleAttack，簡稱“MITM攻擊”

確實，在方案2/3/4中，客戶端獲取到公鑰S之后，對客戶端形成的對稱秘鑰X，用服務端給客戶端的公鑰S進行加密，中間人即使竊取到了數據，此時中間人確實無法解出客戶端形成的密鑰X，因為只有服務器有私鑰S。

但是中間人的攻擊，如果在最開始握手協(xié)商的時候就進行了，那就不一定了，假設hacker已經成功成為中間人

服務器具有非對稱加密算法的公鑰S，私鑰S中間人具有非對稱加密算法的公鑰M，私鑰M客戶端向服務器發(fā)起請求，服務器明文傳送公鑰S給客戶端中間人劫持數據報文，提取公鑰S并保存好，然后將被劫持報文中的公鑰S替換成為自己的公鑰M,并將偽造報文發(fā)給客戶端客戶端收到報文，提取公鑰M(自己當然不知道公鑰被更換過了)，自己形成對稱秘鑰X，用公鑰M加密對稱密鑰X，形成報文發(fā)送給服務器中間人劫持后，直接用自己的私鑰M進行解密，得到通信的對稱秘鑰X，再用曾經保存的服務端公鑰S加密后，將報文推送給服務器

服務器拿到報文，用自己的私鑰S解密，得到通信秘鑰X

雙方開始采用X進行對稱加密，進行通信。但是一切都在中間人的掌握中，劫持數據，進行竊聽甚至修改,都是可以的。

上面的攻擊方案，同樣適用于方案2，方案3

問題本質出在哪里了呢？客戶端無法確定收到的含有公鑰的數據報文，就是目標服務器發(fā)送過來的！(client無法驗證公鑰的合法性)

引入證書

CA認證

服務端在使用HTTPS前，需要向CA機構申領一份數字證書，數字證書里含有證書申請者信息、公鑰信息等。服務器把證書傳輸給瀏覽器，瀏覽器從證書里獲取公鑰就行了，證書就如身份證，證明服務端公鑰的權威性。

CA認證基本說明：CA認證_百度百科

這個證書可以理解成是一個結構化的字符串,里面包含了以下信息：

證書發(fā)布機構證書有效期公鑰證書所有者簽名......

需要注意的是：申請證書的時候，需要在特定平臺生成，可以選擇生成單獨的公鑰或者一對密鑰(公鑰和私鑰)。這把公鑰就是用來在網絡通信中進行明文加密以及數字簽名的。

公鑰會隨著CSR文件，一起提交給CA進行權威認證，私鑰服務端自己進行保留，用來后續(xù)進行通信解密（其實主要就是用來交換對稱秘鑰)

可以使?在線?成CSR和私鑰：CSR在線生成工具 形成CSR之后，后續(xù)就是向CA進?申請認證，不過?般認證過程很繁瑣，?絡各種提供證書申請的服 務商，?般真的需要，直接找平臺解決就?。

注：公鑰和私鑰也可以自己進行生成，不需要特定的平臺生成(比如自己使用Linux進行生成！

自己使用Linux生成一對密鑰和CSR文件：

方法一：

下面一個例子，演示如何使用 ssh-keygen 命令來生成密鑰對。ssh-keygen 是一個用于 SSH 密鑰管理的工具，也可以生成一對公鑰和私鑰。

以下是使用 ssh-keygen 的步驟：

打開終端。運行以下命令生成密鑰對：

ssh-keygen -t rsa -b 2048 -f my_key

這將生成一對2048位的 RSA 密鑰，私鑰將保存在 my_key 文件中，而公鑰將保存在 my_key.pub 文件中。如果您不指定文件名，ssh-keygen 默認會使用 id_rsa 和 id_rsa.pub。

在生成密鑰對的過程中，系統(tǒng)可能會要求您提供密鑰的密碼。這是可選的，如果您選擇設置密碼，私鑰文件將被加密。

現在，您已經生成了一對公鑰和私鑰。私鑰文件 (my_key) 應該保持機密，而公鑰文件 (my_key.pub) 可以與其他人分享。

請注意，雖然 ssh-keygen 是一個常用的工具，但具體的工具和方法可能會因操作系統(tǒng)和使用的軟件而有所不同。在某些情況下，還可以使用編程語言（如 Python、Java 等）提供的庫來生成密鑰對。

在使用 ssh-keygen 命令生成密鑰對時，有三個主要選項，它們分別是 -t、-b、和 -f。

以下是這些選項的解釋：

-t：指定生成密鑰的算法類型（type）。在這里，rsa 表示使用 RSA 算法生成密鑰對。其他可能的值包括 dsa（Digital Signature Algorithm）和 ecdsa（Elliptic Curve Digital Signature Algorithm）等。在示例中，命令使用 -t rsa 表示生成一個 RSA 密鑰對。-b：指定密鑰的位數（bits）。在這里，2048 表示生成的 RSA 密鑰將包含 2048 位。通常，位數越多，密鑰越強大，但也會增加計算成本。您可以根據需要調整這個值。在示例中，命令使用 -b 2048 表示生成 2048 位的 RSA 密鑰。-f：指定生成的密鑰文件的名稱。在這里，my_key 是您指定的文件名前綴。生成的私鑰文件將命名為 my_key，而公鑰文件將命名為 my_key.pub。如果您不指定文件名，ssh-keygen 將使用默認的文件名，如 id_rsa 和 id_rsa.pub。

綜合起來，示例命令 ssh-keygen -t rsa -b 2048 -f my_key 表示使用 RSA 算法生成一個包含 2048 位的密鑰對，并將私鑰保存為 my_key，公鑰保存為 my_key.pub。

如果您不再需要生成的密鑰對，您可以直接刪除相應的密鑰文件。一般來說，您可以通過使用文件管理命令來刪除生成的密鑰文件也就是直接使用 rm 指令直接進行刪除即可。

方法二：

首先需要安裝 OpenSSL 工具，可以按照以下步驟進行安裝：

在 Linux 上：

使用包管理器安裝 OpenSSL。具體命令可能因您使用的 Linux 發(fā)行版而異。以下是一些示例：

在 CentOS上：

sudo yum install openssl

在Linux系統(tǒng)上，需要使用 openssl 工具生成一對密鑰。以下是使用 Linux 命令行生成密鑰對的簡單步驟：

打開終端。使用以下命令生成私鑰文件：

openssl genpkey -algorithm RSA -out private_key.pem

這將生成一個私鑰文件 (private_key.pem)，采用 RSA 算法。

如果您還需要生成相應的公鑰文件，可以運行以下命令：

openssl rsa -pubout -in private_key.pem -out public_key.pem

這將從私鑰文件提取公鑰并保存到 public_key.pem 文件中。

現在，您已經生成了一對公鑰和私鑰文件，可以根據需要在您的應用程序中使用它們。請注意，私鑰文件應該保持機密，而公鑰文件可以與其他人分享。

生成CSR文件

如果您希望生成證書請求 (CSR)，可以使用以下步驟：

生成 Certificate Signing Request (CSR) 通常是在您需要向證書頒發(fā)機構（CA）申請數字證書時執(zhí)行的步驟。CSR 包含有關您的組織信息以及公鑰的信息，CA 將使用這些信息來簽署數字證書。

以下是使用 OpenSSL 工具生成 CSR 的基本步驟：

運行以下命令生成 CSR：

openssl req -new -key private_key.pem -out my_csr.pem

這將生成 CSR，并將其保存在名為 my_csr.pem 的文件中。在這個過程中，您將需要提供有關組織、通用名（通常是您的域名）等信息。-key 選項用于指定私鑰文件，-out 選項用于指定生成的 CSR 文件。

在生成 CSR 過程中，您將需要回答一些有關組織和證書信息的問題。最重要的是 Common Name (CN)，通常是您的域名。其他信息也可以提供，但并非都是必需的。完成后，您將在指定的輸出文件中找到生成的 CSR。

請注意，CSR 是一個包含有關您組織身份的文本文件，而私鑰文件 private_key.pem 應該僅限于您自己保存。CSR 中的信息將被 CA 用于創(chuàng)建數字證書。生成 CSR 之后，您可以將其提交給 CA 進行簽名，以獲取數字證書。

生成 Certificate Signing Request (CSR) 的 OpenSSL 命令包含一系列選項，這些選項用于配置 CSR 中的各種信息。以下是生成 CSR 文件的 OpenSSL 指令及其攜帶的選項的解釋：

req: 這個命令表示進行證書請求和證書生成操作。-new: 該選項指示生成一個新的 CSR。-key private_key.pem: 這是指定私鑰文件的選項。在這里，private_key.pem 是您事先生成的私鑰文件的名稱。CSR 需要與該私鑰關聯，以便在之后對證書進行簽名時使用。-out my_csr.pem: 這是指定輸出 CSR 文件的選項。在這里，my_csr.pem 是生成的 CSR 將保存的文件名。

在運行命令時，您會有可能被要求提供一系列有關證書請求的信息，例如：

Country Name (2 letter code): 兩個字母的國家/地區(qū)代碼，例如 "US" 表示美國。State or Province Name (full name): 州或省份的全名。Locality Name (eg, city): 城市名稱。Organization Name (eg, company): 組織名稱，通常是您的公司或組織名稱。Organizational Unit Name (eg, section): 組織單位名稱，可選。Common Name (eg, fully qualified host name): 通用名稱，通常是您的域名（在TLS證書中，這是最重要的字段）。Email Address: 電子郵件地址，可選。A challenge password: 挑戰(zhàn)密碼，可選。An optional company name: 公司名稱，可選。

在提供這些信息之后，OpenSSL 將生成 CSR 文件 my_csr.pem，其中包含您提供的信息以及公鑰。該文件可以提交給證書頒發(fā)機構（CA）以簽名，以獲得最終的數字證書。請注意，私鑰文件 (private_key.pem) 應該妥善保存，而 CSR 文件可以與其他人共享(注：如有不準確請自行百度)。

進行CA認證

一旦您擁有公鑰和 CSR 文件，您就可以選擇兩種主要方式來獲取數字證書：通過證書頒發(fā)機構（CA）申請簽名證書，或者自行進行自簽名。

1. 向 CA 申請簽名證書：

如果您計劃在公共網絡上使用證書（例如，用于網站的 HTTPS），通常建議使用受信任的證書頒發(fā)機構簽署您的證書。這確保了您的證書能夠被廣泛接受，而不會被瀏覽器或其他客戶端標記為不受信任。

步驟：

將生成的 公鑰 和 CSR 文件提交給證書頒發(fā)機構（CA）(CA證書頒發(fā)機構網址,請自己百度搜索)。CA 將驗證您的身份和提供的組織信息，并使用其私鑰對您的公鑰信息進行簽名，生成一個數字證書。您收到由 CA 簽名的證書，可以在服務器上使用它。

2. 自簽名證書：

自簽名證書適用于內部使用、開發(fā)和測試等場景，但在生產環(huán)境中不太適用。自簽名證書沒有通過受信任的第三方 CA 簽名，因此在公共網絡上使用時，客戶端可能會提示證書不受信任。

步驟：

使用您的私鑰對 CSR 進行簽名，生成自簽名證書。

openssl x509 -req -in my_csr.pem -signkey private_key.pem -out my_certificate.pem

您現在可以在您的服務器上使用生成的自簽名證書。

請注意，對于生產環(huán)境，強烈建議使用受信任的 CA 簽名證書，以確保您的用戶和客戶端能夠信任您的網站或服務。自簽名證書主要用于開發(fā)和測試環(huán)境，或者在一些特定場景中，不要在公共網絡上使用自簽名證書。

理解數據簽名(數字簽名)

簽名的形成是基于數據摘要的，注意，目前暫時和https沒有關系，不要和https中的公鑰私鑰搞混

CA機構擁有非對稱加密的私鑰A和公鑰ACA機構對服務端申請的證書明文數據進行hash，形成數據摘要然后對數據摘要用CA私鑰A加密，得到數字簽名S

服務端申請的證書明文和數字簽名S共同組成了數字證書，這樣一份數字證書就可以頒發(fā)給服務端了

方案5：非對稱加密 + 對稱加密 + 證書認證

在客戶端和服務器剛一建立連接的時候,服務器給客戶端返回一個證書，證書包含了之前服務端的公鑰,也包含了網站的身份信息。

客戶端進行認證

當客戶端獲取到這個證書之后,會對證書進行校驗(防止證書是偽造的)。

判定證書的有效期是否過期判定證書的發(fā)布機構是否受信任(操作系統(tǒng)中已內置的受信任的證書發(fā)布機構)。驗證證書是否被篡改：從系統(tǒng)中拿到該證書發(fā)布機構的公鑰，對簽名解密得到一個hash值(稱為數據摘要)，設為hash1然后計算整個證書的hash值，設為hash2對比 hash1和 hash2是否相等，如果相等，則說明證書是沒有被篡改過的。

中間人有沒有可能篡改該證書？

中間人篡改了證書的明文由于他沒有CA機構的私鑰，所以無法hash之后用私鑰加密形成簽名，那么也就沒法辦法對篡改后的證書形成匹配的簽名如果強行篡改，客戶端收到該證書后會發(fā)現明文和簽名解密后的值不一致，則說明證書已被篡改，證書不可信，從而終止向服務器傳輸信息，防止信息泄露給中間人

中間人整個掉包證書？

因為中間人沒有CA私鑰，所以無法制作假的證書(為什么? )所以中間人只能向CA申請真證書，然后用自己申請的證書進行掉包這個確實能做到證書的整體掉包，但是別忘記，證書明文中包含了域名等服務端認證信息，如果整體掉包，客戶端依舊能夠識別出來。永遠記?。褐虚g人沒有CA私鑰，所以對任何證書都無法進行合法修改，包括自己的

查看瀏覽器的受信任證書發(fā)布結構

打開edge瀏覽器，點擊右上角的

選擇"設置",搜索"證書管理",即可看到以下界面.(如果沒有，在隱私設置和安全性->安全里面找找)

為什么數據摘要內容在網絡傳輸的時候一定要加密形成簽名?

在網絡傳輸過程中，為數據摘要內容加密形成數字簽名的主要目的是確保數據的完整性和身份驗證。以下是一些關鍵原因：

完整性保護： 數字簽名用于驗證數據在傳輸過程中是否被篡改。通過對數據摘要進行加密形成簽名，發(fā)送者使用私鑰進行簽名，而接收者使用相應的公鑰進行驗證。如果數據在傳輸中被篡改，數字簽名驗證將失敗，因此接收者會意識到數據完整性受到威脅。身份驗證： 數字簽名可以用于驗證數據的發(fā)送者身份。只有擁有相應私鑰的發(fā)送者才能生成有效的數字簽名。這種方式確保了接收者可以信任數據的來源，并防止惡意方冒充合法發(fā)送者。防止重播攻擊： 通過數字簽名，可以防止重播攻擊，即攻擊者截獲并多次發(fā)送相同的已簽名數據。數字簽名中包含時間戳等信息，有助于防止攻擊者重復使用相同的簽名。數據保密性： 盡管數字簽名本身并不提供數據的保密性，但在某些情況下，數字簽名的生成可能涉及到加密操作，從而確保簽名的機密性。這取決于具體的實現和使用場景。

常見的摘要算法有：MD5和SHA系列

以MD5為例,我們不需要研究具體的計算簽名的過程,只需要了解MD5的特點：

定長：無論多長的字符串,計算出來的MD5值都是固定長度(16字節(jié)版本或者32字節(jié)版本)分散：源字符串只要改變一點點,最終得到的MD5值都會差別很大。不可逆：通過源字符串生成MD5很容易,但是通過MD5還原成原串理論上是不可能的.

正因為MD5有這樣的特性,我們可以認為如果兩個字符串的MD5值相同,則認為這兩個字符串相同

理解判定證書篡改的過程:(這個過程就好比判定這個身份證是不是偽造的身份證)

假設我們的證書只是一個簡單的字符串 hello，對這個字符串計算hash值(比如md5)，結果為BC4B2A76B9719D91

如果hello中有任意的字符被篡改了,比如變成了hella,那么計算的md5值就會變化很大BDBD6F9CF51F2FD8

然后我們可以把這個字符串hello和哈希值BC4B2A76B9719D91從服務器返回給客戶端,此時客戶端如何驗證hello是否是被篡改過?

那么就只要計算hello的哈希值,看看是不是BC4B2A76B9719D91即可。

但是還有個問題,如果黑客把 hello篡改了,同時也把哈希值重新計算下,客戶端就分辨不出來了呀。

所以被傳輸的哈希值不能傳輸明文,需要傳輸密文。

所以，對證書明文(這里就是“hello”)hash形成散列摘要，然后CA使用自己的私鑰加密形成簽名，將hello和加密的簽名合起來形成CA證書，頒發(fā)給服務端，當客戶端請求的時候，就發(fā)送給客戶端，中間人截獲了，因為沒有CA私鑰，就無法更改或者整體掉包，就能安全的證明，證書的合法性。

最后，客戶端通過操作系統(tǒng)里已經存的了的證書發(fā)布機構的公鑰進行解密,還原出原始的哈希值，再進行校驗

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

使用哈希函數生成摘要而不直接對整個數據進行加密簽名有幾個關鍵原因：

效率： 哈希函數通常能夠生成固定長度的輸出，而無論輸入的數據有多大。這使得簽名操作更加高效，因為只需要對相對較小的哈希值進行加密，而不是整個數據。相比之下，直接對大量數據進行加密簽名可能更為耗時。一致性： 哈希函數產生的摘要是一個固定長度的字符串，而數字簽名的長度可能是可變的，取決于使用的算法和密鑰長度。使用哈希函數可以確保無論原始數據有多大，都能生成固定大小的簽名，方便處理和傳輸。保護私鑰： 數字簽名中使用的加密操作通常是非對稱加密，涉及公鑰和私鑰。私鑰通常用于對較小的數據塊進行簽名，以減少計算開銷。哈希函數生成的摘要作為簽名的輸入是相對較小的，從而降低了對私鑰的使用頻率，有助于保護私鑰的安全性。碰撞防御： 使用哈希函數可以減少碰撞的可能性。碰撞是指兩個不同的輸入產生相同的輸出。如果直接對整個數據進行簽名，存在更大的風險，因為不同的數據可能會產生相同的簽名，從而引發(fā)安全問題。使用哈希函數可以減小這種風險，因為哈希函數的輸出是固定長度的。

因此，通過先使用哈希函數生成摘要，可以提高效率、一致性和安全性，同時降低碰撞的風險，使數字簽名更可靠。

如何成為中間人 - 了解

ARP欺騙:在局域網中，hacker經過收到ARP Request廣播包，能夠偷聽到其它節(jié)點的(IP, MAC)地址。例，黑客收到兩個主機A, B的地址，告訴B(受害者)，自己是A，使得B在發(fā)送給A的數據包都被黑客截取ICMP攻擊:由于ICMP協(xié)議中有重定向的報文類型，那么我們就可以偽造一個ICMP信息然后發(fā)送給局域網中的客戶端，并偽裝自己是一個更好的路由通路。從而導致目標所有的上網流量都會發(fā)送到我們指定的接口上，達到和ARP欺騙同樣的效果假wifi &&假網站等

完整流程

左側都是客戶端做的事情，右側都是服務器做的事情。

HTTPS工作過程中涉及到的密鑰有三組

第一組(非對稱加密，用的是CA密鑰)：用于校驗證書是否被篡改.服務器持有私鑰(私鑰在形成CSR文件與申請證書時獲得),客戶端持有公鑰(操作系統(tǒng)包含了可信任的CA認證機構有哪些,同時持有對應的公鑰)．服務器在客戶端請求是，返回攜帶簽名的證書.客戶端通過這個公鑰進行證書驗證,保證證書的合法性，進一步保證證書中攜帶的服務端公鑰權威性。

第二組(非對稱加密，用的是服務器端的密鑰)：用于協(xié)商生成對稱加密的密鑰.客戶端用收到的CA證書中的公鑰(是可被信任的)給隨機生成的對稱加密的密鑰加密,傳輸給服務器,服務器通過私鑰解密獲取到對稱加密密鑰.

第三組(對稱加密，用的是客戶端的對稱秘鑰)：客戶端和服務器后續(xù)傳輸的數據都通過這個對稱密鑰加密解密。

其實一切的關鍵都是圍繞這個對稱加密的密鑰.其他的機制都是輔助這個密鑰工作的.第二組非對稱加密的密鑰是為了讓客戶端把這個對稱密鑰傳給服務器。

第一組非對稱加密的密鑰是為了讓客戶端拿到第二組非對稱加密的公鑰。

柚子快報激活碼778899分享：網絡協(xié)議 HTTPS

http://yzkb.51969.com/

相關閱讀