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

http://yzkb.51969.com/

文章目錄

加密對稱加密非對稱加密

數(shù)據(jù)摘要 && 數(shù)據(jù)指紋應(yīng)用場景

HTTPS的加密過程CA認(rèn)證CA簽名的形成

HTTPS的最終方案

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

加密

加密就是把明文(要傳輸?shù)男畔?進(jìn)行?系列變換, 生成密文.解密就是把密文再進(jìn)??系列變換, 還原成明文. 在這個(gè)加密和解密的過程中, 往往需要?個(gè)或者多個(gè)中間的數(shù)據(jù), 輔助進(jìn)?這個(gè)過程, 這樣的數(shù)據(jù)稱為 密鑰.

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

對稱加密

采用單鑰密碼系統(tǒng)的加密方法法，同?個(gè)密鑰可以同時(shí)?作信息的加密和解密，這種加密?法稱為對稱加密，也稱為單密鑰加密，特征：加密和解密所用的密鑰是相同的 常見對稱加密算法(了解)：DES、3DES、AES、TDEA、Blowfish、RC2等 特點(diǎn)：算法公開、計(jì)算量小、加密速度快、加密效率高 對稱加密其實(shí)就是通過同?個(gè) “密鑰” , 把明文加密成密文, 并且也能把密?解密成明文.

非對稱加密

需要兩個(gè)密鑰來進(jìn)?加密和解密，這兩個(gè)密鑰是公開密鑰（public key，簡稱公鑰）和私有密鑰private key，簡稱私鑰。 常??對稱加密算法：RSA，DSA，ECDSA 特點(diǎn)：算法強(qiáng)度復(fù)雜、安全性依賴于算法與密鑰但是由于其算法復(fù)雜，?使得加密解密速度沒有對稱加密解密的速度快。 ?對稱加密要?到兩個(gè)密鑰, ?個(gè)叫做 “公鑰”, ?個(gè)叫做 “私鑰”. 公鑰和私鑰是配對的. 最?的缺點(diǎn)就是運(yùn)算速度非常慢，?對稱加密要慢很多.

通過公鑰對明文加密, 變成密文，通過私鑰對密文解密, 變成明文通過私鑰對明文加密, 變成密文， 通過公鑰對密文解密, 變成明文

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

數(shù)字指紋(數(shù)據(jù)摘要),其基本原理是利?單向散列函數(shù)(Hash函數(shù))對信息進(jìn)行運(yùn)算,?成?串固定?度 的數(shù)字摘要。數(shù)字指紋并不是?種加密機(jī)制,但可以?來判斷數(shù)據(jù)有沒有被竄改。摘要常見算法：有MD5、SHA1、SHA256、SHA512等，算法把?限的映射成有限，因此可能會有 碰撞（兩個(gè)不同的信息，算出的摘要相同，但是概率非常低）摘要特征：和加密算法的區(qū)別是，摘要嚴(yán)格意義不是加密，因?yàn)闆]有解密，只不過從摘要很難反推 原信息，通常用來進(jìn)行數(shù)據(jù)對比

通過哈希函數(shù)將信息轉(zhuǎn)化為散列值，這個(gè)過程是不可逆的，也就是說可以通過判斷哈希出來的散列是否相同可以知道數(shù)據(jù)是否被修改，但是這個(gè)過程是不可逆的，直到散列值是不能知道數(shù)據(jù)的。

應(yīng)用場景

