【計算機網絡】HTTPS——更安全的HTTP通信（個人筆記）

學習日期：2024.6.26

內容摘要：HTTPS存在的意義、特點和工作方式

HTTP的缺點——易竊聽、偽裝、篡改

在Web及網絡基礎中，我們已經知道了網頁是怎么打開的，HTTP確實是一個相當優秀和方便的協議，但HTTP也有很多不足，最嚴重的不足就是——不安全。

因為HTTP屬于TCP/IP協議族，其工作機制決定了在通信時，通信線路上的設備幾乎不可能全部是個人的私有物。因此，通信可能被竊聽、篡改或偽裝。

我們來舉個比較生動的例子，HTTP協議通信就是你坐在教室最左邊，想把紙條傳給你最右邊的好哥們，叫他放學超光速去操場搶個籃板，顯然你要通過一堆同學把你的紙條遞過去。

易竊聽

因為HTTP不具備加密功能，你傳出去的紙條是明文（就是直接寫的），傳輸路上的人可能打開來看你的紙條（雖然一般人不會），這就是傳輸被竊聽了。

當然，你可以通過其他協議或者接層加密你的信息。（用密碼來寫你的小紙條）即使如此，通信也會被窺視到加密的內容，加密只是讓人難以破解加密信息的含義，而不能阻止對方看到這次通信的報文信息本身。

易偽裝

HTTP協議中的請求和響應不會對通信方的身份進行確認，也就會存在“跟我通信的服務器是否就是我申請通信的服務器，返回的響應是否真的返回到實際提出申請的客戶端”這一問題。這就存在被偽裝的隱患。聽起來可能有點繞，還是拿傳紙條舉例子。

因為你們教室很大，你看不到你哥們，所以你也不知道你哥們到底有沒有收到信息。即使你收到了回復，建立了通信，你也不確定回復你的到底是你哥們還是你們女班長，還是隔壁班的那個一米九體育生。

這可能導致以下隱患：

①無法確定請求/響應發送至目標的Web服務器/客戶端是不是我期望的服務器/客戶端，可能是偽裝的服務器/客戶端。

②無法確認通信的對方是否具有訪問權限，因為某些服務器上保存的重要信息，只能開放給有特定權限的客戶端訪問。

③無法判斷請求來自何方，出自誰手。

④即使是無意義請求也會照單全收，海量無意義請求下的Dos攻擊（Denial of service，拒絕服務攻擊），會讓服務器癱瘓。

易篡改

HTTP協議無法證明通信的報文完整性，因此在請求和響應送出后，直到對方收到前這段時間，信息即使被篡改也無法知悉。假如有一個壞同學在你和你哥們通信的路上，他偷偷篡改你們倆的通信內容，你們也不會知道，這種攻擊叫做中間人攻擊。（Man in the middle attack,MITM）

HTTP+加密+認證+完整性保護=HTTPS

為了解決以上這些問題，需要在HTTP中加入加密處理和認證等機制，我們把加入這些之后的HTTP稱為HTTPS（HTTP Secure）。

HTTPS并非是應用層的一種新協議，而是HTTP的套殼，HTTP的通信接口部分由SSL（Secure Socket Layer，安全套接層）和TLS（Transport Layer Security，安全傳輸層協議）代替而已。

通常，HTTP直接和TCP通信，當使用SSL時，則是先和SSL通信，再由SSL和TCP通信。

SSL是獨立于HTTP的協議，應用層的其它協議如SMTP和Telnet等都可以配合使用。

HTTPS的加密

在傳輸如身份信息，銀行卡號等等私密內容時，我們顯然不希望它們泄露，而HTTPS就會對通信進行加密。SSL采取一種被叫做“公開密鑰加密”的加密方式。

加密技術基礎

現代加密技術的加密方法一般是公開的，而密鑰是保密的，通過這種方法來保證加密方法的安全性，加密和解密都會用到密鑰，一旦密鑰被攻擊者獲得，加密就失去了意義。

從共享密鑰加密到公開密鑰加密

加密和解密用同一個密鑰的加密方式稱為共享密鑰加密，也稱對稱密鑰加密，以共享密鑰方式加密時，必須將密鑰也發送給對方。但是這會帶來一個問題——如何保證密鑰能安全送達不被竊聽？再加密一層的話，那密鑰的密鑰被竊聽呢？

為了解決這一問題，我們引入了公開密鑰加密，公開密鑰加密使用一對非對稱的密鑰，即公開密鑰和私有密鑰，簡稱公鑰和私鑰。私鑰必須保密，而公鑰可以公開給任何人，隨意發布，不怕攻擊者竊聽。

公開密鑰于其說是“鑰匙”，不如說像“鎖”，在用公開密鑰加密方式進行加密通信時，發送者首先用對方的公開密鑰進行加密，受信方收到后，再使用自己的私鑰進行解密。

公鑰就是隨意分發出去的鎖，即使有人竊聽，把“鎖”偷去，也打不開包裹，而與你通信的人用你的鎖把信息加密好，你再用自己的私鑰打開，就完成了安全通信。

公開密鑰方式雖然好，但是與共享密鑰加密方式相比更加復雜，處理速度也更加的慢。因此，HTTPS一般是通過二者結合的方式，使用公開密鑰加密方式來交換共享密鑰，再通過共享密鑰來通信，這樣就能實現安全快速的通信。

證明公開密鑰正確性的證書

遺憾的是，公開密鑰加密方式也不是完美無缺的，因為其是公開傳輸的，我們也不知道公開密鑰是否遭到了篡改，無法證明收到的公開密鑰就是接收方的公開密鑰。如果這把“鎖”不是接收方的鎖，而是被攻擊者偷偷篡改成攻擊者的“鎖”了，那我們的加密就形同虛設了。

為了解決這一問題，可以使用CA（Certificate Authority，數字證書認證機構）和其相關機關頒發的公開密鑰證書。

數字證書認證機構是服務器端和客戶端都比較信賴的第三方機構。首先，服務器的運營人員會向數字認證機構提出公開密鑰的申請，數字認證機構在仔細判明申請者身份后，會對已申請的公開密鑰做數字簽名，并且將其放入公鑰證書后綁定在一起（公鑰和服務器對應綁定）。

在通信時，服務器端會將這份公鑰證書（又稱數字證書，或直接簡稱證書）發送給客戶端，以公開密鑰加密方式通信，而客戶端則會向CA機構核實，以CA機構的公開密鑰進行通信，確認服務器端發送的密鑰就是服務器之前登記的公開密鑰，一旦核實成功，客戶端就能確定：①認證服務器的CA機構是真實有效的機構 ②服務器的公開密鑰是值得信賴的。

確實有點繞。我還是用鎖舉例來幫助理解：我要確認這把鎖是不是被人替換了，就去找一個靠譜的公司，這個公司把所有靠譜服務器的鎖都在上面登記了。我每次通信的時候就先去公司查一查鎖的目錄，這把鎖是不是對方的那把，如果是就說明沒問題。

但是還有一個問題（真服了），在使用這個方式認證時，客戶端需要和CA機構通信，那么如何保證客戶端和CA機構之間的通信是安全的呢？如果CA機構的公鑰也被篡改了呢？為了解決這個問題，現代的瀏覽器一般會在內部直接植入常用認證機關的公開密鑰。（直接不用通信，一步到位最安全）