柚子快報(bào)激活碼778899分享：網(wǎng)絡(luò)協(xié)議 HTTPS

http://yzkb.51969.com/

目錄

HTTPS協(xié)議原理

什么是加密

為什么要加密

常見的加密方式

1.對稱加密：

2.非對稱加密：

3.數(shù)據(jù)摘要&&數(shù)據(jù)指紋

數(shù)字簽名

HTTPS的工作過程探究

方案1：只使用對稱加密

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

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

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

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

引入證書

CA認(rèn)證

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

生成CSR文件

進(jìn)行CA認(rèn)證

理解數(shù)據(jù)簽名(數(shù)字簽名)

方案5：非對稱加密 + 對稱加密 + 證書認(rèn)證

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

中間人整個掉包證書？

為什么數(shù)據(jù)摘要內(nèi)容在網(wǎng)絡(luò)傳輸?shù)臅r(shí)候一定要加密形成簽名?

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

如何成為中間人 - 了解

完整流程

HTTPS協(xié)議原理

HTTPS是什么，HTTPS也是?個應(yīng)?層協(xié)議，是在HTTP協(xié)議的基礎(chǔ)上引?了?個加密層。 HTTP協(xié)議內(nèi)容都是按照?本的?式明?傳輸?shù)?，這就導(dǎo)致在傳輸過程中出現(xiàn)?些被篡改(被抓包修改)的情況。

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

下面是HTTPS的一些主要原理和特點(diǎn)：

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

總的來說，HTTPS通過加密、身份驗(yàn)證和數(shù)據(jù)完整性保護(hù)了用戶和網(wǎng)站之間的通信，提高了網(wǎng)絡(luò)傳輸?shù)陌踩?。在現(xiàn)代互聯(lián)網(wǎng)中，許多網(wǎng)站都采用了HTTPS以確保用戶的隱私和安全。

什么是加密

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

加密過程：

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

解密過程：

密文輸入： 經(jīng)過加密得到的數(shù)據(jù)稱為密文。解密算法： 使用相應(yīng)的解密算法對密文進(jìn)行變換，還原成明文。密鑰： 解密算法通常也需要使用與加密時(shí)相同的密鑰。

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

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

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

為什么要加密

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

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

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

由于我們通過?絡(luò)傳輸?shù)娜魏蔚臄?shù)據(jù)包都會經(jīng)過運(yùn)營商的?絡(luò)設(shè)備(路由器。交換機(jī)等)，那么運(yùn)營商的?絡(luò)設(shè)備就可以解析出你傳輸?shù)臄?shù)據(jù)內(nèi)容，并進(jìn)?篡改。點(diǎn)擊"下載按鈕"，其實(shí)就是在給服務(wù)器發(fā)送了?個HTTP請求，獲取到的HTTP響應(yīng)其實(shí)就包含了該APP的下載鏈接，運(yùn)營商劫持之后，就發(fā)現(xiàn)這個請求是要下載天天動聽，那么就?動的把交給??的響應(yīng)給篡改成"QQ瀏覽器"的下載地址了。

所以：因?yàn)閔ttp的內(nèi)容是明文傳輸?shù)?，明文?shù)據(jù)會經(jīng)過路由器、wifi熱點(diǎn)、通信服務(wù)運(yùn)營商、代理服務(wù)器等多個物理節(jié)點(diǎn)，如果信息在傳輸過程中被劫持，傳輸?shù)膬?nèi)容就完全暴露了。劫持者還可以篡改傳輸?shù)男畔⑶也槐浑p方察覺，這就是|中間人攻擊，所以我們才需要對信息進(jìn)行加密。

思考下，為啥運(yùn)營商要進(jìn)行劫持?

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

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

HTTPS就是在HTTP的基礎(chǔ)上進(jìn)行了加密,進(jìn)一步的來保證用戶的信息安全

常見的加密方式

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

1.對稱加密：

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

特征：

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

常見對稱加密算法：