http在某些場景中需要想服務(wù)器交付我們用戶的密碼時(shí)，如果不經(jīng)過任何處理，密碼泄漏的風(fēng)險(xiǎn)是很大的，并且在后端MySql中存儲的密碼如果泄漏了，那么用戶都需要修改密碼，影響較大，所以可以在想服務(wù)器傳送密碼這種關(guān)鍵的數(shù)據(jù)時(shí)直接通過MD5來進(jìn)行散列化，然后在服務(wù)器后端存儲的也是散列化后的數(shù)據(jù)，這樣就算密碼泄露了也沒事，因?yàn)檫M(jìn)行散列化，拿到了也沒有用。當(dāng)用戶需要驗(yàn)證登錄的時(shí)候，把輸入后的密碼進(jìn)行散列化后和后端的數(shù)據(jù)對比就可以了。在網(wǎng)盤等領(lǐng)域，用戶存入的數(shù)據(jù)是很多的，同樣用戶存儲的相同的數(shù)據(jù)也是非常多的，假設(shè)兩個(gè)人今天都像網(wǎng)盤上傳了一個(gè)電影，那么后端同樣的數(shù)據(jù)存在兩份太浪費(fèi)空間了，所以可以把這個(gè)電影形成一個(gè)數(shù)據(jù)指紋，形成一個(gè)指紋庫，當(dāng)用戶上傳一個(gè)電影前先無判斷這個(gè)電影形成的指紋是否在指紋庫中，如果在就不用上傳了，直接給該用戶建立一個(gè)鏈接文件就可以了。

HTTPS的加密過程

只使用對稱加密 如果通信雙?都各?持有同?個(gè)密鑰X，且沒有別?知道，這兩?的通信安全當(dāng)然是可以被保證的（除?密鑰被破解） 引?對稱加密之后,中間人即使數(shù)據(jù)被截獲,但是由于中間人不知道秘鑰是啥,中間人因此就無法進(jìn)行解密,中間人也就不知道請求的真實(shí)內(nèi)容是啥了.但是服務(wù)器要和很多客服端通信，和每個(gè)客服端的秘鑰還不能一樣，如果是相同那秘鑰就太容易擴(kuò)散了,中間人就也能拿到了，所以服務(wù)器一定要進(jìn)行管理這些秘鑰，管理這些秘鑰也是一個(gè)麻煩的事情。所以為了不用對密鑰進(jìn)行管理，雙方在建立連接時(shí)就需要進(jìn)行秘鑰的協(xié)商。 但是密鑰不能明文傳送，所以這個(gè)問題就變得無解了。 只使用非對稱加密 如果服務(wù)器先把公鑰以明??式傳輸給瀏覽器，之后瀏覽器向服務(wù)器傳數(shù)據(jù)前都先?這個(gè)公鑰加密好再傳，從客?端到服務(wù)器信道似乎是安全的(有安全問題)，因?yàn)橹挥蟹?wù)器有相應(yīng)的私鑰能解開公鑰加密的數(shù)據(jù)。如果服務(wù)器?它的私鑰加密數(shù)據(jù)傳給瀏覽器，那么瀏覽器?公鑰可以解密它，?這個(gè)公鑰是?開始通過明?傳輸給瀏覽器的，若這個(gè)公鑰被中間?劫持到了，那他也能?該公鑰解密服務(wù)器傳來的信息了。所以這個(gè)方案也是不行的。 雙方都是用非對稱加密 方案二已經(jīng)已經(jīng)解決了客服端到服務(wù)器的安全通信，所以我們只需要在給客服端使用一下非對稱加密，把公鑰給服務(wù)器，然后服務(wù)器就可以通過公鑰加密的方式安全的把數(shù)據(jù)交給客服端，但是依舊存在安全問題，并且非對稱加密的效率太低了。 ?對稱加密+對稱加密 服務(wù)端具有?對稱公鑰S和私鑰S’，然后客戶端發(fā)起請求得到公鑰S，然后通過公鑰把對稱加密的秘鑰發(fā)送給服務(wù)端，這樣雙方就可以安全的知道對稱加密的秘鑰，所以之后就可以使用對稱加密進(jìn)行安全通信。由于中間人沒有私鑰S’,所以對稱加密是安全的。 但是這種場景依舊存在安全問題?。?！ 比如說：服務(wù)器存在公鑰S和私鑰S’，中間人也存在公鑰M和私鑰M’，客戶端向服務(wù)器發(fā)送請求公鑰S，但是公鑰S被中間人拿走保存起來，把自己的公鑰M發(fā)送給了客戶端，客戶端收到報(bào)文，客戶端不知道公鑰被替換過了，所以就拿著這個(gè)公鑰M給服務(wù)器發(fā)送形成的對稱加密的秘鑰X，中間人收到后，解析出來X然后用S加密發(fā)送給服務(wù)器，然后服務(wù)器和客戶端中間人都知道了X，這樣一來，所有的數(shù)據(jù)都在中間人的掌握之中，對數(shù)據(jù)進(jìn)行修改都是可以的。

