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

之前每次看到類似“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。

HTTPS解決的問題：

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

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

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

HTTPS 的通信步驟

• 步驟 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 通信的整個過程。

HTTPS的加密技術

• 共享密鑰加密的困境

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

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

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

• HTTPS 採用混合加密機制

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

HTTPS的問題

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

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權威指南》