Http存在的問題

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

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

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

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

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

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

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

對稱加密

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

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

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

非對稱加密

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

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

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

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

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

數(shù)字證書

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

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

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

CA機構

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

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

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

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

數(shù)字簽名

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

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

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

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

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

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

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

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

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

HTTPS

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

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

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

轉載自: 17coding技術博客
http://www.17coding.info/article/22?

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

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

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

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

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

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

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

單向認證

?

?

雙向認證

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

?

總結

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

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