對(duì)于https的簡(jiǎn)單了解.
??????? 我們這一次來討論一下有關(guān)于https的相關(guān)知識(shí). 其中最重要的就是有關(guān)于加密方式的知識(shí). https中到底是對(duì)稱加密還是非對(duì)稱加密?? 為什么要選用對(duì)稱加密, 或者是非對(duì)稱加密? 玄機(jī)何在?? 這一小節(jié), 我們一起來看一看.
?????? 有關(guān)于加密, 我們首先來看一下不加密的情況, 一般在計(jì)算機(jī)中, 不加密我們成為'裸奔'. 如果數(shù)據(jù)不加密, 則很容易被黑客竊取到. 如下圖所示:
所以針對(duì)這樣的情況, 我們應(yīng)該在數(shù)據(jù)傳輸?shù)倪^程中進(jìn)行對(duì)應(yīng)的加密,那么問題來了,我們應(yīng)該選擇哪種加密方式呢?? 我們知道: 常見的加密方式有對(duì)稱加密和非對(duì)稱加密之分, 例如我們這里選擇對(duì)稱加密的形式. 則如下圖所示:
我們可以把data數(shù)據(jù), 配合秘鑰, 進(jìn)行f()函數(shù)運(yùn)算, 進(jìn)而得到密文: XXX, 再把XXX傳遞到服務(wù)器端,從而使數(shù)據(jù)的傳輸進(jìn)行加密, 但是這樣也面臨一些對(duì)應(yīng)的問題, 我們知道, 對(duì)稱加密的秘鑰是由后端生成的, 但是該秘鑰往往只有一個(gè), 因?yàn)楹蠖瞬豢赡転槊恳粋€(gè)人設(shè)置一個(gè)秘鑰, 否則后端存儲(chǔ)的秘鑰就太多了. 既然秘鑰只有一個(gè), 那么前端想要解密就需要獲取該秘鑰. 這也就是不安全的地方了. 因?yàn)楹诳鸵部梢詡窝b成良民(普通的客戶端), 拿取到對(duì)應(yīng)的秘鑰, 從而對(duì)獲取的數(shù)據(jù)進(jìn)行解密處理. 所以對(duì)稱加密的方式其實(shí)是不安全的. 雖然進(jìn)行了加密但是黑客可以很容易就進(jìn)行解密.
???????? 對(duì)稱加密這么不安全, 那么非對(duì)稱加密呢? 是不是非常安全. 接下來讓我們一起來看一下:
從上圖我們可以知道, 使用非對(duì)稱加密有兩種加密方式:? 公鑰加密,私鑰解密, 私鑰加密, 公鑰解密.
一開始服務(wù)端生成一對(duì)公私鑰(pk,?sk).我們要想進(jìn)行密文通訊, 需要客戶端獲取對(duì)應(yīng)的公鑰(pk). 所以客戶端會(huì)發(fā)送請(qǐng)求, 請(qǐng)求公鑰.? 客戶端獲取到pk后, 會(huì)把數(shù)據(jù)放到f() 方法中進(jìn)行對(duì)應(yīng)的加密, 所用的秘鑰就是剛剛獲取的pk. 加密后得到的XXX就是密文. 所以我們可以把數(shù)據(jù)傳輸給服務(wù)器端.
這個(gè)時(shí)候, 如果黑客截取了對(duì)應(yīng)的XXX數(shù)據(jù), 黑客將沒法獲取對(duì)應(yīng)的明文數(shù)據(jù), 因?yàn)樗麤]有獲取對(duì)應(yīng)的公鑰(pk).
但是非對(duì)稱加密的缺點(diǎn)來了: 如果服務(wù)端想要給客戶端傳遞數(shù)據(jù), 也需要加密該怎么辦呢? 如果使用私鑰加密, 把加密的字段YYY傳輸給客戶端, 看似沒有問題, 但是細(xì)細(xì)想一下, 我們就會(huì)知道黑客也是可以充當(dāng)良民從而獲取公鑰(pk)的. 也就是說, 只要是使用私鑰(sk)加密的方法, 黑客都可以對(duì)其進(jìn)行解密.
總結(jié)發(fā)現(xiàn):? 單獨(dú)使用對(duì)稱加密, 不安全, 單獨(dú)使用非對(duì)稱加密, 也不安全. 那么應(yīng)該怎么解決呢?
經(jīng)過科學(xué)家的努力. 我們就想到了能不能把兩者結(jié)合到一起呢?
例如下面的圖片顯示:
通過上面的圖片, 我們知道, 先通過請(qǐng)求, 獲取服務(wù)端的pk, 拿到之后, 我們可以在客戶端隨機(jī)產(chǎn)生一個(gè)key, 然后通過f(pk, key) = XXX的方式, 把XXX傳輸給服務(wù)端, 這樣服務(wù)端就可以通過私鑰(sk)對(duì)XXX進(jìn)行解密, 從而得到key. 以后我們就可以通過key, 作為秘鑰, 進(jìn)行對(duì)稱加密了.
這樣的方式是非常棒的. 通過這樣的方式我們會(huì)覺得數(shù)據(jù)是非常安全的.
但是真的安全嗎?
其實(shí)是不對(duì)的, 如果我們?cè)O(shè)想一下. 黑客如果從最開始就對(duì)我們的通訊進(jìn)行了監(jiān)聽. 那么我們獲取公鑰的過程也會(huì)被監(jiān)聽到.? 而我們知道, 非對(duì)稱加密的公鑰(pk), 黑客也是可以獲取的. 所以一旦公鑰泄露. key就會(huì)泄露, key泄露, 則后面的全部對(duì)稱加密都稱不上是安全的. 所以后面很安全,但是如何保證pk的傳輸也是安全的就至關(guān)重要了.
那么該如何解決這個(gè)問題呢?
我們可以對(duì)上面的內(nèi)容再次進(jìn)行優(yōu)化, 例如我們這里引入一個(gè)'CA機(jī)構(gòu)',? 'CA機(jī)構(gòu)' 是一種信用機(jī)構(gòu). 主要靠信用賺錢, 一般來說都是全球的大型機(jī)構(gòu). 這類機(jī)構(gòu)也會(huì)有自己的公鑰(cpk)和私鑰(csk), 可以使用csk對(duì)于pk公鑰進(jìn)行加密, 從而得到證書, 我們可以把證書傳遞給前端, 讓前端利用瀏覽器內(nèi)部自帶的公鑰(cpk)對(duì)證書進(jìn)行解密, 如果解密成功, 則可以獲取到pk, 隨后再利用pk對(duì)前端生成的key進(jìn)行加密. 重復(fù)之前的步驟.
通過上面的步驟, 其實(shí)我們就能夠得到完整的, 安全的通訊方式了. 這個(gè)其實(shí)就是https通訊方式中的最主要的加密方式介紹.
好了. 通過上面的學(xué)習(xí), 我們可以知道https通訊其實(shí)使用了非對(duì)稱加密和對(duì)稱加密的多種方式來進(jìn)行的.
