http與https的區別我真的知道嗎

ScoutYin發表於2018-05-10
HTTP

之前每次看到類似“http與https的區別？”的問題時，都會自己思考一下答案，好像只是淺顯地知道https比http安全，但究竟為什麼更安全，卻又似乎說不出個所以然，或者說很多細節地方自己都是不清楚的。為了搞清楚，也為了系統地瞭解一下http相關的知識，前段時間閱讀了一波《圖解HTTP》，不得不說這本書真的算是通俗易懂，瞭解到了很多之前不清楚的知識點（協議、報文、狀態碼、首部欄位、身份認證、資源快取以及web攻擊等）。如果想了解更多http相關的知識的同學當然也可以選擇閱讀《HTTP權威指南》。

HTTP

HTTP，全稱超文字傳輸協議，是一種詳細規定客戶端與web伺服器之間互相通訊的規則，通過因特網傳送全球資訊網文件的資料傳送協議。它的特點是：

  • 無狀態，每個請求結束後都會被關閉，每次的請求都是獨立的，它的執行情況和結果與前面的請求和之後的請求是無直接關係的，它不會受前面的請求應答情況直接影響，也不會直接影響後面的請求應答情況；伺服器中沒有儲存客戶端的狀態，客戶端必須每次帶上自己的狀態去請求伺服器，就像是“人生只如初見”，比如說使用者需要請求某個資料，需要登入許可權，使用者登入之後進行請求，結果因為http的無狀態，等使用者下一次還想請求一份資料，還需要再次登入，這樣不就很煩了嗎，所以就需要session和cookie來進行狀態管理了。

  • 明文傳輸（未經過加密的報文），為什麼通訊時不加密是一個缺點，這是因為，按TCP/IP 協議族的工作機制，通訊內容在所有的通訊線路上都有可能遭到窺視。無論世界哪個角落的伺服器在和客戶端通訊時，在此通訊線路上的某些網路裝置、光纜、計算機等都不可能是個人的私有物，所以不排除某個環節中會遭到惡意窺視行為。即使已經過加密處理的通訊，也會被窺視到通訊內容，這點和未加密的通訊是相同的。只是說如果通訊經過加密，就有可能讓人無法破解報文資訊的含義，但加密處理後的報文資訊本身還是會 被看到的。

  • 不驗證通訊方的身份，因此有可能遭遇偽裝。HTTP 協議中的請求和響應不會對通訊方進行確認。也就是說存在“伺服器是否就是傳送請求中 URI 真正指定的主機，返回的響應是否真的返回到實際提出請求的客戶端”等類似問題。在 HTTP 協議通訊時，由於不存在確認通訊方的處理步驟，任何人都可以發起請求。另外，伺服器只要接收到請求，不管對方是誰都會返回一個響應（但也僅限於傳送端的 IP 地址和埠號沒 有被 Web 伺服器設定限制訪問的前提下；不論是誰傳送過來的請求都會返回響應，因此不確認通訊方，會存在以下各種隱患：1、無法確定請求傳送至目標的 Web 伺服器是否是按真實意圖返回響應的那臺伺服器。有可能是已偽裝的 Web 伺服器；2、無法確定響應返回到的客戶端是否是按真實意圖接收響應的那個客戶端。有可能是已偽裝的客戶端；3、無法確定正在通訊的對方是否具備訪問許可權。因為某些Web 伺服器上儲存著重要的資訊，只想發給特定使用者通訊的許可權；4、無法判定請求是來自何方、出自誰手；5、即使是無意義的請求也會照單全收。無法阻止海量請求下的 DoS 攻擊（Denial of Service，拒絕服務攻擊）。

  • 無法證明報文的完整性。因此，在請求或響應送出之後直到對方接收之前的這段時間內，即使請求或響應的內容遭到篡改，也沒有辦法獲悉；換句話說，沒有任何辦法確認，發出的請求 / 響應和接收到的請 求 / 響應是前後相同的。

HTTPS

HTTPS，全稱Hyper Text Transfer Protocol Secure，相比http，多了一個secure，也就是TLS（SSL），一個安全套接層。https和http都屬於應用層（application layer），基於TCP（以及UDP）協議，但是又完全不一樣。TCP用的port是80， https用的是443。

HTTPS 並非是應用層的一種新協議。只是 HTTP 通訊介面部分用SSL（Secure Socket Layer）和 TLS（Transport Layer Security）協議代替而已。通常，HTTP 直接和 TCP 通訊。當使用 SSL時，則演變成先和 SSL通訊，再由 SSL和 TCP 通訊了。簡言之，所謂 HTTPS，其實就是身披SSL協議這層外殼的 HTTP。

