Http存在的問題

上過網(wǎng)的朋友都知道，網(wǎng)絡(luò)是非常不安全的。尤其是公共場所很多免費(fèi)的wifi，或許只是攻擊者的一個誘餌。還有大家平時喜歡用的萬能鑰匙，等等。那我們平時上網(wǎng)可能會存在哪些風(fēng)險呢？

1、泄密，個人隱私、賬戶密碼等信息可能會被盜取。

2、篡改，收到的數(shù)據(jù)可能被第三方修改過，或被植入廣告等。

3、假冒，訪問的站點(diǎn)非目標(biāo)服務(wù)器站點(diǎn)。如域名欺騙、域名劫持、釣魚網(wǎng)站等。

可能住你隔壁穿人字拖、說話都略顯羞澀的小王，一到夜深人靜的時候就開始偷窺你的一舉一動！陪你一起看91某社區(qū)的電影還好，萬一竊取了各購物網(wǎng)站或其他站點(diǎn)的登錄信息就……是不是想想有些害怕呢！

為什么別人能獲取你上網(wǎng)的數(shù)據(jù)呢？有過一定網(wǎng)絡(luò)基礎(chǔ)的朋友多少都對TCP/IP有些了解，對各種握手揮手早已背得滾瓜爛俗，對http協(xié)議也早了然于心。http是應(yīng)用層的協(xié)議，位于TCP/IP參考模型的最上層。用戶數(shù)據(jù)經(jīng)過應(yīng)用層、傳輸層、網(wǎng)絡(luò)層、鏈路層的層層封裝后經(jīng)過物理層發(fā)送到目標(biāo)機(jī)器。在這幾層中，數(shù)據(jù)都沒有經(jīng)過加密處理，所以一旦別人獲取到你的數(shù)據(jù)包，就能輕易的獲取到數(shù)據(jù)的信息。

為了保護(hù)數(shù)據(jù)隱私，讓數(shù)據(jù)不再“裸奔”。對需要傳輸?shù)臄?shù)據(jù)進(jìn)行加密處理就很有必要了。目前而言，加密算法可以分兩大類，一類是對稱加密算法，還有一類是非對稱加密算法。

對稱加密

對稱加密算法的加密和解密都是用同一個密鑰。在一定條件下，對稱加密可以解決數(shù)據(jù)傳輸安全性的問題。比如我在登錄某個網(wǎng)站的時候，需要填寫賬戶名和密碼進(jìn)行登錄，客戶端把登錄的表單信息進(jìn)行對稱加密后再傳輸，這時候就算小王截獲數(shù)據(jù)包，他也無法獲取數(shù)據(jù)的內(nèi)容，因為數(shù)據(jù)已經(jīng)被加密了。但是服務(wù)器收到數(shù)據(jù)后也是一臉懵逼，你發(fā)來的加密的數(shù)據(jù)包服務(wù)器也不知道解密的密鑰！

那是不是客戶端與服務(wù)端在通信之前應(yīng)該先協(xié)商密鑰呢？客戶端可以通知服務(wù)器需要開啟數(shù)據(jù)傳輸了，然后服務(wù)器告訴客戶端，咱們以后用xxxx這個密鑰進(jìn)行加密解密吧！

這樣內(nèi)容是可以加密傳輸了，但是上圖中第一步協(xié)商密鑰的過程又同樣存在安全的問題！萬一小王截獲了協(xié)商密鑰的數(shù)據(jù)，那后續(xù)加密傳輸?shù)臄?shù)據(jù)對小王來說無異于未加密！所以，對稱加密存在密鑰協(xié)商的問題！

非對稱加密

基于對稱加密存在的問題，又有了非對稱加密。非對稱加密算法需要一組密鑰對，分別是公鑰和私鑰，這兩個密鑰是成對出現(xiàn)的。公鑰加密的內(nèi)容需要用私鑰解密，私鑰加密的內(nèi)容需要用公鑰解密！私鑰由服務(wù)器自己保存，公鑰發(fā)送給客戶端。客戶端拿到公鑰后就可以對請求進(jìn)行加密后發(fā)送給服務(wù)端了，這時候就算被小王截獲，小王沒有私鑰也無法解密發(fā)送的內(nèi)容，這樣確保了客戶端發(fā)送到服務(wù)端數(shù)據(jù)的“安全”！但是由于公鑰也需要通過網(wǎng)絡(luò)發(fā)送給客戶端，同樣能被小王截獲，這樣服務(wù)器私鑰加密后的內(nèi)容依然可以被小王截獲并解密，并且非對稱加密的效率很低。

