朋友們，我是fossi，今天開始進入新的篇章，也是本系列正序的最后一個篇章，我們來看看還有什么問題沒有得到解決。

一、一片烏云

縱觀TCP/IP四層模型，我們花了很多章節(jié)將核心的基礎部分全部叨叨完了，只要主機接入互聯(lián)網，主機上都安裝TCP/IP驅動程序，我們就可以順利將消息從一端的應用程序順利傳達到世界上任意另一端的應用程序上，并且還可以借助客戶端瀏覽器展示花花綠綠的美好世界。

我們仿佛置身于美麗而晴朗的天空下，愜意且得意，盡情地享受陽光的沐浴，可是，一片大大的烏云頃刻間來到了眼前：安全問題。

安全問題是一個領域很大的問題，本系列聚焦的是HTTP協(xié)議本身的安全問題。

二、HTTP的弱點

HTTP協(xié)議，在設計之初并未考慮安全問題，它的設計初衷是用來進行數據傳輸和共享。

隨著web應用的普及，有一小部分黑客借助HTTP的弱點進行攻擊，輕則獲取你的喜好或瀏覽記錄，重則盜取銀行賬號、販賣你的個人信息。

本系列主要關注中間人攻擊，所謂中間人就是在客戶端和服務器之間有一雙無形黑手，對于客戶端和服務器來說，根本不會意識到有中間人的存在，也沒有辦法進行防御。

那么HTTP到底有什么弱點呢？

（1）第一個弱點是：數據未進行加密，一切信息在互聯(lián)網上裸奔。

我們知道，從瀏覽器出發(fā)，到最終的服務器，會經過大量中間節(jié)點，若數據未加密，可輕松在某個節(jié)點上進行截獲并結合工具理解其含義。

有的讀者朋友可能會問：我是否可以在代碼層面使用各種加密算法對內容進行加密和解密呢？即在應用層上對傳輸的數據本身進行加密。

這個沒有從根本上解決此問題，因為即便你可以對傳輸的數據進行加密，但是不能對HTTP頭部進行加密，而HTTP頭部信息是否加密也是在安全考慮范圍內的。

同時此方案不具備通用性，比如服務器對HTML數據進行加密后發(fā)給瀏覽器，而瀏覽器本身卻不會單獨適配你的服務端進行解密后再進行頁面渲染。

（2）第二個弱點是：無法驗證身份，對端跟你聊天的可能是一只狗。

對于HTTP協(xié)議來說，只要傳輸的信息符合HTTP規(guī)范即可，而不會確認雙方的身份，也沒有確認雙方身份的標準。

基于這個一點，很有可能實際訪問到的網站并不是官方的真實網站，原因可能是在你的電腦或者中間DNS上被劫持到了騙子的網站上。

這一點相信讀者朋友們會感覺后背發(fā)涼，當你付款的時候，都無法確認對方是誰，你還敢支付嗎？甚至連密碼都不敢輸入了，因為很有可能你的密碼和個人信息也被竊取走。

真是可惡，防不勝防！

（3）第三個弱點是：數據被篡改，我愛你變成我恨你。

鑒于存在中間人攻擊，中間人在獲取到你的信息后，不僅可以隨心所欲看你的隱私，甚至還可以將你發(fā)送的信息進行篡改后再發(fā)送出去。

但是由于客戶端和服務端并沒有數據是否篡改的校驗機制，服務端無條件信任所有接收到的信息。

好啊，殺人還誅心，這個破網是不能再上了！

三、密碼學初探

我的意中人是個蓋世英雄，有一天他會踩著七色的云彩來娶我。

意中人的名字叫做HTTPS，理解HTTPS之前必須掌握基本的密碼學知識，HTTPS本質上就是對密碼學算法的組合。

之所以這片烏云這么大，罪魁禍首就是牽涉到密碼學，而密碼學關系到數學，這一點要想深入下去，則又是一門學科了；而烏云之所以這么黑，是因為安全無小事，一旦出事就是大問題，這也是密碼學這么深奧且重要的原因。

目前流行的密碼學算法實現是公開的，是經歷了長時間考驗的，是由佷多理具備深厚數學知識的數學家們所創(chuàng)造，對于開發(fā)者來說，即使不了解其背后原理，也可以容易地上手使用他們。

在使用他們的時候，我們必須持有這樣的態(tài)度：

• 世界上不存在一種密碼學算法，能解決所有的安全問題，需要具體問題具體分析。
• 世界上也沒有絕對安全的密碼學算法，對于算法應用者來說，確保目前使用的密碼學算法是安全的就可以了。

所以我們最重要的任務是了解特定的一些密碼學算法解決了何種問題、在正確的場景下能正確地使用他們。

四、密碼學目標

我們上面提三個HTTP的弱點，而引入密碼學就是為了解決問題，我們來看看密碼學的目標。

（1）機密性

解決信息裸奔問題，密碼學最最最核心的任務當然是負責數據加密，只要外人不知道密鑰，即使拿到密文信息也毫無意義。

（2）完整性

解決數據篡改問題，即使是加密數據，如果數據被中間人篡改，則應該可以通過某種策略知曉，保障收到的數據就是發(fā)送方發(fā)出來的原始數據。

在密碼學中，主要使用消息驗證碼（ MAC ）算法保證完整性 。

（3）身份驗證和不可抵賴性

通信雙方必須確保對端就是要通信的對象。在密碼學中，一般使用數字簽名技術確認身份。

此外，數字簽名技術還能避免抵賴，舉個例子，A向B借錢了，并寫了張借條，當B希望A還錢時，A抵賴說借條不是他寫的，理由就是有人冒充他寫了這張借條。

接下來我們再來抽絲剝繭，慢慢探索HTTPS是如何解決如上問題的。