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