本文在個人技術部落格同步釋出，詳情可猛戳
Http存在的問題
上過網的朋友都知道，網路是非常不安全的。尤其是公共場所很多免費的wifi，或許只是攻擊者的一個誘餌。還有大家平時喜歡用的萬能鑰匙，等等。那我們平時上網可能會存在哪些風險呢？
1. 洩密，個人隱私、賬戶密碼等資訊可能會被盜取。
2. 篡改，收到的資料可能被第三方修改過，或被植入廣告等。
3. 假冒，訪問的站點非目標伺服器站點。如域名欺騙、域名劫持、釣魚網站等。
可能住你隔壁穿人字拖、說話都略顯羞澀的小王，一到夜深人靜的時候就開始偷窺你的一舉一動！陪你一起看91某社群的電影還好，萬一竊取了各購物網站或其他站點的登入資訊就……是不是想想有些害怕呢！
為什麼別人能獲取你上網的資料呢？有過一定網路基礎的朋友多少都對TCP/IP有些瞭解，對各種握手揮手早已背得滾瓜爛俗，對http協議也早了然於心。http是應用層的協議，位於TCP/IP參考模型的最上層。使用者資料經過應用層、傳輸層、網路層、鏈路層的層層封裝後經過物理層傳送到目標機器。在這幾層中，資料都沒有經過加密處理，所以一旦別人獲取到你的資料包，就能輕易的獲取到資料的資訊。
為了保護資料隱私，讓資料不再“裸奔”。對需要傳輸的資料進行加密處理就很有必要了。目前而言，加密演算法可以分兩大類，一類是對稱加密演算法，還有一類是非對稱加密演算法。
對稱加密
對稱加密演算法的加密和解密都是用同一個金鑰。在一定條件下，對稱加密可以解決資料傳輸安全性的問題。比如我在登入某個網站的時候，需要填寫賬戶名和密碼進行登入，客戶端把登入的表單資訊進行對稱加密後再傳輸，這時候就算小王截獲資料包，他也無法獲取資料的內容，因為資料已經被加密了。但是伺服器收到資料後也是一臉懵逼，你發來的加密的資料包伺服器也不知道解密的金鑰！
那是不是客戶端與服務端在通訊之前應該先協商金鑰呢？客戶端可以通知伺服器需要開啟資料傳輸了，然後伺服器告訴客戶端，我們們以後用xxxx這個金鑰進行加密解密吧！
這樣內容是可以加密傳輸了，但是上圖中第一步協商金鑰的過程又同樣存在安全的問題！萬一小王截獲了協商金鑰的資料，那後續加密傳輸的資料對小王來說無異於未加密！所以，對稱加密存在金鑰協商的問題！
非對稱加密
基於對稱加密存在的問題，又有了非對稱加密。非對稱加密演算法需要一組金鑰對，分別是公鑰和私鑰，這兩個金鑰是成對出現的。公鑰加密的內容需要用私鑰解密，私鑰加密的內容需要用公鑰解密！私鑰由伺服器自己儲存，公鑰傳送給客戶端。客戶端拿到公鑰後就可以對請求進行加密後傳送給服務端了，這時候就算被小王截獲，小王沒有私鑰也無法解密傳送的內容，這樣確保了客戶端傳送到服務端資料的“安全”！但是由於公鑰也需要通過網路傳送給客戶端，同樣能被小王截獲，這樣伺服器私鑰加密後的內容依然可以被小王截獲並解密，並且非對稱加密的效率很低。
對稱加密和非對稱加密都存在金鑰傳輸的問題，但是至少非對稱加密可以保證客戶端傳輸給服務端的內容無法被“破解”，而對稱加密演算法效能又比較好，那我們是不是可以這樣子呢。第一次通訊的時候服務端傳送公鑰給客戶端，由客戶端產生一個對稱金鑰，通過服務端的公鑰加密後傳送給服務端，後續的互動中都通過對稱金鑰進行加密傳輸。也就是說先通過非對稱金鑰加密對稱金鑰，通過對稱金鑰加密實際請求的內容。
上面的方案看起來天衣無縫，小王拿到資料後貌似就無償下手了，但是真的就天意無縫了嗎？我們看看下圖
也就是說小王可以偽裝成伺服器，與客戶端進行通訊。類似於你與服務端之間多了一箇中間商！也就是說協商金鑰的過程依然存在漏洞！
有點腦闊疼！還能不能讓我安全的上網了！就沒有更安全的機制了麼？ 在協商金鑰的過程中，客戶端怎麼能確定對方是真正的目標伺服器呢？怎麼證明伺服器的身份呢？我們先了解一下數字證書！
數字證書
我們生活中有各種證，有能證明自己是個有身份的人的身份證，有能證明自己讀了幾年書的畢業證。這些證都是由某些權威機關認證、無法偽造的，能證明自己身份的憑據。那伺服器是不是也能有個類似身份證的東西，在與伺服器進行通訊的時候證明自己確實是目標伺服器而不是小王偽造的呢？在生活中這些證件都是事實在在能看得見摸得著的，而計算機中的證書是虛擬的，看得見但是摸不著，是資料形式記錄的，所以叫數字證書！
客戶端第一次與伺服器進行通訊的時候，伺服器需要出示自己的數字證書，證明自己的身份以及自己的公鑰，類似如下（實際上就是一堆資料，這裡為了直觀）
那這個數字證書怎麼產生的呢？總不能是伺服器自己造一個吧？上面說到了我們生活中的證書是由權威機構頒發的、無法偽造的，比如身份證就是由派出所發證、畢業證由教育部發證，如果需要驗證真假，只需要上相關的系統輸入編號查詢就能查到了！那我們數字證書也應該有這兩個特性-權威機構頒發、防偽！
CA機構
CA機構就是數字證書頒發的權威機構，負責頒發證書以及驗證證書的合法性。如果伺服器需要做個有身份的伺服器，就需要向CA機構提交申請，當然有錢才好辦事，交錢才能給你辦證……
伺服器向CA機構提交申請，需要提交站點的資訊如域名、公司名稱、公鑰等等，CA審批無誤之後就可以給伺服器頒發證書了！
客戶端在拿到伺服器的證書後，就需要驗證證書編號是否能在對應的CA機構查到，並且核對證書的基本資訊如證書上的域名是否與當前訪問的域名一致等等，還可以拿到證書中伺服器的公鑰資訊用於協商對稱金鑰！
證書頒發了，可是又怎麼防止偽造，怎麼保證在傳輸過程中不被篡改呢？萬一小王截獲到數字證書，把公鑰改成自己的那不是依然無法保證安全了麼？這就需要數字簽名了！
數字簽名
與公司簽過勞動合同的朋友應該都知道，在合同資訊的填寫中，是不能有塗改的，否則需要重新填寫！並且在最後需要甲方和乙方簽名並且蓋章。一旦簽名蓋章後的合同就具有了法律的效力，合同就不能再修改。簽名和蓋章操作就是防止合同偽造，規定不能修改就防止了合同被篡改！
在實際生活中籤名、蓋章操作是實實在在的動作，作用在具體某個物體上的！但是我們的數字證書本身就是虛擬的，怎麼去給一個虛擬的證書籤名蓋章呢？數字簽名又是什麼機制呢？
我們在做許可權系統的時候，儲存使用者密碼的時候都會經過MD5計算摘要後儲存，在登入的時候計算使用者填寫的密碼的MD5摘要與資料庫儲存的摘要進行對比，如果一致則密碼正確，否則登入失敗！MD5是不可逆的，且不同的資料計算出來的摘要是不一樣的（當然也有極小的概率會hash碰撞），基於這個特性，就有了數字簽名的思路。
伺服器提交自己的基本資訊想CA機構提出申請，CA機構在給伺服器頒發證書的時候，會連同數字證書以及根據證書計算的摘要一同傳送給伺服器，且這個摘要是需要經過CA機構自己的私鑰進行加密的。申請流程如下：
啥？不夠直觀？那我們再來個直觀點的！通過下圖我們能看到，CA給伺服器頒發的證書是有自己專屬的“公章”的。
哪些CA機構對於客戶端來說是權威或者說是認可的呢？我們開啟IE瀏覽器能看到客戶端內建的CA機構的資訊，包含了CA的公鑰、簽名演算法、有效期等等...
伺服器在與客戶端通訊的時候，就會將數字證書和數字簽名出示給客戶端了。客戶端拿到數字證書和數字簽名後，先通過作業系統或者瀏覽器內建信任的CA機構找到對應CA機構的公鑰對數字簽名進行解密，然後採用同樣的摘要演算法計算數字證書的摘要，如果自己計算的摘要與伺服器發來的摘要一致，則證書是沒有被篡改過的！這樣就防止了篡改！第三方拿不到CA機構的私鑰，也就無法對摘要進行加密，如果是第三方偽造的簽名自然也在客戶端也就無法解密，這就防止了偽造！所以數字簽名就是通過這種機制來保證數字證書被篡改和被偽造。具體流程如下：
啥？又不夠直觀？那我們繼續...
這裡需要注意一點，一個是CA機構的公鑰，內建在客戶端，用來解密數字簽名！另一個是目標伺服器的公鑰，在數字證書內容裡，用來協商對稱金鑰！
HTTPS
本文的標題是HTTPS，但是到目前為止HTTPS隻字未提！其實HTTPS=HTTP+SSL，在HTTP層和TCP之間加了一個SSL/TLS層，如下圖：
SSL（Secure Sockets Layer）中文叫“安全套接層”，後來由於廣泛應用，SSL標準化之後就改名為TLS（Transport Layer Security）了,其實HTTPS就是通過上面說到的那些手段來解決網路上可能存在的資料洩密、篡改、假冒的這些問題，保證網路傳輸的安全的啦！
看到這裡的你，對HTTPS的原理是否懂了呢，反正我奶奶看完已經懂了！手動狗頭(*￣︶￣)