Https原理

 原文：http://www.javashuo.com/article/p-oagbweaw-bs.html

 

 

1、Http存在的問題

上過網的朋友都知道，網絡是很是不安全的。尤爲是公共場所不少免費的wifi，或許只是攻擊者的一個誘餌。還有你們平時喜歡用的萬能鑰匙，等等。那咱們平時上網可能會存在哪些風險呢？

1. 泄密，我的隱私、帳戶密碼等信息可能會被盜取。
2. 篡改，收到的數據可能被第三方修改過，或被植入廣告等。
3. 假冒，訪問的站點非目標服務器站點。如域名欺騙、域名劫持、釣魚網站等。

爲何別人能獲取你上網的數據呢？有過必定網絡基礎的朋友多少都對TCP/IP有些瞭解，對各類握手揮手早已背得滾瓜爛俗，對http協議也早了然於心。http是應用層的協議，位於TCP/IP參考模型的最上層。用戶數據通過應用層、傳輸層、網絡層、鏈路層的層層封裝後通過物理層發送到目標機器。在這幾層中，數據都沒有通過加密處理，因此一旦別人獲取到你的數據包，就能輕易的獲取到數據的信息。

  爲了保護數據隱私，讓數據再也不「裸奔」。對須要傳輸的數據進行加密處理就頗有必要了。目前而言，加密算法能夠分兩大類，一類是對稱加密算法，還有一類是非對稱加密算法。

 

2、對稱加密

　　對稱加密算法的加密和解密都是用同一個密鑰。在必定條件下，對稱加密能夠解決數據傳輸安全性的問題。好比我在登陸某個網站的時候，須要填寫帳戶名和密碼進行登陸，客戶端把登陸的表單信息進行對稱加密後再傳輸，這時候就算小王截獲數據包，他也沒法獲取數據的內容，由於數據已經被加密了。可是服務器收到數據後也是一臉懵逼，你發來的加密的數據包服務器也不知道解密的密鑰！

那是否是客戶端與服務端在通訊以前應該先協商密鑰呢？客戶端能夠通知服務器須要開啓數據傳輸了，而後服務器告訴客戶端，我們之後用xxxx這個密鑰進行加密解密吧！

這樣內容是能夠加密傳輸了，可是上圖中第一步協商密鑰的過程又一樣存在安全的問題！萬一小王截獲了協商密鑰的數據，那後續加密傳輸的數據對小王來講無異於未加密！因此，對稱加密存在密鑰協商的問題！

 

3、非對稱加密

　　基於對稱加密存在的問題，又有了非對稱加密。非對稱加密算法須要一組密鑰對，分別是公鑰和私鑰，這兩個密鑰是成對出現的。公鑰加密的內容須要用私鑰解密，私鑰加密的內容須要用公鑰解密！私鑰由服務器本身保存，公鑰發送給客戶端。客戶端拿到公鑰後就能夠對請求進行加密後發送給服務端了，這時候就算被小王截獲，小王沒有私鑰也沒法解密發送的內容，這樣確保了客戶端發送到服務端數據的「安全」！可是因爲公鑰也須要經過網絡發送給客戶端，一樣能被小王截獲，這樣服務器私鑰加密後的內容依然能夠被小王截獲並解密，而且非對稱加密的效率很低。

  對稱加密和非對稱加密都存在密鑰傳輸的問題，可是至少非對稱加密能夠保證客戶端傳輸給服務端的內容沒法被「破解」，而對稱加密算法性能又比較好，那咱們是否是能夠這樣子呢。第一次通訊的時候服務端發送公鑰給客戶端，由客戶端產生一個對稱密鑰，經過服務端的公鑰加密後發送給服務端，後續的交互中都經過對稱密鑰進行加密傳輸。也就是說先經過非對稱密鑰加密對稱密鑰，經過對稱密鑰加密實際請求的內容。

上面的方案看起來完美無缺，小王拿到數據後貌似就無償下手了，可是真的就完美無缺了嗎？咱們看看下圖

也就是說小王能夠假裝成服務器，與客戶端進行通訊。相似於你與服務端之間多了一箇中間商！也就是說協商密鑰的過程依然存在漏洞！

  有點腦闊疼！還能不能讓我安全的上網了！就沒有更安全的機制了麼？ 在協商密鑰的過程當中，客戶端怎麼能肯定對方是真正的目標服務器呢？怎麼證實服務器的身份呢？咱們先了解一下數字證書！

 

4、數字證書