對稱加密和非對稱加密都存在密鑰傳輸?shù)膯栴}，但是至少非對稱加密可以保證客戶端傳輸給服務(wù)端的內(nèi)容無法被“破解”，而對稱加密算法性能又比較好，那我們是不是可以這樣子呢。第一次通信的時候服務(wù)端發(fā)送公鑰給客戶端，由客戶端產(chǎn)生一個對稱密鑰，通過服務(wù)端的公鑰加密后發(fā)送給服務(wù)端，后續(xù)的交互中都通過對稱密鑰進(jìn)行加密傳輸。也就是說先通過非對稱密鑰加密對稱密鑰，通過對稱密鑰加密實際請求的內(nèi)容。

上面的方案看起來天衣無縫，小王拿到數(shù)據(jù)后貌似就無償下手了，但是真的就天意無縫了嗎？我們看看下圖

也就是說小王可以偽裝成服務(wù)器，與客戶端進(jìn)行通信。類似于你與服務(wù)端之間多了一個中間商！也就是說協(xié)商密鑰的過程依然存在漏洞！

有點(diǎn)腦闊疼！還能不能讓我安全的上網(wǎng)了！就沒有更安全的機(jī)制了么？在協(xié)商密鑰的過程中，客戶端怎么能確定對方是真正的目標(biāo)服務(wù)器呢？怎么證明服務(wù)器的身份呢？我們先了解一下數(shù)字證書！

數(shù)字證書

我們生活中有各種證，有能證明自己是個有身份的人的身份證，有能證明自己讀了幾年書的畢業(yè)證。這些證都是由某些權(quán)威機(jī)關(guān)認(rèn)證、無法偽造的，能證明自己身份的憑據(jù)。那服務(wù)器是不是也能有個類似身份證的東西，在與服務(wù)器進(jìn)行通信的時候證明自己確實是目標(biāo)服務(wù)器而不是小王偽造的呢？在生活中這些證件都是事實在在能看得見摸得著的，而計算機(jī)中的證書是虛擬的，看得見但是摸不著，是數(shù)據(jù)形式記錄的，所以叫數(shù)字證書！

客戶端第一次與服務(wù)器進(jìn)行通信的時候，服務(wù)器需要出示自己的數(shù)字證書，證明自己的身份以及自己的公鑰，類似如下（實際上就是一堆數(shù)據(jù)，這里為了直觀）

那這個數(shù)字證書怎么產(chǎn)生的呢？總不能是服務(wù)器自己造一個吧？上面說到了我們生活中的證書是由權(quán)威機(jī)構(gòu)頒發(fā)的、無法偽造的，比如身份證就是由派出所發(fā)證、畢業(yè)證由教育部發(fā)證，如果需要驗證真假，只需要上相關(guān)的系統(tǒng)輸入編號查詢就能查到了！那我們數(shù)字證書也應(yīng)該有這兩個特性-權(quán)威機(jī)構(gòu)頒發(fā)、防偽！

CA機(jī)構(gòu)

CA機(jī)構(gòu)就是數(shù)字證書頒發(fā)的權(quán)威機(jī)構(gòu)，負(fù)責(zé)頒發(fā)證書以及驗證證書的合法性。如果服務(wù)器需要做個有身份的服務(wù)器，就需要向CA機(jī)構(gòu)提交申請，當(dāng)然有錢才好辦事，交錢才能給你辦證……

服務(wù)器向CA機(jī)構(gòu)提交申請，需要提交站點(diǎn)的信息如域名、公司名稱、公鑰等等，CA審批無誤之后就可以給服務(wù)器頒發(fā)證書了！