所以這個(gè)問題的核心在哪？？ 核心就在于客戶端不知道，無法判定收到公鑰的安全性。所以就需要在方案四的基礎(chǔ)上引入證書了。

CA認(rèn)證

服務(wù)端在使?HTTPS前，需要向CA機(jī)構(gòu)申領(lǐng)?份數(shù)字證書，數(shù)字證書?含有證書申請者信息、公鑰信息等。服務(wù)器把證書傳輸給瀏覽器，瀏覽器從證書?獲取公鑰就?了，證書就如?份證，證明服務(wù)端公鑰的權(quán)威性。 這個(gè)證書可以理解為一個(gè)結(jié)構(gòu)化的字符串。 申請證書的時(shí)候，需要在特定平臺?成查找，會同時(shí)?成?對?密鑰對?，即公鑰和私鑰。這對密鑰對?就是?來在?絡(luò)通信中進(jìn)?明?加密以及數(shù)字簽名的。其中公鑰會隨著CSR?件，?起發(fā)給CA進(jìn)?權(quán)威認(rèn)證，私鑰服務(wù)端??保留，?來后續(xù)進(jìn)?通信（其實(shí)主要就是?來交換對稱秘鑰）

CSR文件是可以在線生成的 https://myssl.com/csr_create.html。

CA簽名的形成

簽名的形成是基于?對稱加密算法的。 CA通過hash函數(shù)對服務(wù)器提供的數(shù)據(jù)進(jìn)行散列值，然后用自己的私鑰進(jìn)行加密形成簽名，然后服務(wù)器提供的很多數(shù)據(jù)都是公開明文的，為證書明文，周狗證書明文和簽名一起為數(shù)字簽名證書。就可以發(fā)給服務(wù)器了。

從此以后服務(wù)器可以直接給客戶端發(fā)送證書就行了?？蛻舳藢ψC書進(jìn)行驗(yàn)證。 客戶端得到數(shù)字證書后，得到數(shù)據(jù)和簽名，把數(shù)據(jù)通過同樣的hash函數(shù)形成散列值，然后通過CA的公鑰把簽名進(jìn)行解密，這就意味著所有的客戶端會有CA的公鑰，所以CA的公鑰一般是內(nèi)置在瀏覽器中的，然后把形成的散列值和簽名進(jìn)行對比，相等就說明數(shù)據(jù)沒有被修改，是可以相信的。通過這種方式可以很好的讓客戶端判斷得到的公鑰的合法性。

就算中間人想要破壞，也是會被客戶端發(fā)現(xiàn)的。如果中間人到了證書，如果修改數(shù)據(jù)，那么客戶端一定會知道，如果修改簽名，那么沒有什么意義，如果都修改了，因?yàn)楹灻切枰狢A的私鑰形成的，所以自己無法形成，因此就需要去CA申請一個(gè)合法的證書，但是這個(gè)證書中是存在域名的，所以中間人形成的證書的域名一定和我們自己的是不一樣的，這樣客戶端也可以發(fā)現(xiàn)，所以通過這種方式可以很好的解決這個(gè)問題。

HTTPS的最終方案

?對稱加密+對稱加密+證書認(rèn)證

客戶端行服務(wù)器請求連接，服務(wù)器給客戶端一個(gè)證書，客戶端一定可以拿到正確的公鑰，所以就可以把對稱加密的私鑰傳遞給服務(wù)器，接下來皆可以通過方案4來完成后續(xù)通信。 總結(jié)：

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

http://yzkb.51969.com/

相關(guān)閱讀