【讀書筆記】圖解 HTTP Chapter 07 確保 Web 安全的 HTTPS

缺點

  • 通訊使用不加密明文,內容可能會被竊聽
  • 不驗證通訊方身放,可能遭到偽裝
  • 無法證明訊息的完整性,可能會遭到竄改

以上缺點在其他未加密協定也會存在。

缺點

  • 通訊使用不加密明文,內容可能會被竊聽
  • 不驗證通訊方身放,可能遭到偽裝
  • 無法證明訊息的完整性,可能會遭到竄改

以上缺點在其他未加密協定也會存在。

通訊使用不加密明文,內容可能會被竊聽

  • TCP / IP 是可能被竊聽

根據 TCP / IP 的工作機制,通訊不加密表示所有通訊線路上的資料都有可能被窺視。

網路是連接到全世界的網路組成,因此通訊線路上的電腦、光纖及其他網路上都不可能是個人所有,所以可能在某個環節上被遭到窺視。

即使經過加密處理,也會被窺視到通訊內容,跟未加密的訊息差別在於,加密的訊息有可能讓人無法理解 HTTP 訊息含義,但加密過後的訊息還是有可能被看到。

  • 加密處理防止被竊聽
    在目前大家研究如何防止竊聽的對策,最普及的就是加密技術: - 通訊的加密:將通訊加密,HTTP 協議中沒有加密機制,但可以通過 SSL 或 TLS 的組合使用,加密 HTTP 通訊內容。用 SSL 建立安全通訊後,就可以在這條線路上進行 HTTP 通訊,稱之 HTTPS。 - 內容的加密:將 HTTP 訊息內容作加密,而客戶端和伺服端都要同時具備加密及解密機制。不同於 SSL 或 TLS ,內容仍然有被竄改的風險。

不驗證通訊方的身份就會遭到偽裝

HTTP 協議中的請求與回應不會對通訊方進行確認,也就是可能會發生伺服端或客戶端的其中一方是偽造的狀況。

  • 任何人都可發送請求
    在 HTTP 通訊中,由於不存在確認通訊方的處理步驟,在 IP 位置和埠號沒限制的狀況下,無論是誰發送請求,伺服端都會接收請求,所以可能有以下的隱患:

    - 無法確認發送請求的對象是否為目標伺服端。
    - 無法確認接收請求的對象是否為目標客戶端。
    - 無法確認正在進行通訊的那方是否有具備訪問權限。
  • 查明對方的憑證
    雖然 HTTP 無法確認對方身份,可是 SSL 可以,而且使用了憑證的方法來確認。憑證由第三方機構頒發,來證明客戶端和伺服端是真實存在。因為偽造憑證很困難,所以確認對方的憑證就可以判斷,而且對使用者來說可以減少訊息洩漏的危險。

無法證明訊息完整性,可能已遭竄改

這邊的完整性講的是訊息的準確度。

  • 接收到的內容可能有誤
    由於無法證明 HTTP 訊息的完整性,因此在請求(或回應)後到對方接收的這段時間,如果內容被竄改也沒辦法知道。意思就是你送出的請求(回應)和另一端接收到的請求(回應),在傳輸過程中可能會遭人篡改,像這樣的模式叫做 MITM(Man-in-the-Middle attack)。
  • 如何防止竄改
    雖然有使用 HTTP 協議確認 HTTP 訊息的完整性,但事實上並不可靠,比較常用的是 MD5 和 SHA-1 等散列值檢驗來確認文件的數位簽名。

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

HTTP 加上加密處理與認證等完整保護就是 HTTPS

如果在傳輸過程中使用未加密明文,那麼在頁面上串金流就也可能會被竊聽,那一些金融資料就可能會被曝露,另外沒辦法確認對方身份也很麻煩,所以為了統一解決上述問題,就需要在 HTTP 上做加密處理,因此把加密及認證機制稱作 HTTPS。

https://...

HTTPS 是身披 SSL 外殼的 HTTP

HTTPS 不算是在應用層的新協議,只是通訊端用 SSL 和 TLS 協議替代,通常使用 HTTP 是直接和 TCP 層通訊,但 HTTPS 使用 SSL ,就變成 SSL 在跟 TCP 通訊,這樣的感覺就像在 TCP 和 HTTP 中間多了一層 SSL。

SSL 是獨立於 HTTP 協議,所以應用層的 SMTP 和 Telent 等等協議都可以配合。

相互交換密鑰的公開密鑰加密技術

SSL 採用公開密鑰加密的加密處理方式,現在的加密方法是公開的,但是密鑰是保密的,加密和解密都會用到密鑰,換句話說有密鑰就可以解密。

  • 共享密鑰加密的困境

加密和解密共用同個密鑰叫做共享密鑰加密,又稱為密鑰加密。

以共享密鑰加密的方式把密鑰傳送給對方,但在傳送的過程也可能會被遭到攻擊,如果密鑰被攻擊者知道就失去意義,那我們該如何安全傳輸密鑰呢?

  • 使用兩把密鑰的公開密鑰加密
    公開密鑰加密的方式解決了共享密鑰加密的困難。

    公開密鑰加密:有一把非對稱的密鑰,一把叫做私有密鑰(私鑰),一把叫做公開密鑰(公鑰),意思就是私有密鑰不能給別人知道,公開密鑰可以讓任何人知道。

    過程:發送密文的那方使用接收方的密鑰進行加密處理,對方收到加密的訊息再用自己的私鑰進行解密。

    這樣的方式就不用擔心訊息被竊盜,另外如果想根據密文和公鑰來解密是非常困難的,因為解密的過程就是對離散數學求值,密碼還是有機會遭到破解,但就現在的技術而言是不太可能的。

  • HTTPS 採用混合加密機制
    HTTPS 採用共享密鑰加密和公開密鑰加密兩者並用的混合加密機制,如果密鑰能夠安全交換,那麼就有可能會用公開密鑰的方式來進行通訊,但公開密鑰比共享密鑰加密的方式還慢。

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