客戶端在拿到服務(wù)器的證書后，就需要驗證證書編號是否能在對應(yīng)的CA機(jī)構(gòu)查到，并且核對證書的基本信息如證書上的域名是否與當(dāng)前訪問的域名一致等等，還可以拿到證書中服務(wù)器的公鑰信息用于協(xié)商對稱密鑰！

證書頒發(fā)了，可是又怎么防止偽造，怎么保證在傳輸過程中不被篡改呢？萬一小王截獲到數(shù)字證書，把公鑰改成自己的那不是依然無法保證安全了么？這就需要數(shù)字簽名了！

數(shù)字簽名

與公司簽過勞動合同的朋友應(yīng)該都知道，在合同信息的填寫中，是不能有涂改的，否則需要重新填寫！并且在最后需要甲方和乙方簽名并且蓋章。一旦簽名蓋章后的合同就具有了法律的效力，合同就不能再修改。簽名和蓋章操作就是防止合同偽造，規(guī)定不能修改就防止了合同被篡改！

在實際生活中簽名、蓋章操作是實實在在的動作，作用在具體某個物體上的！但是我們的數(shù)字證書本身就是虛擬的，怎么去給一個虛擬的證書簽名蓋章呢？數(shù)字簽名又是什么機(jī)制呢？

我們在做權(quán)限系統(tǒng)的時候，存儲用戶密碼的時候都會經(jīng)過MD5計算摘要后存儲，在登錄的時候計算用戶填寫的密碼的MD5摘要與數(shù)據(jù)庫存儲的摘要進(jìn)行對比，如果一致則密碼正確，否則登錄失敗！MD5是不可逆的，且不同的數(shù)據(jù)計算出來的摘要是不一樣的（當(dāng)然也有極小的概率會hash碰撞），基于這個特性，就有了數(shù)字簽名的思路。

服務(wù)器提交自己的基本信息想CA機(jī)構(gòu)提出申請，CA機(jī)構(gòu)在給服務(wù)器頒發(fā)證書的時候，會連同數(shù)字證書以及根據(jù)證書計算的摘要一同發(fā)送給服務(wù)器，且這個摘要是需要經(jīng)過CA機(jī)構(gòu)自己的私鑰進(jìn)行加密的。申請流程如下：

啥？不夠直觀？那我們再來個直觀點(diǎn)的！通過下圖我們能看到，CA給服務(wù)器頒發(fā)的證書是有自己專屬的“公章”的。

哪些CA機(jī)構(gòu)對于客戶端來說是權(quán)威或者說是認(rèn)可的呢？我們打開IE瀏覽器能看到客戶端內(nèi)置的CA機(jī)構(gòu)的信息，包含了CA的公鑰、簽名算法、有效期等等...

服務(wù)器在與客戶端通信的時候，就會將數(shù)字證書和數(shù)字簽名出示給客戶端了。客戶端拿到數(shù)字證書和數(shù)字簽名后，先通過操作系統(tǒng)或者瀏覽器內(nèi)置信任的CA機(jī)構(gòu)找到對應(yīng)CA機(jī)構(gòu)的公鑰對數(shù)字簽名進(jìn)行解密，然后采用同樣的摘要算法計算數(shù)字證書的摘要，如果自己計算的摘要與服務(wù)器發(fā)來的摘要一致，則證書是沒有被篡改過的！這樣就防止了篡改！第三方拿不到CA機(jī)構(gòu)的私鑰，也就無法對摘要進(jìn)行加密，如果是第三方偽造的簽名自然也在客戶端也就無法解密，這就防止了偽造！所以數(shù)字簽名就是通過這種機(jī)制來保證數(shù)字證書被篡改和被偽造。具體流程如下：

啥？又不夠直觀？那我們繼續(xù)...

這里需要注意一點(diǎn)，一個是CA的公鑰，內(nèi)置在客戶端，用來解密數(shù)字簽名！另一個是目標(biāo)服務(wù)器的公鑰，在數(shù)字證書內(nèi)容里，用來協(xié)商對稱密鑰！

HTTPS

本文的標(biāo)題是HTTPS，但是到目前為止HTTPS只字未提！其實HTTPS=HTTP+SSL，在HTTP層和TCP之間加了一個SSL/TLS層，如下圖：

