HTTP與HTTPS的區別，詳細介紹（轉）

目錄

HTTP與HTTPS介紹

HTTPS和HTTP的主要區別

客戶端在使用HTTPS方式與Web服務器通訊時的步驟

CA證書的申請及其使用過程

HTTPS的缺點

SSL與TLS的區別？

SSL/TLS歷史

SSL/TLS協議的基本過程

HTTPS涉及的計算環節

如何優化HTTPS的速度

 

HTTP與HTTPS介紹
        超文本傳輸協議HTTP協議被用於在Web瀏覽器和網站服務器之間傳遞信息，HTTP協議以明文方式發送內容，不提供任何方式的數據加密，若是攻擊者截取了Web瀏覽器和網站服務器之間的傳輸報文，就能夠直接讀懂其中的信息，所以，HTTP協議不適合傳輸一些敏感信息，好比：信用卡號、密碼等支付信息。

        爲了解決HTTP協議的這一缺陷，須要使用另外一種協議：安全套接字層超文本傳輸協議HTTPS，爲了數據傳輸的安全，HTTPS在HTTP的基礎上加入了SSL/TLS協議，SSL/TLS依靠證書來驗證服務器的身份，併爲瀏覽器和服務器之間的通訊加密。

        HTTPS協議是由SSL/TLS+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，要比http協議安全

        HTTPS協議的主要做用能夠分爲兩種：一種是創建一個信息安全通道，來保證數據傳輸的安全；另外一種就是確認網站的真實性。

 

HTTPS和HTTP的主要區別
        一、https協議須要到CA申請證書，通常免費證書較少，於是須要必定費用。

        二、http是超文本傳輸協議，信息是明文傳輸，https則是具備安全性的ssl/tls加密傳輸協議。

        三、http和https使用的是徹底不一樣的鏈接方式，用的端口也不同，前者是80，後者是443。

        四、http的鏈接很簡單，是無狀態的；HTTPS協議是由SSL/TLS+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。

 

 

客戶端在使用HTTPS方式與Web服務器通訊時的步驟
　（1）客戶使用https的URL訪問Web服務器，要求與Web服務器創建SSL鏈接。

　（2）Web服務器收到客戶端請求後，會將網站的證書信息（證書中包含公鑰）傳送一份給客戶端。

　（3）客戶端的瀏覽器與Web服務器開始協商SSL/TLS鏈接的安全等級，也就是信息加密的等級。

　（4）客戶端的瀏覽器根據雙方贊成的安全等級，創建會話密鑰，而後利用網站的公鑰將會話密鑰加密，並傳送給網站。

　（5）Web服務器利用本身的私鑰解密出會話密鑰。

　（6）Web服務器利用會話密鑰加密與客戶端之間的通訊。

 

   

        儘管HTTPS並不是絕對安全，掌握根證書的機構、掌握加密算法的組織一樣能夠進行中間人形式的攻擊，但HTTPS還是現行架構下最安全的解決方案，但他大幅增長了中間人攻擊的成本

 

 

CA證書的申請及其使用過程
上面客戶端使用HTTPS與服務器通訊中使用到了CA認證，這裏可能你們會問爲何不直接使用非對稱加密的形式直接進行，首先這裏先介紹下非對稱加密。

非對稱加密：客戶端和服務端均擁有一個公有密匙和一個私有密匙。公有密匙能夠對外暴露，而私有密匙只有本身可見。

使用公有密匙加密的消息，只有對應的私有密匙才能解開。反過來，使用私有密匙加密的消息，只有公有密匙才能解開。這樣客戶端在發送消息前，先用服務器的公匙對消息進行加密，服務器收到後再用本身的私匙進行解密。

 

 

非對稱加密的優勢：

非對稱加密採用公有密匙和私有密匙的方式，解決了http中消息保密性問題，並且使得私有密匙泄露的風險下降。

由於公匙加密的消息只有對應的私匙才能解開，因此較大程度上保證了消息的來源性以及消息的準確性和完整性。

非對稱加密的缺點：