公開密鑰還是有問題,就是無法證明公開密鑰本身的真實性,舉例來說:

準備和某台主機建立公開密鑰加密的方式,來進行通訊傳輸,如何確認公開密鑰就是原本那台伺服器發送的公開密鑰,因為有可能在公開密鑰傳輸的過程中被攻擊者替換。

為了解決上述問題,可以使用數位憑證認證機構,與相關機關頒發的公開密鑰證書。

  • 數位憑證認證機構:客戶端與伺服端雙方都可信任的第三方機構。
  • 流程:伺服器的營運人員先向第三方申請公開密鑰的申請,數位憑證機構判明提出申請者的身份,在對已申請的公開密鑰做數字簽名,然後再分配這個已簽名的公開密鑰,並將公開密鑰放入公鑰證書後並綁定。
  • 伺服端:伺服端會把這份數位憑證機構頒發的公鑰發送給客戶端,以做公鑰密鑰加密的方式通訊,公鑰憑證也可以叫做數位憑證。
  • 客戶端:接收到數位憑證的客戶端,可以使用公鑰對數位憑證進行驗證,驗證通過即可證明認證伺服器的身份以及其公鑰是可以信賴。

數位憑證的公鑰要安全地交給客戶端是困難的事,因此瀏覽器商在發布版本的時候,會事先在內部植入常用的數位憑證機構的公鑰。

客戶端作業順序:

  1. 使用瀏覽器植入的公開密鑰
  2. 拿到伺服器的數位憑證後,用瀏覽器的公開密鑰做驗證
  3. 驗證過後使用公開密鑰對 HTTP 訊息做加密後傳輸

伺服端作業流程:

  1. 伺服器把自己的公開密鑰登錄到數位憑證機構
  2. 接收到請求方的請求後,伺服端用私鑰對加密的請求進行解密
  • 可證明組織真實性的 EV SSL 證書

憑證是來證明其中一方的身份,再來就是確認伺服器規模。擁有該特性的憑證就是 EV SSL 憑證。

EV SSL 數位憑證基於國際標準,嚴格規定了對營運組織的確認方針,因此通過的網站可以獲得比較高的認可度。擁有 EV SSL 數位憑證的瀏覽器,在瀏覽器 URL 欄位的背景色是綠色,為的是防止釣魚攻擊。

  • 用以確認客戶端的客戶端證書

    HTTPS 中還可以使用客戶端憑證,證實伺服器正在通訊的那方是預期的客戶端,作用和伺服端憑證相同,但仍然有幾個問題點:

    • 憑證的頒發與獲得:要拿到證書意味要付費購買,讓不同用戶自行安裝憑證這件事就具有很大的挑戰。現況是安全性比較高的憑證機構可以頒發客戶端憑證,但僅限於特殊用途,像是可以支付憑證的業務。像是網路銀行就常使用客戶端憑證。
    • 無法獲得用戶本人的真實性:就算確認了電腦,但不能代表使用電腦的人就是擁有憑證的本人。
  • 認證機構信譽第一
    SSL 機制之所以可行,是因為認證機構是可被信賴的,之前在荷蘭有被爆出憑證機構被駭客入侵。雖然現在有將憑證吊銷的機制,以及從客戶端刪除憑證發布機構的對策,但距離完全實現還需要一點時間。

  • 由自認證機構頒發的證書稱為自簽名證書
    使用 Open SSL 每個人可以建立自己的數位憑證,給自己的伺服器憑證,但在網路上是不可以使用,如果瀏覽器訪問該網站就會出現「無法確認連接安全」或「此網站憑證存在問題」等等,主要是因為無法消除偽裝可能性的關係。

HTTPS 的安全通信機制

  • SSL 和 TLS
    IETF 以 SSL 3.0 為基準,後來又制訂了 TLS 1.0 及 TLS 1.1 的版本,目前主流的是 SSL 3.0 和 TLS 1.0。
  • SSL 速度慢嗎
    • 通訊慢:和 HTTP 比,網路負載會慢 2-10 倍,TCP 連接、發送 HTTP 請求、回應也都要進行 SSL 通訊,所以通訊量也會增加。
    • 效能慢:因為需要進行加密處理,伺服端和客戶端都需要進行加密和解密的過程,就結果來說 SSL 會消耗更多伺服器和客戶端的硬體資源。

為什麼不一直用 HTTPS 就好?其實只要與個人資訊相關等敏感資料再做加密通訊就好,除了上述缺點外,節約開銷也是重點。
資料來源:《圖解 HTTP》 上野宣 人民郵電出版社
筆記純屬推廣及分享,如有侵權,請告知。
Please advise to remove immediately if any infringement caused.

【讀書筆記】圖解 HTTP Chapter 08 確認訪問用戶身份認證 【讀書筆記】圖解 HTTP Chapter 06 HTTP 首部(中)

評論

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×