DES（Data Encryption Standard）： 使用56位密鑰，但由于密鑰長度短，安全性受到質(zhì)疑，已經(jīng)不再推薦使用。3DES（Triple DES）： 是對DES的改進(jìn)，對數(shù)據(jù)執(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設(shè)計(jì)，是對稱加密算法之一。

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

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

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

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

2.非對稱加密：

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

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

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

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

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

3.數(shù)據(jù)摘要&&數(shù)據(jù)指紋

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

基本原理：

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

數(shù)據(jù)摘要（Data Digest）：

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

數(shù)據(jù)指紋（Data Fingerprint）：

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

常見算法：

MD5（Message Digest Algorithm 5）： 生成128位（16字節(jié)）的摘要，已經(jīng)被認(rèn)為是不安全的，因?yàn)榇嬖谂鲎诧L(fēng)險(xiǎn)。SHA-1（Secure Hash Algorithm 1）： 生成160位（20字節(jié)）的摘要，也因碰撞問題逐漸不再被推薦使用。SHA-256、SHA-512等： 這些是SHA-2系列的變種，分別生成256位和512位的摘要，目前被廣泛應(yīng)用，相對較安全。

碰撞：

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

應(yīng)用：

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

總結(jié)：

共同點(diǎn)： 數(shù)據(jù)摘要和數(shù)據(jù)指紋都是用于確保數(shù)據(jù)完整性和唯一性的技術(shù)，它們通過生成固定長度的標(biāo)識符來實(shí)現(xiàn)這一目標(biāo)。區(qū)別： 數(shù)據(jù)摘要更注重完整性驗(yàn)證，而數(shù)據(jù)指紋更注重?cái)?shù)據(jù)的唯一性和標(biāo)識。

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

數(shù)字簽名

摘要經(jīng)過加密，就得到數(shù)字簽名（下面進(jìn)行解釋）。

HTTPS的工作過程探究

既然要保證數(shù)據(jù)安全，就需要進(jìn)行"加密"。

網(wǎng)絡(luò)傳輸中不再直接傳輸明文了，而是加密之后的"密文"。

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

方案1：只使用對稱加密

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

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

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

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

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

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

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

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

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

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

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

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

服務(wù)端擁有公鑰S與對應(yīng)的私鑰S，客戶端擁有公鑰C與對應(yīng)的私鑰C?？蛻艉头?wù)端交換公鑰客戶端給服務(wù)端發(fā)信息：先用公鑰S對數(shù)據(jù)加密，再發(fā)送，只能由服務(wù)器解密，因?yàn)橹挥蟹?wù)器有私鑰S服務(wù)端給客戶端發(fā)信息：先用公鑰C對數(shù)據(jù)加密，在發(fā)送，只能由客戶端解密，因?yàn)橹挥锌蛻舳擞兴借€C這樣貌似也行啊，但是效率太低(因?yàn)檫\(yùn)算速度慢，對于網(wǎng)絡(luò)通信是一件不友好的事)依舊有安全問題

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

先解決效率問題

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

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

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

確實(shí)，在方案2/3/4中，客戶端獲取到公鑰S之后，對客戶端形成的對稱秘鑰X，用服務(wù)端給客戶端的公鑰S進(jìn)行加密，中間人即使竊取到了數(shù)據(jù)，此時(shí)中間人確實(shí)無法解出客戶端形成的密鑰X，因?yàn)橹挥蟹?wù)器有私鑰S。

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

服務(wù)器具有非對稱加密算法的公鑰S，私鑰S中間人具有非對稱加密算法的公鑰M，私鑰M客戶端向服務(wù)器發(fā)起請求，服務(wù)器明文傳送公鑰S給客戶端中間人劫持?jǐn)?shù)據(jù)報(bào)文，提取公鑰S并保存好，然后將被劫持報(bào)文中的公鑰S替換成為自己的公鑰M,并將偽造報(bào)文發(fā)給客戶端客戶端收到報(bào)文，提取公鑰M(自己當(dāng)然不知道公鑰被更換過了)，自己形成對稱秘鑰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)行對稱加密，進(jìn)行通信。但是一切都在中間人的掌握中，劫持?jǐn)?shù)據(jù)，進(jìn)行竊聽甚至修改,都是可以的。

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

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

引入證書

CA認(rèn)證

