眾所周知，http協議是以明文進行傳輸的，http在明文的傳輸過程中很容易出現數據被攔截、篡改、監控的危險，這種情況無益于一人一絲不掛的在街上裸奔，如果被人想看你，你的任何細節都將一目了然。如果你是用的是長城寬帶、寬帶通、鐵通等這類小運營商的話，或許深有體會，就像下圖我家長城寬帶劫持百度首頁，攔截百度的http包然后添加一些html代碼在網頁底部彈出自家廣告，此種做法惡心至極。
使用HTTP協議的危害
- 篡改數據包，致使數據不完整，如上圖插入廣告
- 攔截數據包，對數據進行監控或獲取敏感數據，如用戶名密碼等
鑒于以上原因，HTTP協議現已越來越不被信任，為解決HTTP帶來的問題HTTPS協議應運而生。
什么是HTTPS
HTTPS協議 = HTTP協議 + SSL/TLS協議，也就是說HTTPS協議是在HTTP協議基礎上加了一層SSL/TLS協議進行數據加解密。也就是說使用HTTPS協議之后在網絡上傳輸的數據是加密的密文，即便進行攔截后沒有密鑰進行解密的話也就是一串亂碼。那HTTPS是如何進行加密的呢？這就涉及到一些簡單的密碼學基礎知識了，不過你只需要簡單了解一下秘鑰、密文、明文、加密、非對稱加密這幾個概念即可。
什么是明文、秘鑰、公鑰、私鑰、密文、對稱加密、非對稱加密、證書？
明文 - 是指原始干凈的數據，比如"I'm a boy."。
密鑰 - 指示用于加密的參數，密鑰又分為兩種對稱密鑰和非對稱密鑰。
1)對稱密鑰 - 既能用于加密數據也能用于解密數據，對稱的意思就是你這頭用什么加密，另外一頭只能用什么解密，比如你是用對稱秘鑰是"12345678"進行加密的數據，那么你要解密這些數據你只能用"12345678"進行解密，否則解密失敗，換句話說加解密的雙方都需要知道這個密鑰，雙方既能進行加密也能進行解密。
2)非對稱密鑰 - 非對稱秘鑰是一個秘鑰組合包含兩個密鑰，一個是公鑰一個是私鑰。其中公鑰只能用于加密，私鑰只能用于解密,因此加解密雙方不需要使用同一個密鑰，數據加密方只需要公鑰進行加密，數據解密方只需要私鑰進行解密。
密文 - 是指通過加密算法加密后的數據,比如明文"I'm a boy."使用對稱秘鑰"12345678"進行des算法加密后變成密文"cUHMRj7NhhNXIUSFKyWCCqgaX3SRnhJi"。
對稱加密 - 是指用對稱加密密鑰以及對應的算法進行加密的方法
非對稱加密 - 是指用非對稱加密密鑰以及對應的算法進行加密的方法，HTTPS在建立連接以及驗證的過程即使用的這種加密方法。
證書 - 是指數字證書，具有權威性，就像企業公司合同上的印章一樣，代表這個是企業授權的合同。
HTTPS通訊步驟
- 客戶端和服務端建立連接
- 服務端將自己的公鑰發送給客戶端
- 客戶端校驗服務單發過來的公鑰是否合法能夠信任，如果不信任則拋出異常或者彈出警告
- 客戶端驗證通過，隨機生成一個堆成密鑰
- 客戶端將隨機生成的堆成密鑰使用服務器發送過來的公鑰進行加密
- 客戶端將加密后的公鑰密文發送給服務端
- 服務端收到客戶端發過來的密文
- 服務端使用自己是私鑰將發過來的密文進行解密，獲得對稱密鑰
- 服務端使用對稱密鑰加密要發送的數據成密文并發送給客戶端
- 客戶端使用對稱密鑰解密服務端發送過來的密文獲得明文
- 客戶端使用對稱密鑰加密要發送的數據成密文并發送給服務端
- 服務端使用對稱密鑰解密客戶端發送過來的密文獲得明文
- 重復步驟9-12進行各種通訊
下圖為https通訊步驟(圖片來自于limboy的博客)
至此，你如果已經理解上述內容，表示你已經差不多掌握https的通訊流程以及為什么https比http安全的原因。但是你如果細心一點會發現上面介紹的概念里面還有一個 證書 沒有用到，那么證書到底有什么用呢？你如果仔細推敲上面的HTTPS通訊步驟，你會發現在第2步服務端將自己的公鑰發送給客戶端時候會產生問題，我們假設客戶端和服務器通訊的過程中出現以下場景：
- 客戶端和服務端建立連接，但是被一個黑客進行了攔截，黑客有自己的公鑰和私鑰
- 客戶端和黑客進行了連接并且交換了密鑰，黑客和服務端進行了連接并且交換了密鑰
- 客戶端向黑客發送了自己用戶名和密碼
- 黑客解密后獲得了用戶名密碼，然后再向服務端發送用戶密碼
- 服務端校驗了用戶密碼是對的，然后向黑客發送了客戶的所有敏感數據
- 黑客獲得了用戶的敏感數據，然后再向客戶端發送了所有數據
以上場景中，客戶端以為連接的是服務端，服務端以為連接的是客戶端，兩個人數據發來發去玩的的不亦樂乎，而黑客作為一個中間人已經獲得了所有的數據，這就是所謂的** 中間人攻擊 。那該怎么辦？怎么防止這種中間人攻擊呢？證書**就用來防止這種事情發生的。
我們在HTTPS通訊步驟的第3步中，對公鑰進行了校驗，這個校驗過程就用到了證書。如果校驗不通過則會出現異常或者彈出警告，我們著名的12306火車票網站就是因為公鑰不被信任導致瀏覽器彈出警告，如下圖：
剛剛上面說到，服務端需要有公鑰和私鑰來進行加解密，那么這個公鑰和私鑰是哪里來的呢？當然你可以創建自己的公鑰和私鑰，這樣一來就完了，大家都可以創建，那瀏覽器該信任誰的公鑰？這樣也不行。
這個時候我們需要共同推舉幾個大家都認可且相信的認證機構，這個機構叫證書認證中心，也叫CA（Certificate Authority）。
全球知名的CA也就100多個，這些CA都是全球都認可的，比如VeriSign、GlobalSign等，國內知名的CA有WoSign。
那么CA又是怎么對公鑰進行認證的呢？
CA自己也有一套公鑰和私鑰，CA會用自己的私鑰對你的公鑰進行非對稱加密，再加上證書的過期時間、頒發給、頒發者等信息，就組成了數字證書，然后將加密后的公鑰發給你，你配置到自己的服務器上。
不論什么平臺，設備的操作系統中都會內置100多個全球公認的這些CA的公鑰。所以HTTPS通訊步驟現在變成了如下：
HTTPS通訊步驟(重點)
- 客戶端和服務端建立連接
- 服務端將自己的公鑰發送給客戶端
- 客戶端嘗試用自己系統內置的所有CA的公鑰對服務端發過來的公鑰進行解密，如果所有CA的公鑰都無法解密的話，說明服務端發過來的證書是不被信任的，彈出警告
- 客戶端嘗如果用自己內置的某個CA公鑰對服務端發過來的公鑰進行解密成功，說明服務端發過來的證書是正常的，然后對服務端的證書進行有效期、機構信息等進行驗證，如果驗證不通過(如：過期)，則彈出警告
- 客戶端驗證通過，隨機生成一個堆成密鑰
- 客戶端將隨機生成的堆成密鑰使用服務器發送過來的公鑰進行加密
- 客戶端將加密后的公鑰密文發送給服務端
- 服務端收到客戶端發過來的密文
- 服務端使用自己是私鑰將發過來的密文進行解密，獲得對稱密鑰
- 服務端使用對稱密鑰加密要發送的數據成密文并發送給客戶端
- 客戶端使用對稱密鑰解密服務端發送過來的密文獲得明文
- 客戶端使用對稱密鑰加密要發送的數據成密文并發送給服務端
- 服務端使用對稱密鑰解密客戶端發送過來的密文獲得明文
- 重復步驟10-13進行各種通訊
經過上述證書驗證步驟，則能夠避免黑客進行中間人攻擊，所以你要做的就是向CA購買一個證書，然后根據自己所使用的技術類型在服務端進行配置好證書即可使用https進行訪問。
-----end-----
轉載請保留我博客地址 http://blog.itbiu.com/2017/03/09/201703091
