国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

【轉(zhuǎn)載】這是我看過最好的對HTTPS的理解

WelliJhon / 3122人閱讀

摘要:對于與這樣的簡單通信模型,我們很容易做出選擇這時對稱加密算法,其中圖中的密鑰同時扮演加密和解密的角色。好了,如何協(xié)商加密算法的問題,我們解決了使用非對稱加密算法進(jìn)行對稱加密算法協(xié)商過程。這其實就是密碼學(xué)中提到的身份驗證問題。

【轉(zhuǎn)載】這是我看過最好的對HTTPS的理解
首先申明,這篇文章并非原創(chuàng)。而是最近想去研究一下https的原理,所以上網(wǎng)查閱了一大堆資料和文檔,其實看來看去都是差不多的,直到發(fā)現(xiàn)了這一篇。為作者打個電話先~

原文出處:http://blog.jobbole.com/110354/

摘要:本文嘗試一步步還原HTTPS的設(shè)計過程,以理解為什么HTTPS最終是這幅模樣。但是這并不代表HTTPS的真實設(shè)計過程。在閱讀本文時,你可以嘗試放下已有的對HTTPS的理解,這樣更利于“還原”過程。

我們先不聊HTTP,HTTPS,我們先從一個聊天軟件說起,我們要實現(xiàn)A能發(fā)送一個hello消息給B:

如果我們要實現(xiàn)這個聊天軟件,本文只考慮安全性問題,要實現(xiàn)

A發(fā)給B的hello消息包,即使被中間人攔截到了,也無法得知消息的內(nèi)容
如何做到真正的安全?

這個問題,很多人馬上就想到了各種加密算法,什么對稱加密、非對稱加密、DES、RSA、XX、噼里啪啦~

而我想說,加密算法只是解決方案,我們首先要做的是理解我們的問題域——什么是安全?

我個人的理解是:

A與B通信的內(nèi)容,有且只有A和B有能力看到通信的真正內(nèi)容

好,問題域已經(jīng)定義好了(現(xiàn)實中當(dāng)然不止這一種定義)。對于解決方案,很容易就想到了對消息進(jìn)行加密。

題外話,但是只有這一種方法嗎?我看未必,說不定在將來會出現(xiàn)一種物質(zhì)打破當(dāng)前世界的通信假設(shè),實現(xiàn)真正意義上的保密。

對于A與B這樣的簡單通信模型,我們很容易做出選擇:

這時對稱加密算法,其中圖中的密鑰S同時扮演加密和解密的角色。具體細(xì)節(jié)不是本文范疇。

只要這個密鑰S不公開給第三者,同時密鑰S足夠安全,我們就解決了我們一開始所定的問題域了。因為世界上有且只有A與B知道如何加密和解密他們之間的消息。

但是,在WWW環(huán)境下,我們的Web服務(wù)器的通信模型沒有那么簡單:

如果服務(wù)端對所有的客戶端通信都使用同樣的對稱加密算法,無異于沒有加密。那怎么辦呢?即能使用對稱加密算法,又不公開密鑰?

答案是:Web服務(wù)器與每個客戶端使用不同的對稱加密算法:

如何確定對稱加密算法?

慢著,另一個問題來了,我們的服務(wù)器怎么告訴客戶端該使用哪種對稱加密算法?

當(dāng)然是通過協(xié)商。

但是,你協(xié)商的過程是沒有加密的,還是會被中間人攔截。那我們再對這個協(xié)商過程進(jìn)行加密就好了,那你對協(xié)商過程加密的加密還是沒有加密,怎么辦?再加密不就好了。好吧,進(jìn)行雞生蛋蛋生雞的問題了。

如何對協(xié)商過程進(jìn)行加密?

新問題來了,如何對協(xié)商過程進(jìn)行加密?密碼學(xué)領(lǐng)域中,有一種稱為“非對稱加密”的加密算法,特點(diǎn)是私鑰加密后的密文,只要是這個私鑰對應(yīng)的公鑰,都可以解密;但是公鑰加密后的密文,只有這個公鑰對應(yīng)的私鑰可以解密。私鑰只有一個人有,而公鑰可以發(fā)給所有的人。