服務(wù)端在使用HTTPS前，需要向CA機(jī)構(gòu)申領(lǐng)一份數(shù)字證書，數(shù)字證書里含有證書申請者信息、公鑰信息等。服務(wù)器把證書傳輸給瀏覽器，瀏覽器從證書里獲取公鑰就行了，證書就如身份證，證明服務(wù)端公鑰的權(quán)威性。

CA認(rèn)證基本說明：CA認(rèn)證_百度百科

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

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

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

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

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

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

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

方法一：

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

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

打開終端。運(yùn)行以下命令生成密鑰對：

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

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

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

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

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

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

以下是這些選項(xiàng)的解釋：

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

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

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

方法二：

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

在 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 算法。

如果您還需要生成相應(yīng)的公鑰文件，可以運(yùn)行以下命令：

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

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

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

生成CSR文件

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

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

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

運(yùn)行以下命令生成 CSR：

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

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

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

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

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

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

在運(yùn)行命令時(shí)，您會有可能被要求提供一系列有關(guān)證書請求的信息，例如：

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ā)機(jī)構(gòu)（CA）以簽名，以獲得最終的數(shù)字證書。請注意，私鑰文件 (private_key.pem) 應(yīng)該妥善保存，而 CSR 文件可以與其他人共享(注：如有不準(zhǔn)確請自行百度)。

進(jìn)行CA認(rèn)證

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

1. 向 CA 申請簽名證書：

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

步驟：

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

2. 自簽名證書：

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

步驟：

使用您的私鑰對 CSR 進(jìn)行簽名，生成自簽名證書。

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

您現(xiàn)在可以在您的服務(wù)器上使用生成的自簽名證書。

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

理解數(shù)據(jù)簽名(數(shù)字簽名)

簽名的形成是基于數(shù)據(jù)摘要的，注意，目前暫時(shí)和https沒有關(guān)系，不要和https中的公鑰私鑰搞混

CA機(jī)構(gòu)擁有非對稱加密的私鑰A和公鑰ACA機(jī)構(gòu)對服務(wù)端申請的證書明文數(shù)據(jù)進(jìn)行hash，形成數(shù)據(jù)摘要然后對數(shù)據(jù)摘要用CA私鑰A加密，得到數(shù)字簽名S

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

方案5：非對稱加密 + 對稱加密 + 證書認(rèn)證

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

客戶端進(jìn)行認(rèn)證

當(dāng)客戶端獲取到這個證書之后,會對證書進(jìn)行校驗(yàn)(防止證書是偽造的)。

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

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

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

中間人整個掉包證書？

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

查看瀏覽器的受信任證書發(fā)布結(jié)構(gòu)

打開edge瀏覽器，點(diǎn)擊右上角的

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

為什么數(shù)據(jù)摘要內(nèi)容在網(wǎng)絡(luò)傳輸?shù)臅r(shí)候一定要加密形成簽名?

在網(wǎng)絡(luò)傳輸過程中，為數(shù)據(jù)摘要內(nèi)容加密形成數(shù)字簽名的主要目的是確保數(shù)據(jù)的完整性和身份驗(yàn)證。以下是一些關(guān)鍵原因：

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

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

以MD5為例,我們不需要研究具體的計(jì)算簽名的過程,只需要了解MD5的特點(diǎn)：

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

正因?yàn)镸D5有這樣的特性,我們可以認(rèn)為如果兩個字符串的MD5值相同,則認(rèn)為這兩個字符串相同

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

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

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

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

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

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

所以被傳輸?shù)墓Ｖ挡荒軅鬏斆魑?需要傳輸密文。

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

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

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

使用哈希函數(shù)生成摘要而不直接對整個數(shù)據(jù)進(jìn)行加密簽名有幾個關(guān)鍵原因：

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

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

如何成為中間人 - 了解

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

完整流程

左側(cè)都是客戶端做的事情，右側(cè)都是服務(wù)器做的事情。

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

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

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

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

其實(shí)一切的關(guān)鍵都是圍繞這個對稱加密的密鑰.其他的機(jī)制都是輔助這個密鑰工作的.第二組非對稱加密的密鑰是為了讓客戶端把這個對稱密鑰傳給服務(wù)器。

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

柚子快報(bào)激活碼778899分享：網(wǎng)絡(luò)協(xié)議 HTTPS

http://yzkb.51969.com/

相關(guān)閱讀