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