雖然服務(wù)端向A、B......的方向還是不安全的,但是至少A、B向服務(wù)端方向是安全的。

好了,如何協(xié)商加密算法的問題,我們解決了:使用非對稱加密算法進(jìn)行對稱加密算法協(xié)商過程。

這下,你明白為什么HTTPS同時需要對稱加密算法和非對稱加密算法了吧?

協(xié)商什么加密算法?

要達(dá)到Web服務(wù)器針對每個客戶端使用不同的對稱加密算法,同時,我們也不能讓第三者針對這個對稱加密算法是什么,怎么辦?

使用隨機(jī)數(shù),就是使用隨機(jī)數(shù)來生成對稱加密算法。這樣就可以做到服務(wù)器和客戶端每次交互都是新的加密算法、只有交互的那一刻才確定加密算法。

這下,你明白為什么HTTPS協(xié)議握手階段會有這么多的隨機(jī)數(shù)了吧。

如何得到公鑰?

細(xì)心的人可能已經(jīng)注意到了如果使用非對稱加密算法,我們的客戶端A、B需要一開始就持有公鑰,要不沒法開展加密行為啊。

這下,我們又遇到新問題了,如何讓A、B客戶端安全的得到公鑰?

方案1、服務(wù)器端將公鑰發(fā)送給每一個客戶端

方案2、服務(wù)器端將公鑰放到一個遠(yuǎn)程服務(wù)器,客戶端可以請求得到

我們選擇方案1,因為方案2又多了一次請求,還要另外處理公鑰的放置位置。

公鑰被掉包了怎么辦?又是一個雞生蛋蛋生雞問題?

但是方案1有個問題:如果服務(wù)器端發(fā)送公鑰給客戶端時,被中間人掉包了,怎么辦?

原理如下:

顯然,讓每個客戶端的每個瀏覽器默認(rèn)保存所有網(wǎng)站的公鑰是不現(xiàn)實的。

使用第三方機(jī)構(gòu)的公鑰解決雞生蛋蛋生雞問題

公鑰被掉包的問題出現(xiàn),是因為我們的客戶端無法分辨返回公鑰的人到底是中間人,還是真的服務(wù)器。這其實就是密碼學(xué)中提到的身份驗證問題。

如果讓你來解決,你怎么解決?如果你了解過HTTPS,會知道使用數(shù)字證書來解決。但是你想過證書的本質(zhì)是什么么?請放下你對HTTPS已有的知識,自己嘗試找到解決方案。

我是這樣解決的。既然服務(wù)器需要將公鑰傳給客戶端,這個過程本身是不安全的,那么我們?yōu)槭裁床粚@個過程本身再加密一次?可是,你是使用對稱加密,還是非對稱加密?這下好了,我感覺又近了雞生蛋蛋生雞問題了。

問題的難點(diǎn)是如果我們選擇直接將公鑰傳遞給客戶端的方案,我們始終無法解決公鑰傳遞被中間人掉包的問題。

所以,我們不能直接將服務(wù)器的公鑰傳遞給客戶端,而是第三方機(jī)構(gòu)使用它的私鑰對我們的公鑰進(jìn)行加密后,再傳給客戶端。客戶端再使用第三方機(jī)構(gòu)的公鑰進(jìn)行解密。

下圖就是我們設(shè)計的第一版“設(shè)計證書”,證書中只有服務(wù)器交給第三方機(jī)構(gòu)的公鑰,而且這個公鑰被第三方機(jī)構(gòu)的私鑰加密了:

如果能解密,就說明這個公鑰沒有被中間人掉包。因為如果中間人使用自己的私鑰加密后的東西東西傳給客戶端,客戶端時無法使用第三方的公鑰進(jìn)行解密的。

說到這里,我以為解決問題了。但是現(xiàn)實中HTTPS,還有一個數(shù)字簽名的概念,我沒法理解它的設(shè)計理由。