image

HTTPS解決的問題：

  • 信任主機的問題.。 採用https 的server 必須從CA （數字證書認證機構處於客戶端與伺服器雙方都可信賴的第三方機構的 立場上）申請一個用於證明伺服器用途型別的證書，該證書有了CA的簽名，客戶端才能知道訪問的伺服器是安全的。 目前基本所有的線上購物和網銀等網站或系統,關鍵部分應用都是https 的，客戶通過信任該證書,從而信任了該主機，這樣才能保證安全。

  • 通訊過程中的資料的洩密和被竄改 使用https協議，服務端和客戶端之間的所有通訊都是加密的。客戶端和服務端各有自己的一對非對稱的金鑰,一把叫做私有金鑰（private key），另一把叫做公開金鑰（public key），顧名思義，私有金鑰不能讓其他任何人知道，而公開金鑰則可以隨意釋出，任何人都可以獲得。使用公開金鑰加密方式，傳送密文的一方使用對方的公開金鑰進行加密處理，對方收到被加密的資訊後，再使用自己的私有金鑰進行解密。利用這種方式，不需要傳送用來解密的私有金鑰，也不必擔心金鑰被攻擊者竊聽而盜走。要想根據密文和公開金鑰，恢復到資訊原文是異常困難的，因為解密過程就是在對離散對數進行求值，這並非輕而易舉就能辦到。退一步講，如果能對一個非常大的整數做到快速地因式分解，那麼密碼破解還是存在希望的。但就目前的技術來看是不太現實的。

    image

簡單點說就是：HTTP + 認證 + 加密 + 完整性保護 = HTTPS

HTTPS 的通訊步驟

image

  • 步驟 1： 客戶端通過傳送 Client Hello 報文開始 SSL通訊。報文中包含客戶端支援的 SSL的指定版本、加密元件（Cipher Suite）列表（所使用的加密演算法及金鑰長度等）。
  • 步驟 2： 伺服器可進行 SSL通訊時，會以 Server Hello 報文作為應答。和客戶端一樣，在報文中包含 SSL版本以及加密元件。伺服器的加密元件內容是從接收到的客戶端加密元件內篩選出來的。
  • 步驟 3： 之後伺服器傳送 Certificate 報文。報文中包含公開金鑰證書。
  • 步驟 4： 最後伺服器傳送 Server Hello Done 報文通知客戶端，最初階段的 SSL握手協商部分結束。
  • 步驟 5： SSL第一次握手結束之後，客戶端以 Client Key Exchange 報文作為迴應。報文中包含通訊加密中使用的一種被稱為 Pre-mastersecret 的隨機密碼串。該報文已用步驟 3 中的公開金鑰進行加密。
  • 步驟 6： 接著客戶端繼續傳送 Change Cipher Spec 報文。該報文會提示伺服器，在此報文之後的通訊會採用 Pre-master secret 金鑰加密。
  • 步驟 7： 客戶端傳送 Finished 報文。該報文包含連線至今全部報文的整體校驗值。這次握手協商是否能夠成功，要以伺服器是否能夠正確解密該報文作為判定標準。
  • 步驟 8： 伺服器同樣傳送 Change Cipher Spec 報文。
  • 步驟 9： 伺服器同樣傳送 Finished 報文。
  • 步驟 10： 伺服器和客戶端的 Finished 報文交換完畢之後，SSL連線就算建立完成。當然，通訊會受到 SSL的保護。從此處開始進行應用層協議的通訊，即傳送 HTTP 請求。
  • 步驟 11： 應用層協議通訊，即傳送 HTTP 響應。
  • 步驟 12： 最後由客戶端斷開連線。斷開連線時，傳送 close_notify 報文。上圖做了一些省略，這步之後再傳送 TCP FIN 報文來關閉與 TCP的通訊。

下面是對整個流程的圖解。圖中說明了從僅使用伺服器端的公開金鑰證書（伺服器證書）建立 HTTPS 通訊的整個過程。

image

