|
Http存在的問(wèn)題 可能住你隔壁穿人字拖、說(shuō)話(huà)都略顯羞澀的小王,一到夜深人靜的時(shí)候就開(kāi)始偷窺你的一舉一動(dòng)!陪你一起看91某社區(qū)的電影還好,萬(wàn)一竊取了各購(gòu)物網(wǎng)站或其他站點(diǎn)的登錄信息就……是不是想想有些害怕呢! 為什么別人能獲取你上網(wǎng)的數(shù)據(jù)呢?有過(guò)一定網(wǎng)絡(luò)基礎(chǔ)的朋友多少都對(duì)TCP/IP有些了解,對(duì)各種握手揮手早已背得滾瓜爛俗,對(duì)http協(xié)議也早了然于心。http是應(yīng)用層的協(xié)議,位于TCP/IP參考模型的最上層。用戶(hù)數(shù)據(jù)經(jīng)過(guò)應(yīng)用層、傳輸層、網(wǎng)絡(luò)層、鏈路層的層層封裝后經(jīng)過(guò)物理層發(fā)送到目標(biāo)機(jī)器。在這幾層中,數(shù)據(jù)都沒(méi)有經(jīng)過(guò)加密處理,所以一旦別人獲取到你的數(shù)據(jù)包,就能輕易的獲取到數(shù)據(jù)的信息。 為了保護(hù)數(shù)據(jù)隱私,讓數(shù)據(jù)不再“裸奔”。對(duì)需要傳輸?shù)臄?shù)據(jù)進(jìn)行加密處理就很有必要了。目前而言,加密算法可以分兩大類(lèi),一類(lèi)是對(duì)稱(chēng)加密算法,還有一類(lèi)是非對(duì)稱(chēng)加密算法。 對(duì)稱(chēng)加密
非對(duì)稱(chēng)加密 對(duì)稱(chēng)加密和非對(duì)稱(chēng)加密都存在密鑰傳輸?shù)膯?wèn)題,但是至少非對(duì)稱(chēng)加密可以保證客戶(hù)端傳輸給服務(wù)端的內(nèi)容無(wú)法被“破解”,而對(duì)稱(chēng)加密算法性能又比較好,那我們是不是可以這樣子呢。第一次通信的時(shí)候服務(wù)端發(fā)送公鑰給客戶(hù)端,由客戶(hù)端產(chǎn)生一個(gè)對(duì)稱(chēng)密鑰,通過(guò)服務(wù)端的公鑰加密后發(fā)送給服務(wù)端,后續(xù)的交互中都通過(guò)對(duì)稱(chēng)密鑰進(jìn)行加密傳輸。也就是說(shuō)先通過(guò)非對(duì)稱(chēng)密鑰加密對(duì)稱(chēng)密鑰,通過(guò)對(duì)稱(chēng)密鑰加密實(shí)際請(qǐng)求的內(nèi)容。 上面的方案看起來(lái)天衣無(wú)縫,小王拿到數(shù)據(jù)后貌似就無(wú)償下手了,但是真的就天意無(wú)縫了嗎?我們看看下圖 也就是說(shuō)小王可以偽裝成服務(wù)器,與客戶(hù)端進(jìn)行通信。類(lèi)似于你與服務(wù)端之間多了一個(gè)中間商!也就是說(shuō)協(xié)商密鑰的過(guò)程依然存在漏洞! 有點(diǎn)腦闊疼!還能不能讓我安全的上網(wǎng)了!就沒(méi)有更安全的機(jī)制了么? 在協(xié)商密鑰的過(guò)程中,客戶(hù)端怎么能確定對(duì)方是真正的目標(biāo)服務(wù)器呢?怎么證明服務(wù)器的身份呢?我們先了解一下數(shù)字證書(shū)! 數(shù)字證書(shū) 客戶(hù)端第一次與服務(wù)器進(jìn)行通信的時(shí)候,服務(wù)器需要出示自己的數(shù)字證書(shū),證明自己的身份以及自己的公鑰,類(lèi)似如下(實(shí)際上就是一堆數(shù)據(jù),這里為了直觀) 那這個(gè)數(shù)字證書(shū)怎么產(chǎn)生的呢?總不能是服務(wù)器自己造一個(gè)吧?上面說(shuō)到了我們生活中的證書(shū)是由權(quán)威機(jī)構(gòu)頒發(fā)的、無(wú)法偽造的,比如身份證就是由派出所發(fā)證、畢業(yè)證由教育部發(fā)證,如果需要驗(yàn)證真假,只需要上相關(guān)的系統(tǒng)輸入編號(hào)查詢(xún)就能查到了!那我們數(shù)字證書(shū)也應(yīng)該有這兩個(gè)特性-權(quán)威機(jī)構(gòu)頒發(fā)、防偽! CA機(jī)構(gòu) 服務(wù)器向CA機(jī)構(gòu)提交申請(qǐng),需要提交站點(diǎn)的信息如域名、公司名稱(chēng)、公鑰等等,CA審批無(wú)誤之后就可以給服務(wù)器頒發(fā)證書(shū)了! 客戶(hù)端在拿到服務(wù)器的證書(shū)后,就需要驗(yàn)證證書(shū)編號(hào)是否能在對(duì)應(yīng)的CA機(jī)構(gòu)查到,并且核對(duì)證書(shū)的基本信息如證書(shū)上的域名是否與當(dāng)前訪(fǎng)問(wèn)的域名一致等等,還可以拿到證書(shū)中服務(wù)器的公鑰信息用于協(xié)商對(duì)稱(chēng)密鑰! 證書(shū)頒發(fā)了,可是又怎么防止偽造,怎么保證在傳輸過(guò)程中不被篡改呢?萬(wàn)一小王截獲到數(shù)字證書(shū),把公鑰改成自己的那不是依然無(wú)法保證安全了么?這就需要數(shù)字簽名了! 數(shù)字簽名 在實(shí)際生活中簽名、蓋章操作是實(shí)實(shí)在在的動(dòng)作,作用在具體某個(gè)物體上的!但是我們的數(shù)字證書(shū)本身就是虛擬的,怎么去給一個(gè)虛擬的證書(shū)簽名蓋章呢?數(shù)字簽名又是什么機(jī)制呢? 我們?cè)谧鰴?quán)限系統(tǒng)的時(shí)候,存儲(chǔ)用戶(hù)密碼的時(shí)候都會(huì)經(jīng)過(guò)MD5計(jì)算摘要后存儲(chǔ),在登錄的時(shí)候計(jì)算用戶(hù)填寫(xiě)的密碼的MD5摘要與數(shù)據(jù)庫(kù)存儲(chǔ)的摘要進(jìn)行對(duì)比,如果一致則密碼正確,否則登錄失敗!MD5是不可逆的,且不同的數(shù)據(jù)計(jì)算出來(lái)的摘要是不一樣的(當(dāng)然也有極小的概率會(huì)hash碰撞),基于這個(gè)特性,就有了數(shù)字簽名的思路。 服務(wù)器提交自己的基本信息想CA機(jī)構(gòu)提出申請(qǐng),CA機(jī)構(gòu)在給服務(wù)器頒發(fā)證書(shū)的時(shí)候,會(huì)連同數(shù)字證書(shū)以及根據(jù)證書(shū)計(jì)算的摘要一同發(fā)送給服務(wù)器,且這個(gè)摘要是需要經(jīng)過(guò)CA機(jī)構(gòu)自己的私鑰進(jìn)行加密的。申請(qǐng)流程如下: 啥?不夠直觀?那我們?cè)賮?lái)個(gè)直觀點(diǎn)的!通過(guò)下圖我們能看到,CA給服務(wù)器頒發(fā)的證書(shū)是有自己專(zhuān)屬的“公章”的。
哪些CA機(jī)構(gòu)對(duì)于客戶(hù)端來(lái)說(shuō)是權(quán)威或者說(shuō)是認(rèn)可的呢?我們打開(kāi)IE瀏覽器能看到客戶(hù)端內(nèi)置的CA機(jī)構(gòu)的信息,包含了CA的公鑰、簽名算法、有效期等等…
服務(wù)器在與客戶(hù)端通信的時(shí)候,就會(huì)將數(shù)字證書(shū)和數(shù)字簽名出示給客戶(hù)端了??蛻?hù)端拿到數(shù)字證書(shū)和數(shù)字簽名后,先通過(guò)操作系統(tǒng)或者瀏覽器內(nèi)置信任的CA機(jī)構(gòu)找到對(duì)應(yīng)CA機(jī)構(gòu)的公鑰對(duì)數(shù)字簽名進(jìn)行解密,然后采用同樣的摘要算法計(jì)算數(shù)字證書(shū)的摘要,如果自己計(jì)算的摘要與服務(wù)器發(fā)來(lái)的摘要一致,則證書(shū)是沒(méi)有被篡改過(guò)的!這樣就防止了篡改!第三方拿不到CA機(jī)構(gòu)的私鑰,也就無(wú)法對(duì)摘要進(jìn)行加密,如果是第三方偽造的簽名自然也在客戶(hù)端也就無(wú)法解密,這就防止了偽造!所以數(shù)字簽名就是通過(guò)這種機(jī)制來(lái)保證數(shù)字證書(shū)被篡改和被偽造。具體流程如下:
這里需要注意一點(diǎn),一個(gè)是CA機(jī)構(gòu)的公鑰,內(nèi)置在客戶(hù)端,用來(lái)解密數(shù)字簽名!另一個(gè)是目標(biāo)服務(wù)器的公鑰,在數(shù)字證書(shū)內(nèi)容里,用來(lái)協(xié)商對(duì)稱(chēng)密鑰! HTTPS
看到這里的你,對(duì)HTTPS的原理是否懂了呢,反正我奶奶看完已經(jīng)懂了!手動(dòng)狗頭(* ̄︶ ̄) |
|
|
來(lái)自: 印度阿三17 > 《開(kāi)發(fā)》