原來,我漏掉了一個場景:第三方機(jī)構(gòu)不可能只給你一家公司制作證書,它也可能會給中間人這樣有壞心思的公司發(fā)放證書。這樣,中間人就有機(jī)會對你的證書進(jìn)行掉包,客戶端在這種情況下無法分辨出接受的是你的證書,還是中間人的。因為不論中間人,還是你的證書,都能使用第三方機(jī)構(gòu)的公鑰進(jìn)行解密,像下面這樣:

第三方機(jī)構(gòu)向多家公司頒發(fā)證書的情況:

客戶端能解密同一家第三方機(jī)構(gòu)頒發(fā)的所有證書:

最終導(dǎo)致其它持有同一家第三方機(jī)構(gòu)證書的中間人可以進(jìn)行調(diào)包:

數(shù)字簽名,解決同一機(jī)構(gòu)發(fā)的不同證書被篡改問題

要解決這個問題,我們首先要清楚一個問題,辨別同一機(jī)構(gòu)下不同證書的這個職責(zé),我們應(yīng)該放在哪?

只能放到客戶端了。意思是,客戶端在拿到證書后,自己就有能力分別證書是否被篡改了。如何才能有這個能力呢?

我們從現(xiàn)實中找靈感。比如你是HR,你手上拿到候選人的學(xué)歷證書,證書上寫了持證人,頒發(fā)機(jī)構(gòu),頒發(fā)時間等等,同時證書上,還有一個最重要的:證書編號!我們怎么鑒別這張證書的真?zhèn)文兀恐灰眠@個證書編號上相關(guān)機(jī)構(gòu)去查,如果證書上的持證人與現(xiàn)實的這個候選人一致,同時證書編號也能對應(yīng)上,那么就說明這個證書是真實的。

我們的客戶端能不能采用這個機(jī)制呢,像這樣:

可是,這個“第三方機(jī)構(gòu)”到底是在哪呢?是一個遠(yuǎn)程服務(wù)?不可能吧,如果是個遠(yuǎn)端服務(wù),整個交互都會變慢。所以,這個第三方機(jī)構(gòu)的驗收功能只能放在客戶端的本地了。

客戶端本地怎么驗證證書呢?

客戶端本地怎么驗證 證書呢?答案是證書本身就已經(jīng)告訴客戶端怎么驗證證書的真?zhèn)巍?/p>

也就是證書上寫著如何根據(jù)證書的內(nèi)容生成證書編號。客戶端拿到證書后根據(jù)證書上的方法自己生成一個證書編號,如果生成的證書編號與證書上的證書編號相同,那么說明這個證書是真實的。

同時,為避免證書編號本身又被掉包,所以使用第三方的私鑰進(jìn)行加密。

這個地方有些抽象,我們來個圖幫助理解:

證書的制作如圖所示。證書中的“編號生成方法MD5”就是告訴客戶端:你使用MD5對證書的內(nèi)容求值就可以得到一個證書編號。

當(dāng)客戶端拿到證書后,開始對證書中的內(nèi)容進(jìn)行驗證,如果客戶端計算出來的證書編號與證書編號相同,則驗證通過:

但是第三方機(jī)構(gòu)的公鑰怎么跑到了客戶端的機(jī)器中呢?世界上那么多機(jī)器。

其實呢,現(xiàn)實中,瀏覽器和操作系統(tǒng)都會維護(hù)一個權(quán)威的的第三方機(jī)構(gòu)列表(包括它們的公鑰)。因為客戶端接收的證書中會寫有頒發(fā)機(jī)構(gòu),客戶端就根據(jù)這個辦法機(jī)構(gòu)的值在本地找相應(yīng)的公鑰。

題外話:如果瀏覽器和操作系統(tǒng)這道防線被破了,忽悠沒辦法了。

說道這里,想必大家已經(jīng)知道上文所說的,證書就是HTTPS中數(shù)字證書,證書簽名就是數(shù)字簽名,而第三方機(jī)構(gòu)就是指數(shù)字證書簽發(fā)機(jī)構(gòu)(CA)。

CA是如何辦法數(shù)字證書給服務(wù)端的?