非對稱加密時須要使用到接收方的公匙對消息進行加密，可是公匙不是保密的，任何人均可以拿到，中間人也能夠。那麼中間人能夠作兩件事，第一件是中間人能夠在客戶端與服務器交換公匙的時候，將客戶端的公匙替換成本身的。這樣服務器拿到的公匙將不是客戶端的，而是中間人的。服務器也沒法判斷公匙來源的正確性。第二件是中間人能夠不替換公匙，可是他能夠截獲客戶端發來的消息，而後篡改，而後用服務器的公匙加密再發往服務器，服務器將收到錯誤的消息。

非對稱加密的性能相對對稱加密來講會慢上幾倍甚至幾百倍，比較消耗系統資源。正是由於如此，https將兩種加密結合了起來。

 

爲了應對上面非對稱加密帶來的問題，咱們就引入了數字證書與數字簽名

故CA認證介入咱們的HTTPS鏈接的過程以下：

一、服務器擁有本身的私鑰與公鑰

二、服務器將公鑰交給CA認證機構，請求給予一份數字證書

三、CA認證機構生成數字證書，並頒發給服務器

四、服務器將帶有公鑰信息的數字證書發給客戶端

五、進入客戶端生成對稱密鑰再進行對接的過程......

 

 

HTTPS的缺點
　　雖說HTTPS有很大的優點，但其相對來講，仍是存在不足之處的：

　　（1）HTTPS協議握手階段比較費時，會使頁面的加載時間延長近50%，增長10%到20%的耗電；

　　（2）HTTPS鏈接緩存不如HTTP高效，會增長數據開銷和功耗，甚至已有的安全措施也會所以而受到影響；

　　（3）SSL證書須要錢，功能越強大的證書費用越高，我的網站、小網站沒有必要通常不會用。

　    （4）SSL證書一般須要綁定IP，不能在同一IP上綁定多個域名，IPv4資源不可能支撐這個消耗。

　　（5）HTTPS協議的加密範圍也比較有限，在黑客攻擊、拒絕服務攻擊、服務器劫持等方面幾乎起不到什麼做用。最關鍵的，SSL證書的信用鏈體系並不安全，特別是在某些國家能夠控制CA根證書的狀況下，中間人攻擊同樣可行。

 

        實踐中建議保留http。因此咱們在切換的時候能夠作http和https的兼容，具體實現方式是，去掉頁面連接中的http頭部，這樣能夠自動匹配http頭和https頭。例如：將http://www.baidu.com改成//www.baidu.com。而後當用戶從http的入口進入訪問頁面時，頁面就是http，若是用戶是從https的入口進入訪問頁面，頁面即便https的

 

SSL與TLS的區別？
SSL：（Secure Socket Layer，安全套接字層），位於可靠的面向鏈接的網絡層協議和應用層協議之間的一種協議層。SSL經過互相認證、使用數字簽名確保完整性、使用加密確保私密性，以實現客戶端和服務器之間的安全通信。該協議由兩層組成：SSL記錄協議和SSL握手協議。

TLS：(Transport Layer Security，傳輸層安全協議)，用於兩個應用程序之間提供保密性和數據完整性。該協議由兩層組成：TLS記錄協議和TLS握手協議。

 

SSL/TLS歷史
1994年，NetScape公司設計了SSL協議（Secure Sockets Layer）的1.0版，可是未發佈。
1995年，NetScape公司發佈SSL 2.0版，很快發現有嚴重漏洞。
1996年，SSL 3.0版問世，獲得大規模應用。
1999年，互聯網標準化組織ISOC接替NetScape公司，發佈了SSL的升級版TLS 1.0版。
2006年和2008年，TLS進行了兩次升級，分別爲TLS 1.1版和TLS 1.2版。最新的變更是2011年TLS 1.2的修訂版。
目前，應用最普遍的是TLS 1.0，接下來是SSL 3.0。可是，主流瀏覽器都已經實現了TLS 1.2的支持。
TLS 1.0一般被標示爲SSL 3.1，TLS 1.1爲SSL 3.2，TLS 1.2爲SSL 3.3。

 

 

SSL/TLS協議的基本過程