　　咱們生活中有各類證，有能證實本身是個有身份的人的身份證，有能證實本身讀了幾年書的畢業證。這些證都是由某些權威機關認證、沒法僞造的，能證實本身身份的憑據。那服務器是否是也能有個相似身份證的東西，在與服務器進行通訊的時候證實本身確實是目標服務器而不是小王僞造的呢？在生活中這些證件都是事實在在能看得見摸得着的，而計算機中的證書是虛擬的，看得見可是摸不着，是數據形式記錄的，因此叫數字證書！

  客戶端第一次與服務器進行通訊的時候，服務器須要出示本身的數字證書，證實本身的身份以及本身的公鑰，相似以下（實際上就是一堆數據，這裏爲了直觀）

　　那這個數字證書怎麼產生的呢？總不能是服務器本身造一個吧？上面說到了咱們生活中的證書是由權威機構頒發的、沒法僞造的，好比身份證就是由派出所發證、畢業證由教育部發證，若是須要驗證真假，只須要上相關的系統輸入編號查詢就能查到了！那咱們數字證書也應該有這兩個特性-權威機構頒發、防僞！

 

5、CA機構

　　CA機構就是數字證書頒發的權威機構，負責頒發證書以及驗證證書的合法性。若是服務器須要作個有身份的服務器，就須要向CA機構提交申請，固然有錢纔好辦事，交錢才能給你辦證……

  服務器向CA機構提交申請，須要提交站點的信息如域名、公司名稱、公鑰等等，CA審批無誤以後就能夠給服務器頒發證書了！

  客戶端在拿到服務器的證書後，就須要驗證證書編號是否能在對應的CA機構查到，而且覈對證書的基本信息如證書上的域名是否與當前訪問的域名一致等等，還能夠拿到證書中服務器的公鑰信息用於協商對稱密鑰！

  證書頒發了，但是又怎麼防止僞造，怎麼保證在傳輸過程當中不被篡改呢？萬一小王截獲到數字證書，把公鑰改爲本身的那不是依然沒法保證安全了麼？這就須要數字簽名了！

 

6、數字簽名

　　與公司簽過勞動合同的朋友應該都知道，在合同信息的填寫中，是不能有塗改的，不然須要從新填寫！而且在最後須要甲方和乙方簽名而且蓋章。一旦簽名蓋章後的合同就具備了法律的效力，合同就不能再修改。簽名和蓋章操做就是防止合同僞造，規定不能修改就防止了合同被篡改！

  在實際生活中籤名、蓋章操做是實實在在的動做，做用在具體某個物體上的！可是咱們的數字證書自己就是虛擬的，怎麼去給一個虛擬的證書籤名蓋章呢？數字簽名又是什麼機制呢？

  咱們在作權限系統的時候，存儲用戶密碼的時候都會通過MD5計算摘要後存儲，在登陸的時候計算用戶填寫的密碼的MD5摘要與數據庫存儲的摘要進行對比，若是一致則密碼正確，不然登陸失敗！MD5是不可逆的，且不一樣的數據計算出來的摘要是不同的（固然也有極小的機率會hash碰撞），基於這個特性，就有了數字簽名的思路。

  服務器提交本身的基本信息想CA機構提出申請，CA機構在給服務器頒發證書的時候，會連同數字證書以及根據證書計算的摘要一同發送給服務器，且這個摘要是須要通過CA機構本身的私鑰進行加密的。申請流程以下：

 

啥？不夠直觀？那咱們再來個直觀點的！經過下圖咱們能看到，CA給服務器頒發的證書是有本身專屬的「公章」的。

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

 

　　服務器在與客戶端通訊的時候，就會將數字證書和數字簽名出示給客戶端了。客戶端拿到數字證書和數字簽名後，先經過操做系統或者瀏覽器內置信任的CA機構找到對應CA機構的公鑰對數字簽名進行解密，而後採用一樣的摘要算法計算數字證書的摘要，若是本身計算的摘要與服務器發來的摘要一致，則證書是沒有被篡改過的！這樣就防止了篡改！第三方拿不到CA機構的私鑰，也就沒法對摘要進行加密，若是是第三方僞造的簽名天然也在客戶端也就沒法解密，這就防止了僞造！因此數字簽名就是經過這種機制來保證數字證書被篡改和被僞造。具體流程以下：

　　這裏須要注意一點，一個是CA機構的公鑰，內置在客戶端，用來解密數字簽名！另外一個是目標服務器的公鑰，在數字證書內容裏，用來協商對稱密鑰！

 

7、HTTPS

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

　　SSL（Secure Sockets Layer）中文叫「安全套接層」，後來因爲普遍應用，SSL標準化以後就更名爲TLS（Transport Layer Security）了,其實HTTPS就是經過上面說到的那些手段來解決網絡上可能存在的數據泄密、篡改、假冒的這些問題，保證網絡傳輸的安全的啦！