當(dāng)我聽到這個問題時,我誤以為,我們的SERVER需要發(fā)網(wǎng)絡(luò)請求到CA部門的服務(wù)器來拿這個證書。。。

其實,問題應(yīng)該是CA如何辦法給我們的網(wǎng)站管理員,而我們的管理員又如何將這個數(shù)字證書放到我們的服務(wù)器上。

我們?nèi)绾蜗駽A申請呢?每個CA機(jī)構(gòu)都大同小異,我在網(wǎng)上找了一個:

拿到證書后,我們就可以將證書配置到自己的服務(wù)器上了。那么如何配置?這是具體細(xì)節(jié)了,留給大家google了。

也許我們需要整理一下思路

我們通過推算的方式嘗試還遠(yuǎn)HTTPS的設(shè)計過程。這樣,我們也就明白了為什么HTTPS比HTTP多那么多次交互,為什么HTTPS的性能會差,以及找到HTTPS的性能優(yōu)化點(diǎn)。

而上面一大堆工作都是為了讓客戶端與服務(wù)端安全地協(xié)商出一個對稱加密算法。這就是HTTPS中的SSL/TLS協(xié)議主要干的活。剩下的就是通信時雙方使用這個對稱加密算法進(jìn)行加密解密。

以下是一張HTTPS協(xié)議的真實交互圖(從網(wǎng)上copy的,忘了從哪了,如果侵權(quán)麻煩告知):

能不能用一句話總結(jié)HTTPS?

答案是不能,因為HTTPS本身實在太復(fù)雜。但是我還是嘗試使用一段話來總結(jié)HTTPS:

HTTPS要使用客戶端與服務(wù)端的通信過程得到安全保證,必須使用對稱加密算法,但是協(xié)商對稱加密算法的過程,需要使用非對稱加密算法來保證安全,然而直接使用非對稱加密的過程本身也不安全,會有中間人篡改公鑰的可能性,所以客戶端與服務(wù)端不直接使用公鑰,而是使用數(shù)字證書簽發(fā)機(jī)構(gòu)頒發(fā)的證書來保證非對稱加密過程本身的安全。這樣通過這些機(jī)制協(xié)商出一個對稱加密算法,就此雙方使用該算法進(jìn)行加密解密。從而解決了客戶端與服務(wù)端之間的通信安全問題。

好長的一段話。

以上文字,純手打,也加深了自己對于HTTPS的理解。

文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址:http://specialneedsforspecialkids.com/yun/28713.html

相關(guān)文章

  • 一個 16年畢業(yè)生所經(jīng)歷 PHP 面試

    摘要:正確做法是給加索引,還有聯(lián)合索引,并不能避免全表掃描。 前言:有收獲的話請加顆小星星,沒有收獲的話可以 反對 沒有幫助 舉報三連 有心的同學(xué)應(yīng)該會看到我這個noteBook下面的其它知識,希望對你們有些許幫助。 本文地址 時間點(diǎn):2017-11 一個16年畢業(yè)生所經(jīng)歷的php面試 一、什么是面試 二、面試準(zhǔn)備 1. 問:什么時候開始準(zhǔn)備? 2. 問:怎么準(zhǔn)備? 三、面試...

    dabai 評論0 收藏0
  • 資源集 - 收藏集 - 掘金

    摘要:行爬取頂點(diǎn)全網(wǎng)任意小說掘金之前連續(xù)多篇文章介紹客戶端爬取平臺,今天我們從零開始,實現(xiàn)爬取頂點(diǎn)小說網(wǎng)任意一本小說的功能。文件標(biāo)記所有文件我的后端書架后端掘金我的后端書架月前本書架主要針對后端開發(fā)與架構(gòu)。 30行js爬取頂點(diǎn)全網(wǎng)任意小說 - 掘金之前連續(xù)多篇文章介紹客戶端爬取平臺(dspider),今天我們從零開始,實現(xiàn)爬取頂點(diǎn)小說網(wǎng)任意一本小說的功能。 如果你還不知道客戶端爬取,可以先看...

    stdying 評論0 收藏0

發(fā)表評論

0條評論

WelliJhon

|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<