（1） 客戶端向服務器端索要並驗證公鑰。
（2） 雙方協商生成"對話密鑰"。
（3） 雙方採用"對話密鑰"進行加密通訊。
上面過程的前兩步，又稱爲"握手階段"（handshake）

 

1 客戶端發出請求（ClientHello）

（1） 支持的協議版本，好比TLS 1.0版。
（2） 一個客戶端生成的隨機數，稍後用於生成"對話密鑰"。
（3） 支持的加密方法，好比RSA公鑰加密。
（4） 支持的壓縮方法。

2 服務器迴應（SeverHello）

（1） 確認使用的加密通訊協議版本，好比TLS 1.0版本。若是瀏覽器與服務器支持的版本不一致，服務器關閉加密通訊。
（2） 一個服務器生成的隨機數，稍後用於生成"對話密鑰"。
（3） 確認使用的加密方法，好比RSA公鑰加密，此時帶有公鑰信息。
（4） 服務器證書。

3 客戶端迴應

（1） 一個隨機數pre-master key。該隨機數用服務器公鑰加密，防止被竊聽。
（2）編碼改變通知，表示隨後的信息都將用雙方商定的加密方法和密鑰發送。
（3） 客戶端握手結束通知，表示客戶端的握手階段已經結束。這一項同時也是前面發送的全部內容的hash值，用來供服務器校驗。

        上面第一項的隨機數，是整個握手階段出現的第三個隨機數，又稱"pre-master key"。有了它之後，客戶端和服務器就同時有了三個隨機數，接着雙方就用事先商定的加密方法，各自生成本次會話所用的同一把"會話密鑰"。

 

至於爲何必定要用三個隨機數，來生成"會話密鑰"：

        "無論是客戶端仍是服務器，都須要隨機數，這樣生成的密鑰纔不會每次都同樣。因爲SSL協議中證書是靜態的，所以十分有必要引入一種隨機因素來保證協商出來的密鑰的隨機性。

        對於RSA密鑰交換算法來講，pre-master-key自己就是一個隨機數，再加上hello消息中的隨機，三個隨機數經過一個密鑰導出器最終導出一個對稱密鑰。

        pre master的存在在於SSL協議不信任每一個主機都能產生徹底隨機的隨機數，若是隨機數不隨機，那麼pre master secret就有可能被猜出來，那麼僅適用pre master secret做爲密鑰就不合適了，所以必須引入新的隨機因素，那麼客戶端和服務器加上pre master secret三個隨機數一同生成的密鑰就不容易被猜出了，一個僞隨機可能徹底不隨機，但是是三個僞隨機就十分接近隨機了，每增長一個自由度，隨機性增長的可不是一。"

        此外，若是前一步，服務器要求客戶端證書，客戶端會在這一步發送證書及相關信息。

4 服務器的最後迴應

        服務器收到客戶端的第三個隨機數pre-master key以後，計算生成本次會話所用的"會話密鑰"。（客戶端在第三階段也生成這個「會話祕鑰」）。而後，向客戶端最後發送下面信息。
（1）編碼改變通知，表示隨後的信息都將用雙方商定的加密方法和密鑰發送。
（2）服務器握手結束通知，表示服務器的握手階段已經結束。這一項同時也是前面發送的全部內容的hash值，用來供客戶端校驗。

        至此，整個握手階段所有結束。接下來，客戶端與服務器進入加密通訊，就徹底是使用普通的HTTP協議，只不過用"會話密鑰"加密內容。

 

TLS的主要目標是使SSL更安全，並使協議的規範更精確和完善。TLS 在SSL v3.0 的基礎上，提供瞭如下加強內容：

　　1）更安全的MAC算法

　　2）更嚴密的警報

　　3）「灰色區域」規範的更明確的定義

　　3．TLS對於安全性的改進

　　1）對於消息認證使用密鑰散列法：TLS 使用「消息認證代碼的密鑰散列法」（HMAC），當記錄在開放的網絡（如因特網）上傳送時，該代碼確保記錄不會被變動。SSLv3.0還提供鍵控消息認證，但HMAC比SSLv3.0使用的（消息認證代碼）MAC 功能更安全。

