我們先不去探究ssl的實(shí)現(xiàn)原理，我們先從設(shè)計(jì)者的角度去思考如何去建立一個(gè)安全的傳輸通道?

從第一個(gè)消息開始?

客戶端A向服務(wù)端B發(fā)送一條消息，這個(gè)消息可能會(huì)被攔截以及篡改，我們?nèi)绾巫龅紸發(fā)送給B的數(shù)據(jù)包，及時(shí)被攔截了，也沒辦法得知消息內(nèi)容并且也不能查看呢？?

利用對(duì)稱加密?

要做到消息不能被第三方查看以及篡改，那么第一想法就是對(duì)內(nèi)容進(jìn)行加密，同時(shí)，該消息還需要能被服務(wù)端進(jìn)行解密。所以我們可以使用對(duì)稱加密算法來實(shí)現(xiàn)，密鑰S扮演著加密和解密的角色。在密鑰S不公開的情況下，就可以保證安全性？?

沒那么簡單?

在互聯(lián)網(wǎng)世界，通信不會(huì)這么簡單，也許是這樣。?

會(huì)存在多個(gè)客戶端和服務(wù)端產(chǎn)生連接，而這個(gè)客戶端也許是一個(gè)潛伏者，如果他也有對(duì)稱密鑰S，那相當(dāng)于上面的方案是不可行的？如果服務(wù)端和每個(gè)客戶端通信的時(shí)候使用不同的加密算法呢？?

似乎能夠完美解決問題，然后？密鑰如何分配呢？也就是服務(wù)端怎么告訴客戶端該使用那種對(duì)稱加密算法呢？
解決辦法似乎只能通過建立會(huì)話以后進(jìn)行協(xié)商了？?

協(xié)商過程又是不安全的?

協(xié)商過程，意味著又是基于一個(gè)網(wǎng)絡(luò)傳輸?shù)那闆r下去動(dòng)態(tài)分配密鑰，可是這個(gè)協(xié)商過程又是不安全的，怎么破？?

非對(duì)稱加密出馬?

非對(duì)稱加密算法的特點(diǎn)是：私鑰加密后的密文，只要有公鑰，都能解密，但是公鑰加密后的密文，只有私鑰可以解密。私鑰只有一個(gè)人有，而公鑰可以發(fā)給所有人?

這樣就可以保證A/B向服務(wù)器端方向發(fā)送的消息是安全的。似乎我們通過非對(duì)稱加密算法解決了密鑰的協(xié)商的問題？但是?

公鑰怎么拿？?

使用非對(duì)稱加密算法，那么如何讓A、B客戶端安全地持有公鑰？?

那么我們逐步思考，有兩種我們能想到的方案：?

1. 服務(wù)器端將公鑰發(fā)送給每一個(gè)客戶端?

2. 服務(wù)器端將公鑰放到一個(gè)遠(yuǎn)程服務(wù)器，客戶端可以請(qǐng)求到 （多了一次請(qǐng)求，還得解決公鑰放置問題）?

方案一
似乎不可行，因?yàn)?#xff0c;傳輸過程又是不安全的？公鑰可能會(huì)被調(diào)包?

引入第三方機(jī)構(gòu)?

到上面這一步，最關(guān)鍵的問題是，客戶端如何知道給我公鑰的是黃蓉還是小龍女？只能找本人去證實(shí)？或者有一個(gè)第三者來幫你證實(shí)，并且第三者是絕對(duì)公正的。?

所以，引入一個(gè)可信任的第三者是一個(gè)好的方案?服務(wù)端把需要傳遞給客戶端的公鑰，通過第三方機(jī)構(gòu)提供的私鑰對(duì)公鑰內(nèi)容進(jìn)行加密后，再傳遞給客戶端？?通過第三方機(jī)構(gòu)私鑰對(duì)服務(wù)端公鑰加密以后的內(nèi)容，就是一個(gè)簡陋版本的“數(shù)字證書”。這個(gè)幀數(shù)中包含【服務(wù)器公鑰】

