Http存在的問題
上過網的朋友都知道，網絡是非常不安全的。尤其是公共場所很多免費的wifi，或許只是攻擊者的一個誘餌。還有大家平時喜歡用的萬能鑰匙，等等。那我們平時上網可能會存在哪些風險呢？
- 泄密，個人隱私、賬戶密碼等信息可能會被盜取。
- 篡改，收到的數據可能被第三方修改過，或被植入廣告等。
- 假冒，訪問的站點非目標服務器站點。如域名欺騙、域名劫持、釣魚網站等。
可能住你隔壁穿人字拖、說話都略顯羞澀的小王，一到夜深人靜的時候就開始偷窺你的一舉一動！陪你一起看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的原理是否懂了呢，反正我奶奶看完已經懂了！手動狗頭(*￣︶￣)
（完）