HTTPS的加密技術

  • 共享金鑰加密的困境

    加密和解密同用一個金鑰的方式稱為共享金鑰加密（Common key crypto system），也被叫做對稱金鑰加密。以共享金鑰方式加密時必須將金鑰也發給對方。可究竟怎樣才能 安全地轉交？在網際網路上轉發金鑰時，如果通訊被監聽那麼金鑰 就可會落入攻擊者之手，同時也就失去了加密的意義。另外還得 設法安全地保管接收到的金鑰。也就是說，傳送金鑰就存在被竊聽的風險，不傳送，對方就不能解密。再說如果金鑰能夠安全送達，那麼資料也能夠安全送達，那加密也就失去其意義了。

  • 使用兩把金鑰的公開金鑰加密

    公開金鑰加密方式很好地解決了共享金鑰加密的困難。公開金鑰加密使用一對非對稱的金鑰。一把叫做私有金鑰（private key），另一把叫做公開金鑰（public key）。顧名思義，私有金鑰不能讓其他任何人知道，而公開金鑰則可以隨意釋出，任何人都可以獲得。 使用公開金鑰加密方式，傳送密文的一方使用對方的公開金鑰進 行加密處理，對方收到被加密的資訊後，再使用自己的私有金鑰 進行解密。利用這種方式，不需要傳送用來解密的私有金鑰，也不必擔心金鑰被攻擊者竊聽而盜走。 另外，要想根據密文和公開金鑰，恢復到資訊原文是異常困難的，因為解密過程就是在對離散對數進行求值，這並非輕而易舉 就能辦到。退一步講，如果能對一個非常大的整數做到快速地因式分解，那麼密碼破解還是存在希望的。但就目前的技術來看是不太現實的。

  • HTTPS 採用混合加密機制

    因此，HTTPS採用的是共享金鑰加密和公開金鑰加密兩者並用的混合加密機制。若金鑰能夠實現安全交換，那麼有可能會考慮僅使用公開金鑰加密來通訊。但是公開金鑰加密與共享金鑰加密相比，其處理速度要慢。所以應充分利用兩者各自的優勢，將多種方法組合起來用於通訊。在交換金鑰環節使用公開金鑰加密方式，之後的建立通訊交換報文階段則使用共享金鑰加密方式。上圖中生成的master secret即共享金鑰，之後的交換的報文資訊都將使用它來進行加密。

HTTPS加密

HTTPS的問題

  • HTTPS足夠安全嗎？世界上沒有絕對的安全。比如2014年的Heartbleed漏洞席捲全球，很多網站受到heartbleed威脅，其中就有雅虎，stackoverflow這樣的網站。但總的來說對於絕大部分人來說HTTPS還是相對安全的，至少比HTTP安全。
  • HTTPS 還有一個問題，那就是當使用 SSL時，它的處理速度會變慢

image

SSL的慢分兩種。一種是指通訊慢。另一種是指由於大量消耗CPU 及記憶體等資源，導致處理速度變慢。

  • 和使用 HTTP 相比，網路負載可能會變慢 2 到 100 倍。除去和TCP 連線、傳送 HTTP 請求 • 響應以外，還必須進行 SSL通訊，因此整體上處理通訊量不可避免會增加。
  • 另一點是 SSL必須進行加密處理。在伺服器和客戶端都需要進行加密和解密的運算處理。因此從結果上講，比起 HTTP 會更多地消耗伺服器和客戶端的硬體資源，導致負載增強。 -針對速度變慢這一問題，並沒有根本性的解決方案，我們會使用SSL加速器這種（專用伺服器）硬體來改善該問題。該硬體為SSL通訊專用硬體，相對軟體來講，能夠提高數倍 SSL的計算速度。僅在 SSL處理時發揮 SSL加速器的功效，以分擔負載。

為什麼不一直使用 HTTPS？

  • 因為與純文字通訊相比，加密通訊會消耗更多的CPU 及記憶體資源。如果每次通訊都加密，會消耗相當多的資源，平攤到一臺計算機上時，能夠處理的請求數量必定也會隨之減少。因此，如果是非敏感資訊則使用 HTTP 通訊，只有在包含個人資訊等敏感資料時，才利用 HTTPS 加密通訊。特別是每當那些訪問量較多的 Web 網站在進行加密處理時，它們所承擔著的負載不容小覷。在進行加密處理時，並非對所有內容都進行加密處理，而是僅在那些需要資訊隱藏時才會加密，以節約資源。

  • 想要節約購買證書的開銷也是原因之一。 要進行 HTTPS 通訊，證書是必不可少的。而使用的證書必須向認證機構（CA）購買。證書價格可能會根據不同的認證機構略有不同。那些購買證書並不合算的服務以及一些個人網站，可能只會選擇採用 HTTP 的通訊方式。

參考書籍

《圖解HTTP》

《HTTP權威指南》

相關文章