- 一 加密知識
- 1.1 單向加密
- 1.2 對稱加密
- 1.3 非對稱加密
- 二 加密知識總結
- 從一個需求開始
相信很多人,對 https 的過程弄不清楚,只是知道 https 是安全加密的,背后的原理,過程并不清楚
筆者曾經也是對 https 的過程并不清楚,一知半解,而且最可氣的是每次面試,面試官很可能就問你這個問題
每次都答不對或者答的面試官不滿意,說來說去,還是自己沒有真正理解
其實 https 的原理過程,并沒有那么復雜,只是有些文章沒有說清楚,這樣的文章看多了,就迷糊了。
在了解 https 原理的過程之前,我們先來了解一下加密的知識
一 加密知識
加密按照加密方式,可以分為以下三種方式
1.1 單向加密
也叫做不可逆加密,對明文的加密產生一個密文,并不能再通過密文,解出來對應的明文
一般用于產生消息摘要,密鑰加密等,常見的單向加密有:
- MD5 : 相信這個大家都都熟悉了,一個明文,md5 以后,對應一個唯一的密文
- SHA : 其中又分為 sha192 , sha256
特點:
- 不可逆
- 輸入一樣,輸出必然相同
1.2 對稱加密
對稱加密,用一個密鑰,對明文進行加密,同理,同這把密鑰,也可以對密文進行解密
也就是說加密和解密,可以用同一個密鑰
這種加密方法就是 對稱加密
常用的對稱加密方法有:
- DES
- 3DES
- AES
特點:
- 加密方和解密使用同一密鑰
- 加密解密的速度比較快
1.3 非對稱加密
我們知道,對稱加密使用同一把密鑰,相反,非對稱加密,使用公鑰和私鑰進行加密解密
可以使用私鑰加密,公鑰進行解密,同理,也可以使用公鑰加密,私鑰進行解密
常見非對稱加密方式的有:
- RSA
- DSA
我們平時最常用的就是 RSA
特點:
- 使用兩把密鑰進行加密和解密,即公鑰和私鑰
- 公鑰加密私鑰解密,私鑰加密公鑰可以解密
- 加密或者解密,速度非常慢
- 私鑰和公鑰是成對出現的
二 加密知識總結
** 單向加密:** 不可逆,只要輸入的內容一樣,輸出的密文一定是一樣的,有任何修改, 產生的密文都是不同的
** 對稱加密:** 加密和解密使用同一把密鑰,加密解密速度特別快
非對稱加密: 使用公鑰和私鑰進行加密和解密,公鑰加密私鑰解,私鑰加密公鑰解。加密解密的過程非常慢
所謂公鑰,就是可以公開給別人的
所謂私鑰,就是不可以公開給別人,是自己私有保留的。
注:以上內容,純粹是加密的知識,和 https 沒有任何關系。下面我們開始講解 https 的過程。我們先看一個需求
解決了這個需求,就明白了 https 的過程了。
從一個需求開始
假設有這樣一個需求:小明和小花需要通信,少男少女寫情書嘛,肯定不想讓別人看到,所以需要安全的通信。
問題一:小明如何安全的把內容傳給小花?
通過上面的加密知識的學習,我們很容易就想到,把通信的內容,給加密了就行了啊
答案是對的,把通信的內容給加密就行了。
問題二:使用哪種加密方式加密呢?
單向加密肯定不行,小花收到信,解不出來,這戀愛沒法談
對稱加密可以 ,小花只要有密鑰,就可以把內容解出來
非對稱加密也可以 ,小明用自己的私鑰加密,小花拿到小明的公鑰,也可以把內容解出來
問題三:對稱加密,非對稱加密都可以,到底使用哪種呢?
通過上面的加密知識的學習,我們知道
對稱加密速度快,非對稱加密速度慢
那么對于小明,小花這倆人來說,經常一聊就是幾個小時,數據是非常多的
如果使用非對稱加密,那估計得郁悶死,因為加密也慢,解密也慢,這倆人肯定不會用非對稱加密,要是我,我也不用,急死個人。
那么答案就是,使用對稱加密方式 ,因為加密快啊,小明小花,都持有同一把密鑰,雙方互相都能解密出來對方發的信。
總結:小明和小花通信,使用對稱加密,假如密鑰是 S , 雙方都使用同一把密鑰 S 進行加密,解密
這樣小明和小花就能愉快的通信了,而且內容是加密的,加密解密的速度也很快,這很美好。
但是這樣有一個隱患,就是密鑰 S , 在傳輸的過程中,不小心被 老王 截獲了
造成的后果就是:小明,小花以及老王,都有相同的密鑰 S 了
那么,小明和小花之間沒有秘密可言了,他們發的信,老王都能解開看,看完再加密,再發給小花,這還得了。
那么如何解決 密鑰S 在傳輸的過程中,被別人截獲的情況呢?
有人說,可以對稱加密方式對密鑰S 進行加密, 再傳輸,那么此時的密鑰S1 也是有被截獲的風險啊
那就再對 S1 進行加密,再傳輸...... , 這樣就無窮盡了。肯定是行不能的。
上面的方法肯定是不行了,現在的問題,變成了:小明如何把 密鑰S 安全的傳給小花, 這是不是和之前的問題一小明如何安全的把內容傳給小花?類似
所以,小明和小花如何要安全的通信,就需要使用對稱加密 把信件內容加密傳輸
那么就得先解決一個問題:小明如何安全的把密鑰S 傳輸給小花?
問題四:小明如何安全的把密鑰S傳輸給小花?
如果密鑰S 的傳輸過程不安全,那么后面的通信就是不安全的,反之,如何密鑰S 能安全的傳輸給小花,那么后面的通信就是安全的。
如果這是領導交待給我們這樣一個活,我們使用自己學到的上面的加密知識,應該怎么解決呢?
通過上面的加密知識的學習,是不是有下面這樣一個安全的加密傳輸方式
- 小明使用非對稱加密進行通信,首先小明生成了自己的一對私鑰和公鑰,為了方便,分別叫做 privateKey, publicKey
- 小明把 publicKey 給了小花
- 方法一 小明用自己的 privateKey,對 密鑰S 進行加密,加密后的密文 S0 傳輸給小花,小花用 publicKey 對 S0 解密出來 密鑰S
- 方法二 小花用 publicKey 對 密鑰S 進行加密,加密后的密文 S0 傳輸給小明,小明用 privatekey 對 S0 解密出來 密鑰S
上面,方法一 是不可行的,因為小明的 publicKey 是公開的,誰都可以下載,也就是說,老王也有小明的 publicKey,也可以對 S0 進行解密出來 密鑰S
方法二是可行的,因為 privateKey 只有小明有,小花用小明的公鑰進行加密,只有小明能解開,其它任何人都解不開
所以上面的解決方案就是:
使用非對稱加密 方式,對 密鑰S 進行加密,進行傳輸
有人說,不對啊,非對稱加密 性能不好,加密解密特別慢,要不剛一開始,小明,小花直接使用非對稱加密 進行通信,不就行了嘛
說的是對的,不過我們這里只是使用非對稱加密 對 密鑰S 進行加密,這個數據量很小的,而且密鑰S 安全的傳輸給對方之后
后面的通信就直接使用對稱加密了,這樣效率就高了,而非對稱加密只是在開始協商怎么安全傳輸密鑰S 的階段使用了,此階段完成后,就不再需要使用了。
通過上面可知:非對稱加密有這樣的特性
我只要拿到誰的公鑰,我和誰通信,就是安全的
比如,你有一對私鑰和公鑰,我只要拿到你的公鑰,然后用你的公鑰進行加密傳輸內容,只有你自己能解開,因為私鑰只有你自己有
如下:
反過來,小明用自己的私鑰加密,其它人使用小明的公鑰解密,這個過程的作用是什么的呢?
答案是:驗證身份的。
只要小明用自己的私鑰加密,其它人用小明的公鑰如果能解開,那么證明這封信一定以及肯定是小明寫的
比如你需要發一個通知,但是又要確保這個通知一定是你發的,為了怕別人在中間涂改(比如古代假傳圣旨,就是沒有做好身份驗證)
你可以用你的私鑰對通知進行加密,其它人想看的話,通過下載你的公鑰,進行解密,能解密出來,說明通知一定是你發的。
因為其它人如果在中間涂改,但是又沒有你的私鑰重新加密,所以是行不通的。
總結 :通過以上的描述,我們解決了好幾個問題,經過了以下幾個過程。
- 小明和小花為了安全的通信,采用加密方式,對內容進行加密傳輸
- 對比來對比去,只能選對稱加密這種加密方式,對內容進行加密傳輸
- 但是對稱加密的密鑰S ,傳輸過程不安全,容易被老王竊取,怎么辦呢
- 小明想到了非對稱加密方式,于是就生成了一對私鑰公鑰,并且把公鑰給了小花
- 小花就用公鑰對密鑰S 進行加密,傳給小明
- 因為是用了小明的公鑰加密的,又因為私鑰只有小明自己有,所以,只有小明能解密。這個過程哪怕老王截獲了密文,也解密不了
- 這樣,小明用自己的私鑰解密出來了 密鑰S
- 此時 小明和小花就用對稱加密, 密鑰S , 進行愉快的通信了,比如商量彩禮給多少,酒席在哪辦,蜜月在哪度
- 這樣,這個通信過程就是安全的了。
上面的過程很完美,但是道高一尺,魔高一丈啊,老王腦子靈光特別好使啊,又想出來一招
既然你倆用非對稱加密,我截取到密文也解密不了,那就換個法子。
如果小花在獲取小明的公鑰的過程,出了問題,比如小花獲取的不是小明的公鑰,而且老王的公鑰呢(此時小花還以為手里的公鑰是小明的呢)
會發生什么?先看一下圖(也就是所謂的中間人攻擊)
根據上圖,老王,也叫做中間人,上圖就是中間人攻擊,流程如下:
- 小花在獲取小明公鑰的過程中,被老王給掉包成了自己的公鑰,發給了小花
- 小花誤以為手里的公鑰是小明的 (其實是老王的公鑰了),所以就用老王的公鑰對密鑰S 進行加密,得到密文S0
- 密文S0 發給小明的過程中,被老王攔截,老王就用自己的私鑰解密,得到了密鑰S
- 老王得到密鑰S 后,自己備份一份,再把此 密鑰S,用小明的公鑰加密,得到密文S1, 發給小明
- 小明得到 密文S1 后,用自己的私鑰解密,得到 密鑰S
- 以后,小明和小花,就用對稱加密方式, 密鑰S 進行通信了
- 他倆還以為很安全,其實通信的內容早就被老王先看了一遍了。還是不安全
啊啊啊,要瘋了,為了通信安全,我們就加密,但是加密的密鑰傳輸又不安全了
為了密鑰傳輸安全,我們生產了私鑰公鑰對,把公鑰給小花,小花用公鑰對密鑰加密再傳輸
這樣就只有小明能解密了,沒曾想,公鑰的傳輸又不安全了。
談個戀愛好難啊,老王啊,干的都叫啥事啊。。。
出了問題,總得解決啊,現在是傳輸公鑰的過程,又不安全了
這和上面的問題 怎么把信件內容安全的傳輸給對方?以及怎``么把密鑰安全的傳輸給對方?`` 是類似的
現在這個問題是:怎么把公鑰安全的傳輸給對方?
感覺進入到了死循環了,不管是把 信件內容安全傳輸,還是把密鑰安全傳輸,還是把 公鑰安全安全傳輸
本質都是類似的,只不過傳輸的東西不一樣,采用的方法不一樣
問題五:小明如何安全的把自己的公鑰傳輸給小花
經過上面我們解決的問題可以知道
- 如何安全的把通信內容傳輸給對方?解決方法:我們用對稱加密的方式進行通信
- 如何安全的把密鑰S 安全的傳輸給對方 ?解決方法:采用非對稱加密方式,小明把自己的公鑰給小花小花用小明的公鑰對密鑰S 加密傳給小明,小明用自己的私鑰解密這個過程只有小明能解密,所以是安全的
現在新的問題是:公鑰如何安全傳輸給對方 ?
難道再用對稱或者非對稱加密?都不對。這樣已經行不通了。
想象一下,生活中,我們有個矛盾,有個問題,我們最相信的是誰,肯定是政府啊
現在我從小明那下載公鑰已經不靠譜了,已經不安全了
到底我應該相信誰呢?到底從誰那獲取的公鑰是小明真正的公鑰呢?
所以,我們也搞一個機構,我們大家都相信這個機構,反正我就是無條件百分百相信這個機構,這是規定。
我們把這個機構起一個名字,叫做 CA 機構
好了,現在我們把問題拋給了 CA 機構,小花也好,小麗也好,小美也好,只要獲取小明的公鑰,都從 CA 那里獲取
CA 機構哪來的小明的公鑰呢?肯定是小明給的啊,對于小明來說,反正我已經把我的公鑰給你 CA 了,你 CA 機構就得保證安全的傳輸給別人
這 CA 也是夠倒霉的,你們搞不定的活,全拋給了我,又不是我和小花談戀愛。。。
抱怨歸抱怨,CA 是怎么解決的呢?
答案是 數字證書 , 怎么又出來一個名字,數字證書是個什么鬼,是不是已經繞暈了,不要急,這個時候暈了,再回過過頭再看看前面的寫的
多看看幾遍,別忘了,筆者也是看了 N 多遍,自己問自己問題,自己來嘗試解決,才搞明白這個過程的。
先來說一個結論:數字證書就是解決公鑰傳輸問題的
重要的事件重復三遍 :數字證書就是解決公鑰傳輸問題的 ,數字證書就是解決公鑰傳輸問題的 ,數字證書就是解決公鑰傳輸問題的
在說數字證書之前,我們先解決這樣一個問題
問題六:信件的傳輸過程中,如何保證內容不被篡改,即信息的完整性?
結合前面學到的加密知識,我們可以用單向加密算法,我們以 md5 加密算法舉例
- 小明給小花寫完信后,用 md5 對信件的內容作一次加密運算,得到一個唯一的字符串,我們把這個字符串起個名,叫做摘要
- 小明在信件的底部,寫上單向加密算法 md5, 以及 md5 對信件內容運算出來的摘要,一塊發給小花
- 小花收到信后,看到信件底部是 md5 算法,于是就用 md5 對信件內容進行加密算法,得到 新的摘要
- 小花將 新的摘要 和信件底部附加的 摘要 進行對比,如果相等,說明信件沒有被人改過
- 如果不相等,說明信件內容被別人改過了。
如下圖表示此過程。
但就是上面這個過程,也是有問題的,如果老王又出現了呢
- 首先老王拿到信了,把信給改了
- 老王用 md5 算法 ,重新把信件內容給 md5 一下,得到新的加密串
- 老五把新的加密串,放在信件底部,發給了小花
- 此時小花收到信后,是沒辦法判斷出來,信件是不是被篡改過的。
如下圖表示:
所以,單純的使用單向加密算法 ,生成摘要,是不能保證內容的完整性的
那么如何才能保證信件的完整性,不被人篡改呢?
答案是,簽名
又出來一個名詞,簽名,本文的名詞太多了。
通過前面學習,我們知道,非對稱加密,有 2 個作用,其中一個就是身份認證
還是上面的例子我, 我們改一下:
- 小明用 md5 對信件內容進行運算,得到一個字符串,我們起名叫摘要
- 小明用自己的私鑰對摘要進行加密運算,得到另一個字符串,我們起名叫簽名
- 將 md5, 摘要, 簽名一塊發給小花
- 小花用小明的公鑰對簽名進行解密,到得信件摘要,假如為 d1
- 小花用 md5 對信件內容進行運算,得到信件摘要,假如為 d2
- 對比 d1 和 d2 是否相等,相等說明信件內容沒有被篡改過
- d1 和 d2 不相等,說明信件內容被篡改過。
此時,這個過程就是安全的了
如果老王再次截取了信件,老王可以修改信件內容,再次用 md5 算出一個新的摘要出來
但是簽名,老王是修改不了的。因為簽名是用的小明的私鑰加密的,就算老王能解密出來
老王是沒有辦法生成新的簽名的,因為小明的私鑰只有小明自己有。
而且小花收到信后,是用小明的公鑰進行對簽名解密的,老王假如用自己的私鑰對摘要進行加密生成新的簽名
小花用小明的公鑰是解密不了的。
此時再來進行一時概念的定義
摘要 :md5(或者其它單向加密算法),對內容進行加密出來的字符串,就叫做摘要
簽名 :小明用私鑰對摘要進行加密,加密出來簽字串,就叫做簽名
驗簽 :小花用小明的公鑰,對簽名進行解密操作,解密出來的摘要和原來的對比,就叫做驗簽
問題七:數字證書是怎么由來的?
數字證書是由 CA 機構頒發的,首先小明如果想要有一個數字證書,就需要向 CA 機構申請
CA 機構就會給小明頒發一張數字證書,里面包含了
- 公鑰:小明的公鑰
- 頒發者:CA(證書認證機構)
- 有效期:證書的使用期限
- 摘要算法:指定的摘要算法,用來計算證書的摘要
- 指紋:也就是證書的摘要,保證證書的完整性
- 簽名算法:用于生成簽名,確保證書是由 CA 簽發
- 序列號:證書的唯一標識
知道了證書里面包含的內容,我們了解一下證書是如何產生的?
- 將小明的公鑰,頒發者,有效期,摘要算法 ,哈希算法寫入證書
- CA 根據證書中的指定的哈希算法,計算出整個證書的摘要,即 digest
- CA 根據簽名算法以及上一步計算出來的摘要,CA用自己的私鑰對摘要進行加密,生成 CA 的簽名,即 signature
- 最后把摘要,簽名以及證書的基本信息,一起發布,就得到了小明的證書
問題八:數字證書的作用
從上面我們知道,數字證書就是解決公鑰傳輸問題的,同時我們也知道,數字證書就是一個文件
既然數字證書是用來解決公鑰的安全傳輸的,那么到底如何解決傳輸問題的呢
現在小明有了自己的證書了,我們就不會公開傳輸公鑰了,只需要傳輸證書就行了
那么,小明和小花現在需要安全的通信,那么流程是怎么樣的呢?如下
- 小明把自己的數字證書發送給小花
- 擔心證書被老王掉包,小花需要對證書進行驗證,驗證什么呢?
- 其實就是驗證此數字到底是不是 CA 機構頒發的,不是 CA 機構頒發的證書,我們就認為傳輸是不安全的。
- 驗證數字證書是不是 CA 頒發的,需要有 CA的公鑰 。。。(為啥需要 CA 的公鑰啊,因為證書上的簽名,是 CA 的私鑰加密的啊,只有 CA 的公鑰才能解密啊)啊啊啊,受不了啦,搞了半天怎么又需要公鑰,我們講了半天的數字證書,就是為了傳輸公鑰的所以,換成下面的描述會好點驗證數字證書是不是 CA 頻發的,需要 CA 的數字證書(因為里面有 CA 的公鑰)
- 那我們去哪里找 CA 的數字證書呢?從上面的描述,我們知道了,需要一個數字證書,就向 CA 申請,CA 給我們頒發。
- 那么 CA 機構自己的數字證書哪來的呢?答案是也是自己給自己頒發的,那么我們從哪里獲取呢?
- 如果從網上,或者從其它服務器下載,又有可能會被掉包,又不安全了。
- 這真的是個傷心的故事,但是今天兔哥非要把這個故事講完。
- 從網上下載或者從其它服務器下載數字證書,都不安全的,那么怎么樣才是安全的呢?
- 答案就是:你的電腦安裝操作系統的時候,操作系統里面,就已經內置了非常多的 CA 機構的數字證書了
- 也就說,只要你安裝了操作系統,不管是 windows, linux, 或者 mac , 或者你剛買的電腦,里面都已經有了 CA 機構的數字證書了
- 這個是可以相信的,是真的 CA 機構的數字證書,不會有假。(除非你安裝的是盜版的操作系統,所以我們盡量用正版操作系統)
上面的過程真的是復雜啊,兔哥也是花了很久才搞明白的,知道這塊面試會坑很多人,其實 https 過程不知道,也沒啥關系
也不影響你寫代碼,但是那些面試官就死愛問這塊,好像他們能搞懂這個過程很了不起似的,你問點設計模式它不香嘛。
- 我們的電腦,天生就有 CA 的數字證書,而且是真的。天生的。上天定的,上天最大那么我們就可以對數字證書進行辨別真偽了。
問題九:對數字證書的驗證
從上面可以知道:
小花收到了小明的數字證書,首先要對數字證書進行驗證,就是驗證此數字證書是不是 CA 頒發的
因為我們操作系統里面內置了所有 CA 機構的數字證書,所以,我們就可以對數字證書進行驗證
在說流程之前,先來簡單的復習一下前面的,摘要和簽名怎么來的
摘要 = md5 (證書內容) :單向加密算法,比如 md5,對證書整個內容進行加密,得到摘要,也叫做證書的指紋
簽名 = privateKey (摘要) : 私鑰對上一步摘要加密,產生簽名
數字證書的驗證流程如下:
- 小花用內置的 CA 的數字證書,得到 CA 的公鑰
- 小明發過來的數字證書,我們假如叫做 C , 小花用 CA 的公鑰對 C 證書里面的簽名進行解密,得到摘要 D
- 小花根據 C 證書里面的摘要算法,假如是 md5,小花用 md5 對證書整個內容進行計算,得到摘要 D1
- 小花對比摘要 D 和摘要 D1 是否相等
- 如果 D == D1 ,那么說明此證書就是 CA 頒發的
- 如果 D != D1 , 那么說明此證書不是 CA 頒發的,是有風險的,不安全的
假如證書驗證通過,就說明此證書的確是 CA 頒發的,此時小花就可以從數字證書中拿到小明的公鑰了
因為小明在申請數字證書時,數字證書中所有者是小明,CA 是會驗證小明的身份的,所以數字證書中小明的公鑰是真實的
由至此,我們總算完成了一件事:小明正確的把自己的公鑰安全的傳輸給了小花
這件事的成立 ,接下來我們的工作就好做多了。接下來,我們看一下具體的傳輸過程
問題十 :完整的傳輸過程
下面我們看一下小明再次給小花通信,就和前面的不一樣了,我們來看下:
- 小明把寫完的信,在信的底部,附加上摘要算法,假如是 MD5, 以及通過 MD5 算出來的摘要
- 小明用自己的私鑰,對上一步的摘要進行加密,得到簽名
- 小明把摘要算法,摘要,簽名都附加到信件底部以后,再把自己的數字證書,一起發送給小花
- 小花收到信后,首先用自己的 CA 數字證書,拿到 CA 公鑰,再用 CA 公鑰對數字證書進行驗證(也就是上面我們講的流程)
- 數字證書驗證通過后,說明證書就是 CA 頒發的,沒有被篡改
- 小花就從證書中拿到了小明的公鑰
- 有了小明的公鑰,接下來的過程,就是對信件內容進行驗證了
對信件內容的驗證流程如下(前面其實我們講過)
- 小花用小明的公鑰,對信件的簽名進行解密,得到信件的摘要 D1
- 小花用摘要算法,對信件進行運算,得到信件的摘要 D2
- 小花對比 D1 是否等于 D2
- 如果不相等,說明信件被人篡改過,不安全
- 如果相等,說明,信件內容沒有被篡改過
- 相等的情況,小花就拿到了信件的內容
總結:
以上所有的內容,是數字證書,加密解密,簽名,驗簽的過程,還沒有正式講 https 的過程呢。
有了以上的知識,我們講起來 https 就容易的多了。下面我們看一張圖
我們以訪問 www.helloworld.NET 網站為例,講解 https 的過程
此過程分為 3 個階段,我們在下面描述此 3 個階段
訪問 www.helloworld.net 的過程 階段如下
- 網站申請證書階段
- 網站向 CA 機構申請數字證書(需要提交一些材料,比如域名)
- CA 向證書中寫入摘要算法,域名,網站的公鑰等重要信息
- CA 根據證書中寫入的摘要算法,計算出證書的摘要
- CA 用自己的私鑰對摘要進行加密,計算出簽名
- CA 生成一張數字證書,頒發給了 www.helloworld.net
- 網站的管理員,把證書放在自己的服務器上
- 瀏覽器驗證證書階段
- 瀏覽器在地址欄中輸入 https://www.helloworld.net,并回車
- 服務器將數字證書發送給瀏覽器
- 瀏覽器用操作系統內置的 CA 的數字證書,拿到 CA 的公鑰
- 瀏覽器用 CA 公鑰對 www.helloworld.net 的數字證書進行驗簽
- 具體就是,瀏覽器用 CA 公鑰,對 helloworld 的數字證書中的簽名進行解密,得到摘要 D1
- 瀏覽器根據 helloworld 數字證書中的摘要算法,計算出證書的摘要 D2
- 對比 D1 和 D2 是否相等。
- 如果不相等,說明證書被掉包了
- 如果相等,說明證書驗證通過了。
- 協商對稱加密密鑰階段
- 瀏覽器驗證數字證書通過以后
- 瀏覽器拿到數字證書中的公鑰,也就是 www.helloworld.net 網站的公鑰
- 瀏覽器有了網站的公鑰后,就用公鑰進行對密鑰S 進行加密,加密以后的密文發送給服務器
- 服務器收到密文后,用自己的私鑰進行解密,得到密鑰S
- 此后瀏覽器,服務器雙方就用密鑰S 進行對稱加密的通信了。
終止所述,終于講完了,花了整整一天的時間
過程那么多,其實抓住幾個關鍵的問題是很簡單的,本質上還是兩個人,如何安全高效的進行通信
我們再次簡單的總結一下,采用一問一答的方式,我覺得比較好
問題一:小明和小花安全的通信,怎么做?
答:通過加密
問題二:通過哪種加密方式通信,更高效?
答:對稱加密
因為,單向加密,沒辦法解密,不行
非對稱加密,太慢,也不行
只有對稱加密,速度快
問題三:采用對稱加密,密鑰 S 怎么安全傳輸?
答:小花使用小明的公鑰,對密鑰S 進行加密,傳給小明
小明用自己的私鑰解密
問題四:小明如何安全的把自己的公鑰傳輸給小花?
答:使用數字證書
具體就是 小明向 CA 申請一個自己的數字證書,把自己的公鑰放在證書中
小明將數字證書發送給小花
問題五:小花如何驗證數字證書的真實性?
答:小花用操作系統內置的 CA 的數字證書,拿到 CA 的公鑰,用 CA 的公鑰,對數字證書進行驗簽
驗簽通過,說明數字證書是真的。
以上幾個問題,希望讀者多問問自己,如果是自己,應該怎么解決這個問題。