?客戶端拿到這個(gè)證書以后，因?yàn)樽C書是第三方機(jī)構(gòu)使用私鑰加密的。客戶端必須要有第三方機(jī)構(gòu)提供的公鑰才能解密證書。這塊又涉及到第三方機(jī)構(gòu)的公鑰怎么傳輸？（假設(shè)是先內(nèi)置在系統(tǒng)中）以及還有一個(gè)問題，第三方機(jī)構(gòu)頒發(fā)的證書是面向所有用戶，不會(huì)只針對(duì)一家發(fā)放。如果不法分子也去申請(qǐng)一個(gè)證書呢？?

如果不法分子也拿到證書？?

如果不法分子也申請(qǐng)了證書，那它可以對(duì)證書進(jìn)行調(diào)包。客戶端在這種情況下是無法分辨出收到的是你的證書，還是中間人的。因?yàn)椴徽撌侵虚g人的、還是你的證書?

都能使用第三方機(jī)構(gòu)的公鑰進(jìn)行解密。?

?

驗(yàn)證證書的有效性?

事情發(fā)展到現(xiàn)在，問題演變成了，客戶端如何識(shí)別證書的真?zhèn)?#xff1f;在現(xiàn)實(shí)生活中，要驗(yàn)證一個(gè)東西的真?zhèn)?#xff0c;絕大部分都是基于編號(hào)去驗(yàn)證（比如大學(xué)畢業(yè)證書，比如買的數(shù)碼產(chǎn)品是否是山寨），我之前講過，計(jì)算機(jī)領(lǐng)域的解決方案都是人為去實(shí)現(xiàn)的，所以在這里，解決方案也是一樣，如果給這個(gè)數(shù)字證書添加一個(gè)證書編號(hào)？是不是就能達(dá)到目的呢？?

證書上寫了如何根據(jù)證書的內(nèi)容生成證書編號(hào)。客戶端拿到證書后根據(jù)證書上的方法自己生成一個(gè)證書編號(hào)，如果生成的證書編號(hào)與證書上的證書編號(hào)相同，那么說明這個(gè)證書是真實(shí)的。這塊有點(diǎn)類似于md5的驗(yàn)證，我們下載一個(gè)軟件包，都會(huì)提供一個(gè)md5的值，我們可以拿到這個(gè)軟件包以后通過一個(gè)第三方軟件去生成一個(gè)md5值去做比較，是不是一樣如果一樣表示這個(gè)軟件包沒被篡改過?

對(duì)服務(wù)端的數(shù)據(jù)進(jìn)行MD5算法得到一個(gè)MD5的值，生成證書編號(hào)，使用第三方機(jī)構(gòu)的私鑰對(duì)這個(gè)證書編號(hào)進(jìn)行加密，并且會(huì)在證書中添加證書編號(hào)的生成算法?

瀏覽器內(nèi)置的CA公鑰可以解密服務(wù)端CA私鑰加密的證書，通過瀏覽器內(nèi)置的CA證書的證書編號(hào)算法對(duì)服務(wù)端返回的證書編號(hào)進(jìn)行驗(yàn)簽?

第三方機(jī)構(gòu)的公鑰證書存哪里？?

瀏覽器和操作系統(tǒng)都會(huì)維護(hù)一個(gè)權(quán)威的第三方機(jī)構(gòu)列表（包括他們的公鑰）?

因?yàn)榭蛻舳私邮盏降淖C書中會(huì)些頒發(fā)機(jī)構(gòu)，客戶端就根據(jù)這個(gè)辦法機(jī)構(gòu)的值在本地找到響應(yīng)的公鑰?
說到這里，我想大家一定知道，證書就是HTTPS中的數(shù)字證書，證書編號(hào)就是數(shù)字簽名，而第三方機(jī)構(gòu)就是數(shù)字證書的簽發(fā)機(jī)構(gòu)（CA）?

?

總結(jié)

以上是生活随笔為你收集整理的逆向推导https的设计过程的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。