SSL（Secure Sockets Layer）中文叫“安全套接層”，后來由于廣泛應(yīng)用，SSL標(biāo)準(zhǔn)化之后就改名為TLS（Transport Layer Security）了,其實HTTPS就是通過上面說到的那些手段來解決網(wǎng)絡(luò)上可能存在的數(shù)據(jù)泄密、篡改、假冒的這些問題，保證網(wǎng)絡(luò)傳輸?shù)陌踩睦?#xff01;

看到這里的你，對HTTPS的原理是否懂了呢，反正我奶奶看完已經(jīng)懂了！手動狗頭(*￣︶￣)

轉(zhuǎn)載自: 17coding技術(shù)博客
http://www.17coding.info/article/22?

看完之后自己又用語言總結(jié)了下，記錄一下

1.對稱加密 加密和解密的密鑰相同 ?
? 非對稱加密 一對私鑰和公鑰?
? ? ? ? ? ? ?私鑰由生成方擁有，公鑰發(fā)布給其他客戶端或者服務(wù)器(公鑰加密需要使用私鑰解密，私鑰加密需要公鑰解密)
2.不使用對稱加密 因為直接傳輸密鑰不安全，一旦被攔截，通信內(nèi)容加密也就沒有意義了
3.非對稱加密? 服務(wù)端需要發(fā)送公鑰給客戶端，如果被攔截，那么服務(wù)端發(fā)送給客戶端的內(nèi)容都能被破解，
? 但是客戶端發(fā)送給服務(wù)端的內(nèi)容依舊可以保證安全(這是因為客戶端使用公鑰加密，解密需要私鑰--只有服務(wù)器持有)

https要保證傳輸信息的安全，最關(guān)鍵的是保證加密密鑰的安全，既然有辦法保證客戶端發(fā)送給服務(wù)器的內(nèi)容的安全性，
那么就由客戶端來生成對稱密鑰用以加密傳輸內(nèi)容(對稱密鑰的加密效率更高)

總的來說就是服務(wù)端生成一對密鑰，把公鑰發(fā)送給客戶端，客戶端再生成對稱密鑰，使用公鑰加密對稱密鑰并發(fā)送給服務(wù)端 -- 完成密鑰的商定?

但是這樣會有新的問題:如果第三方偽裝成服務(wù)器攔截原服務(wù)器的請求，并把公鑰替換成自己的公鑰，那么就可以拿到客戶端發(fā)送的消息了，就需要想辦法向客戶端證明它接收到的公鑰確實是真正的服務(wù)器發(fā)送的。

那就需要有第三方安全機(jī)構(gòu)的權(quán)威認(rèn)證--CA機(jī)構(gòu)頒發(fā)的數(shù)字證書(用來證明服務(wù)器的身份，包含域名，公鑰，編號等信息) ，
為了防止證書被篡改主要是擔(dān)心證書中的公鑰被篡改，就需要使用數(shù)字簽名(根據(jù)證書內(nèi)容生成摘要，然后使用CA生成的私鑰加密)

總結(jié)下https請求的流程如下:
1.由客戶端發(fā)送請求給服務(wù)器端
2.服務(wù)器端返回數(shù)字證書和對應(yīng)的數(shù)字簽名給客戶端
3.客戶端拿到數(shù)字簽名之后使用對應(yīng)CA的公鑰進(jìn)行解密獲得對應(yīng)的摘要A，并對當(dāng)前證書的內(nèi)容進(jìn)行摘要算法計算出摘要B，
? ?如果兩次摘要相同則說明數(shù)字證書是可靠的，就取出數(shù)字證書中的公鑰
4.客戶端生成對稱密鑰，并使用公鑰加密后發(fā)送給服務(wù)端
5.服務(wù)端拿到密文后使用私鑰解密 然后就能使用安全的密鑰和客戶端進(jìn)行通信了

單向認(rèn)證

?

?

雙向認(rèn)證

? 圖片來自簡書上的文章:https://www.jianshu.com/p/29e0ba31fb8d

?

總結(jié)

以上是生活随笔為你收集整理的看完这篇文章，我奶奶都懂了https的原理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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