網絡安全協議（完善篇）

在上一期文章當中，提及到了網絡安全協議的誕生和發展方向，上期留下了一個問題，在不斷進化的安全方案中，依然存有小許缺陷。接下來我們會了解到，小缺陷是如何解決的。

從上期提到的方案4中，客戶端獲取到公鑰S之後，對客戶端形成的對稱密鑰X用服務端給客戶端的公鑰S進行加密，中間人即使竊取到了數據，確實是無法接觸客戶端形成的密鑰X，因爲只有服務器有私鑰S’。但是，如果中間人的攻擊在最開始握手協商的時候就開始進行劫持，那麼方案4就不一定安全了。

那麼，我們可以通過模擬場景更具象化地看一下這種方案被劫持信息的可能：

但是這一切都在中間人的掌握中，劫持數據，進行竊聽甚至修改都是可以的。因爲 客戶端無法確定收到含有公鑰的數據就是目標服務器發送過來的。被攻擊的核心原因是客戶端無法驗證公鑰的合法性，在這種情況下就需要一個公平公正的第三方機構來進行認證，確保客戶端連接的服務器是合法的。

爲實現這個概念，從而出現了各種網站都需要“引入CA數字證書”，一個可以確保自己的網站、服務器是合法合規並且安全的手段。我們都知道，互聯網是虛擬的，通過互聯網我們無法正確獲取對方真實身份，數字證書提供了一種在互聯網上驗證實體身份的方式。

CA是證書的簽發機構，是公鑰基礎設施（Public Key Infrastructure,PKI)的核心，用於證明自身身份，比較像身份證和駕駛證。擁有強大的“摘要算法”（也就是常說的散列函數、哈希函數），可以理解爲一種特殊的壓縮算法，能夠把任意長度的數據“壓縮”成固定長度、且獨一無二的“摘要”字符串，就好像給這段數據生成了一個數字“指紋”。

在我國實名制政策下，應用CA證書的申請者主要圍繞電子政務、商務、金融、企業內網和軟件分發這些領域，爲更好地保護機密數據和用戶資料。CA在申請者提交完整身份資料後，會爲申請者分配一個公鑰，並且CA將該公鑰與申請者的身份信息綁在一起形成證書發給申請者。但這不是掛起來的證書，而是安裝在服務器的證書。

大多數瀏覽器開發商在發佈瀏覽器版本時，會預先在瀏覽器內部植入常用認證機關的CA證書，客戶端（比如瀏覽器）內置了很多收信人的CA證書，這些CA證書中的公鑰是用來驗證服務器證書籤名的。而這種內置的CA證書是瀏覽器廠商和操作系統開發商管理和更新的，他們確保客戶端可以信任這些CA證書，在我們使用HTTPS的網站時，瀏覽器可以自動驗證證書的有效性，確保用戶安全。

那麼還有一個問題，如果“中間人攻擊”對數字證書進行了篡改，我們又要怎樣辨別確認所收到的數字簽名的真實性？

這種證書正正是爲了杜絕這種情況的發生。首先第一：中間人無法僞造簽名，即使中間人截獲了服務器發送的證書，並試圖篡改證書內容或替換服務器公鑰，他也無法生成一個有效的數字簽名，因爲他並沒有CA的私鑰。只有擁有CA私鑰的機構（真正的CA機構）才能生成匹配的簽名。中間人即使知道生成簽名的算法，也無法在沒有CA私鑰的情況下生成合法簽名。

其二：如果中間人篡改證書內容（比如替換公鑰），客戶端在解密數字簽名後會發現，解密得到的哈希值與客戶端計算出的哈希值不匹配。這意味着證書已經被篡改，客戶端會拒絕信任這個證書，並會終止與服務器的連接。防止信息泄露給攻擊者。

經過這一系列的迭代，我們得到的最優解決方案，非對稱式加密+對稱式解密+CA證書，是HTTPS鎖採取的方案。在建立連接時，HTTPS比HTTP多了TLS的握手過程。這個過程包括客戶端向服務器索要並驗證服務器的公鑰，確保是服務器形成的，然後雙方會產生一個密鑰，用來加密雙方之間的內容。

由此我們可以瞭解到HTTPS通過SSL/TLS協議提供了一種加密的通信方式，可以防止數據在傳輸過程中被截獲和竊取，而HTTP只是明文傳輸，沒有加密手段。所以，HTTPS比HTTP更加安全。

這下總會明白爲什麼不建議下載一些渠道外的軟件了吧？一些沒有正規機構出具證書的網站或軟件都能以之前說的“中間人攻擊”方式劫持用戶的數據併發送他們想讓用戶看到的信息。一步一步讓用戶掉入陷阱之中。