　2）加強的僞隨機功能（PRF）：PRF生成密鑰數據。在TLS中，HMAC定義PRF。PRF使用兩種散列算法保證其安全性。若是任一算法暴露了，只要第二種算法未暴露，則數據仍然是安全的。

　3）改進的已完成消息驗證：TLS和SSLv3.0都對兩個端點提供已完成的消息，該消息認證交換的消息沒有被變動。然而，TLS將此已完成消息基於PRF和HMAC值之上，這也比SSLv3.0更安全。

　4）一致證書處理：與SSLv3.0不一樣，TLS試圖指定必須在TLS之間實現交換的證書類型。

　5）特定警報消息：TLS提供更多的特定和附加警報，以指示任一會話端點檢測到的問題。TLS還對什麼時候應該發送某些警報進行記錄。

 

 

HTTPS很安全，很古老也很成熟，爲何一直到今天咱們還有66%的網站不支持HTTPS呢？

        一、慢，HTTPS未經任何優化的狀況下要比HTTP慢幾百毫秒以上，特別在移動端可能要慢500毫秒以上，關於HTTPS慢和如何優化已是一個很是系統和複雜的話題

        二、貴，特別在計算性能和服務器成本方面。HTTPS爲何會增長服務器的成本？相信你們也都清楚HTTPS要額外計算，要頻繁地作加密和解密操做，幾乎每個字節都須要作加解密，這就產生了服務器成本

 

另外還有:

        一、大量的計算。SSL的每個字節都涉及到較爲複雜的計算。即便是clientHello，也須要在握手完成時作校驗。

        二、TLS協議的封裝和解析。HTTPS全部數據都是按照TLS record格式進行封裝和解析的。

       三、協議的網絡交互。從TLS的握手過程能夠看出，即便不須要進行任何計算，TLS的握手也須要至少1個RTT（round trip time)以上的網絡交互。

RTT(Round-Trip Time): 往返時延。在計算機網絡中它是一個重要的性能指標，表示從發送端發送數據開始，到發送端收到來自接收端的確認（接收端收到數據後便當即發送確認），總共經歷的時延。

        四、HTTPS下降用戶訪問速度（需屢次握手）

        五、網站改用 HTTPS 之後，由 HTTP 跳轉到 HTTPS 的方式增長了用戶訪問耗時（多數網站採用 30一、302 跳轉）

        六、HTTPS 涉及到的安全算法會消耗 CPU 資源，須要增長服務器資源（https 訪問過程須要加解密）

 

 

 

HTTPS涉及的計算環節
        一、非對稱密鑰交換。好比RSA, Diffie-Hellman, ECDHE.這類算法的主要做用就是根據客戶端和服務端不對稱的信息，通過高強度的密鑰生成算法，生成對稱密鑰，用於加解密後續應用消息。

         二、對稱加解密。服務端使用密鑰A對響應內容進行加密，客戶端使用相同的密鑰A對加密內容進行解密，反之亦然。

        三、消息一致性驗證。每一段加密的內容都會附加一個MAC消息，即消息認證碼。簡單地說就是對內容進行的安全哈希計算，接收方須要校驗MAC碼。

        四、證書籤名校驗。這個階段主要發生在客戶端校驗服務端證書身份時，須要對證書籤名進行校驗，確保證書的真實性。

 

以上圖片文字解釋來源：https://www.cnblogs.com/mylanguage/p/5635524.html

OCSP(Online Certificate Status Protocol，在線證書狀態協議)

 

 

如何優化HTTPS的速度
HSTS重定向技術

HSTS（HTTP Strict Transport Security）技術，啓用HSTS後，將保證瀏覽器始終鏈接到網站的 HTTPS 加密版本。

        1. 用戶在瀏覽器裏輸入 HTTP 協議進行訪問時，瀏覽器會自動將 HTTP 轉換爲 HTTPS 進行訪問，確保用戶訪問安全；

        2. 省去301跳轉的出現，縮短訪問時間；

        3. 能阻止基於 SSL Strip 的中間人攻擊，萬一證書有錯誤，則顯示錯誤，用戶不能迴避警告，從而可以更加有效安全的保障用戶的訪問。

 

