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

以前每次看到相似「http與https的區別？」的問題時，都會本身思考一下答案，好像只是淺顯地知道https比http安全，但究竟爲何更安全，卻又彷佛說不出個因此然，或者說不少細節地方本身都是不清楚的。爲了搞清楚，也爲了系統地瞭解一下http相關的知識，前段時間閱讀了一波《圖解HTTP》，不得不說這本書真的算是通俗易懂，瞭解到了不少以前不清楚的知識點（協議、報文、狀態碼、首部字段、身份認證、資源緩存以及web攻擊等）。若是想了解更多http相關的知識的同窗固然也能夠選擇閱讀《HTTP權威指南》。

HTTP

HTTP，全稱超文本傳輸協議，是一種詳細規定客戶端與web服務器之間互相通訊的規則，經過因特網傳送萬維網文檔的數據傳送協議。它的特色是：

• 無狀態，每一個請求結束後都會被關閉，每次的請求都是獨立的，它的執行狀況和結果與前面的請求和以後的請求是無直接關係的，它不會受前面的請求應答狀況直接影響，也不會直接影響後面的請求應答狀況；服務器中沒有保存客戶端的狀態，客戶端必須每次帶上本身的狀態去請求服務器，就像是「人生只如初見」，好比說用戶須要請求某個數據，須要登陸權限，用戶登陸以後進行請求，結果由於http的無狀態，等用戶下一次還想請求一份數據，還須要再次登陸，這樣不就很煩了嗎，因此就須要session和cookie來進行狀態管理了。

• 明文傳輸（未通過加密的報文），爲何通訊時不加密是一個缺點，這是由於，按TCP/IP 協議族的工做機制，通訊內容在全部的通訊線路上都有可能遭到窺視。不管世界哪一個角落的服務器在和客戶端通訊時，在此通訊線路上的某些網絡設備、光纜、計算機等都不多是我的的私有物，因此不排除某個環節中會遭到惡意窺視行爲。即便已通過加密處理的通訊，也會被窺視到通訊內容，這點和未加密的通訊是相同的。只是說若是通訊通過加密，就有可能讓人沒法破解報文信息的含義，但加密處理後的報文信息自己仍是會 被看到的。

• 不驗證通訊方的身份，所以有可能遭遇假裝。HTTP 協議中的請求和響應不會對通訊方進行確認。也就是說存在「服務器是否就是發送請求中 URI 真正指定的主機，返回的響應是否真的返回到實際提出請求的客戶端」等相似問題。在 HTTP 協議通訊時，因爲不存在確認通訊方的處理步驟，任何人均可以發起請求。另外，服務器只要接收到請求，無論對方是誰都會返回一個響應（但也僅限於發送端的 IP 地址和端口號沒 有被 Web 服務器設定限制訪問的前提下；不管是誰發送過來的請求都會返回響應，所以不確認通訊方，會存在如下各類隱患：一、沒法肯定請求發送至目標的 Web 服務器是不是按真實意圖返回響應的那臺服務器。有多是已假裝的 Web 服務器；二、沒法肯定響應返回到的客戶端是不是按真實意圖接收響應的那個客戶端。有多是已假裝的客戶端；三、沒法肯定正在通訊的對方是否具有訪問權限。由於某些Web 服務器上保存着重要的信息，只想發給特定用戶通訊的權限；四、沒法斷定請求是來自何方、出自誰手；五、即便是無心義的請求也會照單全收。沒法阻止海量請求下的 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權威指南》