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