TLS握手優化

        在傳輸應用數據以前，客戶端必須與服務端協商密鑰、加密算法等信息，服務端還要把本身的證書發給客戶端代表其身份，這些環節構成 TLS 握手過程。

        採用 False Start （搶先開始）技術，瀏覽器在與服務器完成 TLS 握手前，就開始發送請求數據，服務器在收到這些數據後，完成 TLS 握手的同時，開始發送響應數據。

        開啓 False Start 功能後，數據傳輸時間將進一步縮短。

 

Session Identifier（會話標識符）複用

        若是用戶的一個業務請求包含了多條的加密流，客戶端與服務器將會反覆握手，一定會致使更多的時間損耗。或者某些特殊狀況致使了對話忽然中斷，雙方就須要從新握手，增長了用戶訪問時間。

        （1）服務器爲每一次的會話都生成並記錄一個 ID 號，而後發送給客戶端；

        （2）若是客戶端發起從新鏈接，則只要向服務器發送該 ID 號；

        （3）服務器收到客戶端發來的 ID 號，而後查找本身的會話記錄，匹配 ID 以後，雙方就能夠從新使用以前的對稱加密祕鑰進行數據加密傳輸，而沒必要從新生成，減小交互時間。

 

開啓OSCP Stapling，提升TLS握手效率

        採用OCSP Stapling ，提高 HTTPS 性能。服務端主動獲取 OCSP 查詢結果並隨着證書一塊兒發送給客戶端，從而客戶端可直接經過 Web Server 驗證證書，提升 TLS 握手效率。

        服務器模擬瀏覽器向 CA 發起請求，並將帶有 CA 機構簽名的 OCSP 響應保存到本地，而後在與客戶端握手階段，將 OCSP 響應下發給瀏覽器，省去瀏覽器的在線驗證過程。因爲瀏覽器不須要直接向 CA 站點查詢證書狀態，這個功能對訪問速度的提高很是明顯。

 

徹底前向加密PFS，保護用戶數據，預防私鑰泄漏

        非對稱加密算法 RSA，包含了公鑰、私鑰，其中私鑰是保密不對外公開的，因爲此算法既能夠用於加密也能夠用於簽名，因此用途甚廣，可是仍是會遇到一些問題：

（1） 假如我是一名黑客，雖然如今我不知道私鑰，可是我能夠先把客戶端與服務器以前的傳輸數據（已加密）所有保存下來

（2）若是某一天，服務器維護人員不當心把私鑰泄露了，或者服務器被我攻破獲取到了私鑰

（3）那我就能夠利用這個私鑰，破解掉以前已被我保存的數據，從中獲取有用的信息

        因此爲了防止上述現象發生，咱們必須保護好本身的私鑰。

        若是私鑰確實被泄漏了，那咱們改如何補救呢？那就須要PFS（perfect forward secrecy）徹底前向保密功能，此功能用於客戶端與服務器交換對稱密鑰，起到前向保密的做用，也即就算私鑰被泄漏，黑客也沒法破解先前已加密的數據。

        實現此功能須要服務器支持如下算法和簽名組合：

（1）ECDHE 密鑰交換、RSA 簽名；

（2）ECDHE 密鑰交換、ECDSA 簽名；

 

優化總結易記版：

一、HSTS重定向技術：將http自動轉換爲https，減小301重定向

二、TLS握手優化：在TLS握手完成前客戶端就提早向服務器發送數據

三、會話標識符：服務器記錄下與某客戶端的會話ID，下次鏈接客戶端發ID過來就能夠直接用以前的私鑰交流了

四、OSCP Stapling：服務器將帶有 CA 機構簽名的 OCSP 響應在握手時發給客戶端，省的客戶端再去CA查詢

五、徹底前向加密PFS：使用更牛逼複雜的祕鑰算法

 

 

部份內容參考：

https://www.cnblogs.com/wqhwe/p/5407468.html 

https://www.cnblogs.com/xzwblog/p/6834663.html

https://segmentfault.com/p/1210000009272802/read原文：https://blog.csdn.net/qq_35642036/article/details/82788421