溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
小編給大家分享一下HTTP與HTTPS有哪些區別，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！
超文本傳輸協議HTTP協議被用于在Web瀏覽器和網站服務器之間傳遞信息，HTTP協議以明文方式發送內容，不提供任何方式的數據加密，如果攻擊者截取了Web瀏覽器和網站服務器之間的傳輸報文，就可以直接讀懂其中的信息，因此，HTTP協議不適合傳輸一些敏感信息，比如：信用卡號、密碼等支付信息。
為了解決HTTP協議的這一缺陷，需要使用另一種協議：安全套接字層超文本傳輸協議HTTPS，為了數據傳輸的安全，HTTPS在HTTP的基礎上加入了SSL/TLS協議，SSL/TLS依靠證書來驗證服務器的身份，并為瀏覽器和服務器之間的通信加密。
HTTPS協議是由SSL/TLS+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，要比http協議安全
HTTPS協議的主要作用可以分為兩種：一種是建立一個信息安全通道，來保證數據傳輸的安全；另一種就是確認網站的真實性。
1、https協議需要到CA申請證書，一般免費證書較少，因而需要一定費用。
2、http是超文本傳輸協議，信息是明文傳輸，https則是具有安全性的ssl/tls加密傳輸協議。
3、http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。
4、http的連接很簡單，是無狀態的；HTTPS協議是由SSL/TLS+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。
這部分內容作為前提點綴，如果你是初次了解HTTPS，看不懂這里不要緊，只要把文章后面看完，再回過頭來看這里的內容，就能恍然大悟了。
**第一層：**HTTPS本質上是為了實現加密通信，理論上，加密通信就是雙方都持有一個對稱加密的秘鑰，然后就可以安全通信了
但是，無論這個最初的秘鑰是由客戶端傳給服務端，還是服務端傳給客戶端，都是明文傳輸，中間人都可以知道。那就讓這個過程變成密文就好了唄，而且還得是中間人解不開的密文。
第二層：使用非對稱加密 加密客戶端與服務端協商生成對稱秘鑰之前各種鹽值、種子。
但是，在使用非對稱加密秘鑰之前，比如由服務端生成非對稱秘鑰，它需要將生成的公鑰給到客戶端，這個時候公鑰就會在網絡中明文傳輸，任何人都可以更改，會有中間人攻擊的問題。因此，只能引入公信機構CA，使我們傳輸自己的公鑰時可以保證不會被篡改！
*第三層：*服務端把自己的公鑰給 CA，讓 CA 用 CA 的私鑰加密，然后返回加密結果（可以用CA的公鑰解密，如果要篡改結果，必須再次用 CA 的私鑰加密，由于中間人沒法獲取私鑰，所以無法篡改）。
（1）客戶使用https的URL訪問Web服務器，要求與Web服務器建立SSL連接。
（2）Web服務器收到客戶端請求后，會將網站的證書信息（證書中包含公鑰）傳送一份給客戶端。
（3）客戶端的瀏覽器與Web服務器開始協商SSL/TLS連接的安全等級，也就是信息加密的等級。
（4）客戶端的瀏覽器根據雙方同意的安全等級，建立會話密鑰，然后利用網站的公鑰將會話密鑰加密，并傳送給網站。
（5）Web服務器利用自己的私鑰解密出會話密鑰。
（6）Web服務器利用會話密鑰加密與客戶端之間的通信。
盡管HTTPS并非絕對安全，掌握根證書的機構、掌握加密算法的組織同樣可以進行中間人形式的攻擊，但HTTPS仍是現行架構下最安全的解決方案，他大幅增加了中間人攻擊的成本
上面客戶端使用HTTPS與服務器通信中使用到了CA認證，這里可能大家會問為什么不直接使用非對稱加密的形式直接進行，首先這里先介紹下非對稱加密。
?
非對稱加密：客戶端和服務端均擁有一個公有密匙和一個私有密匙。公有密匙可以對外暴露，而私有密匙只有自己可見。
使用公有密匙加密的消息，只有對應的私有密匙才能解開。反過來，使用私有密匙加密的消息，只有公有密匙才能解開。這樣客戶端在發送消息前，先用服務器的公匙對消息進行加密，服務器收到后再用自己的私匙進行解密。
非對稱加密的優點：
非對稱加密采用公有密匙和私有密匙的方式，解決了http中消息保密性問題，而且使得私有密匙泄露的風險降低。 因為公匙加密的消息只有對應的私匙才能解開，所以較大程度上保證了消息的來源性以及消息的準確性和完整性。 非對稱加密的缺點：
非對稱加密時需要使用到接收方的公匙對消息進行加密，但是公匙不是保密的，任何人都可以拿到，中間人也可以。那么中間人可以做兩件事，第一件是中間人可以在客戶端與服務器交換公匙的時候，將客戶端的公匙替換成自己的。這樣服務器拿到的公匙將不是客戶端的，而是中間人的。服務器也無法判斷公匙來源的正確性。第二件是中間人可以不替換公匙，但是他可以截獲客戶端發來的消息，然后篡改，然后用服務器的公匙加密再發往服務器，服務器將收到錯誤的消息。 非對稱加密的性能相對對稱加密來說會慢上幾倍甚至幾百倍，比較消耗系統資源。正是因為如此，https將兩種加密結合了起來。
為了應對上面非對稱加密帶來的問題，我們就引入了數字證書與數字簽名
故CA認證介入我們的HTTPS連接的過程如下：
1、服務器擁有自己的私鑰與公鑰
2、服務器將公鑰交給CA認證機構，請求給予一份數字證書
3、CA認證機構生成數字證書，并頒發給服務器
4、服務器將帶有公鑰信息的數字證書發給客戶端
5、進入客戶端生成對稱密鑰再進行對接的過程……
SSL：（Secure Socket Layer，安全套接字層），位于可靠的面向連接的網絡層協議和應用層協議之間的一種協議層。SSL通過互相認證、使用數字簽名確保完整性、使用加密確保私密性，以實現客戶端和服務器之間的安全通訊。該協議由兩層組成：SSL記錄協議和SSL握手協議。
TLS：(Transport Layer Security，傳輸層安全協議)，用于兩個應用程序之間提供保密性和數據完整性。該協議由兩層組成：TLS記錄協議和TLS握手協議。TLS是HTTP與TCP協議之間的一層，通常TLS發生在TCP三次握手之后，此時進行TLS四次握手，然后再進行HTTP通信
*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的修訂版，在2018年也發布了TLS1.3版本。*TLS 1.0通常被標示為SSL 3.1，TLS 1.1為SSL 3.2，TLS 1.2為SSL 3.3。
目前應用的最廣泛的 TLS 是 1.2，而之前的協議（TLS1.1/1.0、SSLv3/v2）都已經被認為是不安全的了
（1） 客戶端向服務器端索要并驗證公鑰。（2） 雙方協商生成”對話密鑰”。（3） 雙方采用”對話密鑰”進行加密通信。上面過程的前兩步，又稱為”握手階段”（handshake）
下面是我們本次模擬訪問https://www.baidu.com時抓的包，大家可以看到這里面涉及的流程邏輯
1 客戶端發出請求（ClientHello）
（1） 支持的協議版本，比如TLS 1.2版。（2） 一個客戶端生成的隨機數1，稍后用于生成”對話密鑰”。（3） 【支持的密碼套件】支持的加密方法，比如RSA公鑰加密。（4） 支持的壓縮方法。（5） 一個session id，標識是否復用服務器之前的tls連接（需要服務器支持）
2 服務器回應（SeverHello）
（1） 確認使用的加密通信協議版本，比如TLS 1.2版本。如果瀏覽器與服務器支持的版本不一致，服務器關閉加密通信。（2） 一個服務器生成的隨機數2，稍后用于生成”對話密鑰”。（3） 【確認密碼套件】確認使用的加密方法，比如RSA公鑰加密，此時帶有公鑰信息。（4） 一個session id（若同意復用連接）
3 服務器回應（Server Certificate）
（1）服務器證書（該證書即包含服務器公鑰）。
4 服務器回應（Server Key Exchange）
（1）服務器算法變更通知，服務端給客戶端一個用于 ECDHE 算法的公鑰
5 服務器回應（Server CertificateRequest）
（1）請求客戶端證書，此案例中沒有，一般銀行等需要客戶端也加密的才有，比如 U 盾。
6 服務器回應（Server ServerHelloDone）- 標識著 serverHello 這個握手過程結束了。
7 客戶端回應（Client Certificate）- 回應客戶端證書，本案例不涉及
8 客戶端回應（ClientKeyExchange）
（1）客戶端給服務端一個用于 ECDHE 算法的公鑰
?
到這里，服務端與客戶端將 生成最終通信的對稱加密秘鑰：master_secret
計算過程根據上面得到的三個隨機數：
隨機數 1（客戶端隨機數）：在 ClientHello 消息里，由客戶端生成的隨機數1
隨機數 2（服務端隨機數）：在 ServerHello 消息里，由服務端生成的隨機數2
隨機數 3（pre_master)：通過秘鑰交換算法 ECDHE 計算出的，我們叫它 pre_master。
最終的對稱加密秘鑰 master_secret，就是根據這三個隨機數共同計算出來的。
9 客戶端回應（Client CertificateVerif*）*
（1）驗證客戶端證書有效性，本次不涉及
10 客戶端回應（Client ChangeCipherSpec）
（1）秘鑰改變通知，此時客戶端已經生成了 master_secret，之后的消息將都通過 master secret 來加密。
11 客戶端回應（Client Finish）
（1） 客戶端握手結束通知，表示客戶端的握手階段已經結束。這一項同時也是前面發送的所有內容的hash值，用來供服務器校驗。
12 服務器回應（Server ChangeCipherSpec）
（1）秘鑰改變通知，此時服務端也已經生成了 master_secret 了，后面的通信都用此值加密。
13 服務器回應（Server Finish*）*
（1）同 Client Finish，服務器端發送握手結束通知，同時會帶上前面所發內容的hash簽名到客戶端，保證前面通信數據的正確性。
上述流程簡易版（不包含驗證客戶端證書）：
?
1. client –> server ClientHello
客戶端生成隨機數，并發送一組密碼學套件供服務端選
2. server–> client ServerHello
服務端生成隨機數，并從上述密碼學套件組里選一個
3. server–> client Certificate
服務端發給客戶端證書
4. server–> client ServerKeyExchange
服務端發給客戶端秘鑰交換算法所需的值
5. server–> client ServerHelloDone
服務端 hello 階段結束
6. client –> server ClientKeyExchange
客戶端發給服務端秘鑰交換算法所需的值
7. client –> server ChangeCipherSpec
客戶端告訴服務端，我已經知道秘鑰了，之后的消息我就都加密發送了。
8. client –> server Finish
結束并驗證
7. server –> server ChangeCipherSpec
服務端告訴客戶端，我已經知道秘鑰了，之后的消息我就都加密發送了。
9. server–> client Finish
結束并驗證
為什么一定要用三個隨機數，來生成”會話密鑰”呢？
?
“不管是客戶端還是服務器，都需要隨機數，這樣生成的密鑰才不會每次都一樣。由于SSL協議中證書是靜態的，因此十分有必要引入一種隨機因素來保證協商出來的密鑰的隨機性。
對于RSA密鑰交換算法來說，pre-master-key本身就是一個隨機數，再加上hello消息中的隨機數，三個隨機數通過一個密鑰導出器最終導出一個對稱密鑰。
pre master的存在在于SSL協議不信任每個主機都能產生完全隨機的隨機數，如果隨機數不隨機，那么pre master secret就有可能被猜出來，那么僅適用pre master secret作為密鑰就不合適了，因此必須引入新的隨機因素，那么客戶端和服務器加上pre master secret三個隨機數一同生成的密鑰就不容易被猜出了，一個偽隨機可能完全不隨機，可是是三個偽隨機就十分接近隨機了，每增加一個自由度，隨機性增加的可不是一。”
此外，如果前一步，服務器要求客戶端證書，客戶端會在這一步發送證書及相關信息。
以上介紹為TLS1.2的版本，其他TLS如1.0版本的流程會稍有不同，但大致邏輯是一樣的。
TLS 1.2 轉換流程邏輯也可以參考：26丨信任始于握手：TLS1.2連接過程解析 – 飛鳥與新月 – 博客園
更新的 TLS 1.3也可以參考：27丨更好更快的握手：TLS1.3特性解析 – 飛鳥與新月 – 博客園
TLS的主要目標是使SSL更安全，并使協議的規范更精確和完善。TLS 在SSL v3.0 的基礎上，提供了以下增強內容：
1）更安全的MAC算法
2）更嚴密的警報
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還對何時應該發送某些警報進行記錄。
瀏覽器和服務器在使用 TLS 建立連接時需要選擇一組恰當的加密算法來實現安全通信，這些算法的組合被稱為“密碼套件”（cipher suite，也叫加密套件）。上述Client/Server Hello過程中就涉及密碼套件的約定流程。
TLS 的密碼套件命名格式為：密鑰交換算法 + 簽名算法 + 對稱加密算法 + 摘要算法
如對于套件：“ECDHE-RSA-AES256-GCM-SHA384”，其解釋為：握手時使用 ECDHE 算法進行密鑰交換，用 RSA 簽名和身份認證，握手后的通信使用 AES 對稱算法，密鑰長度 256 位，分組模式是 GCM，摘要算法 SHA384 用于消息認證和產生隨機數。
HTTPS很安全，很古老也很成熟，為什么一直到今天我們還有66%的網站不支持HTTPS呢？
1、慢，HTTPS未經任何優化的情況下要比HTTP慢幾百毫秒以上，特別在移動端可能要慢500毫秒以上，關于HTTPS慢和如何優化已經是一個非常系統和復雜的話題
2、貴，特別在計算性能和服務器成本方面。HTTPS為什么會增加服務器的成本？相信大家也都清楚HTTPS要額外計算，要頻繁地做加密和解密操作，幾乎每一個字節都需要做加解密，這就產生了服務器成本
另外還有:
**1、大量的計算。**SSL的每一個字節都涉及到較為復雜的計算。即使是clientHello，也需要在握手完成時做校驗。
2、TLS協議的封裝和解析。HTTPS所有數據都是按照TLS record格式進行封裝和解析的。
**3、協議的網絡交互。**從TLS的握手過程可以看出，即使不需要進行任何計算，TLS的握手也需要至少1個RTT（round trip time)以上的網絡交互。
RTT(Round-Trip Time): 往返時延。在計算機網絡中它是一個重要的性能指標，表示從發送端發送數據開始，到發送端收到來自接收端的確認（接收端收到數據后便立即發送確認），總共經歷的時延。
4、HTTPS降低用戶訪問速度（需多次握手）
5、網站改用 HTTPS 以后，由 HTTP 跳轉到 HTTPS 的方式增加了用戶訪問耗時（多數網站采用 301、302 跳轉）
6、HTTPS 涉及到的安全算法會消耗 CPU 資源，需要增加服務器資源（https 訪問過程需要加解密）
**1、非對稱密鑰交換。**比如RSA, Diffie-Hellman, ECDHE.這類算法的主要作用就是根據客戶端和服務端不對稱的信息，經過高強度的密鑰生成算法，生成對稱密鑰，用于加解密后續應用消息。
**2、對稱加解密。**服務端使用密鑰A對響應內容進行加密，客戶端使用相同的密鑰A對加密內容進行解密，反之亦然。
**3、消息一致性驗證。**每一段加密的內容都會附加一個MAC消息，即消息認證碼。簡單地說就是對內容進行的安全哈希計算，接收方需要校驗MAC碼。
**4、證書簽名校驗。**這個階段主要發生在客戶端校驗服務端證書身份時，需要對證書簽名進行校驗，確保證書的真實性。
以上圖片文字解釋來源：HTTP與HTTPS對訪問速度（性能）的影響 – 宋可欣 – 博客園
OCSP(Online Certificate Status Protocol，在線證書狀態協議)
雖然說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的
HTTPS連接大致可以劃分為兩個部分：第一個是建立連接時的非對稱加密握手，第二個是握手后的對稱加密報文傳輸。
由于目前流行的 AES、ChaCha20 性能都很好，還有硬件優化，報文傳輸的性能損耗可以說是非常地小，小到幾乎可以忽略不計了。所以，通常所說的“HTTPS 連接慢”指的就是剛開始建立連接的那段時間。
在 TCP 建連之后，正式數據傳輸之前，HTTPS 比 HTTP 增加了一個 TLS 握手的步驟，這個步驟最長可以花費兩個消息往返，也就是 2-RTT（TLS1.3只需1-RTT）。而且在握手消息的網絡耗時之外，還會有其他的一些“隱形”消耗，比如：
產生用于密鑰交換的臨時公私鑰對（ECDHE）；
驗證證書時訪問 CA 獲取 CRL 或者 OCSP；
非對稱加密解密處理“Pre-Master”。
1、HSTS重定向技術
HSTS（HTTP Strict Transport Security，HTTP 嚴格傳輸安全）技術，啟用HSTS后，將保證瀏覽器始終連接到網站的 HTTPS 加密版本。這相當于告訴瀏覽器：我這個網站必須嚴格使用 HTTPS 協議，在半年之內（182.5 天）都不允許用 HTTP，你以后就自己做轉換吧，不要再來麻煩我了。
\1. 用戶在瀏覽器里輸入 HTTP 協議進行訪問時，瀏覽器會自動將 HTTP 轉換為 HTTPS 進行訪問，確保用戶訪問安全；
\2. 省去301跳轉的出現，縮短訪問時間；
\3. 能阻止基于 SSL Strip 的中間人攻擊，萬一證書有錯誤，則顯示錯誤，用戶不能回避警告，從而能夠更加有效安全的保障用戶的訪問。
2、TLS握手優化
在傳輸應用數據之前，客戶端必須與服務端協商密鑰、加密算法等信息，服務端還要把自己的證書發給客戶端表明其身份，這些環節構成 TLS 握手過程。
使用 ECDHE 橢圓曲線密碼套件，可以節約帶寬和計算量，還能實現“False Start”，采用 False Start （搶先開始）技術，瀏覽器在與服務器完成 TLS 握手前，就開始發送請求數據，服務器在收到這些數據后，完成 TLS 握手的同時，開始發送響應數據。
開啟 False Start 功能后，數據傳輸時間將進一步縮短。
3、Session Identifier（會話標識符）復用
如果用戶的一個業務請求包含了多條的加密流，客戶端與服務器將會反復握手，必定會導致更多的時間損耗。或者某些特殊情況導致了對話突然中斷，雙方就需要重新握手，增加了用戶訪問時間。
（1）服務器為每一次的會話都生成并記錄一個 ID 號，然后發送給客戶端；
（2）如果客戶端發起重新連接，則只要向服務器發送該 ID 號；
（3）服務器收到客戶端發來的 ID 號，然后查找自己的會話記錄，匹配 ID 之后，雙方就可以重新使用之前的對稱加密秘鑰進行數據加密傳輸，而不必重新生成，減少交互時間（只用一個消息往返就可以建立安全連接）。
但它也有缺點，服務器必須保存每一個客戶端的會話數據，對于擁有百萬、千萬級別用戶的網站來說存儲量就成了大問題，加重了服務器的負擔。于是又出現了第二種“Session Ticket”的方案。
它有點類似 HTTP 的 Cookie，存儲的責任由服務器轉移到了客戶端，服務器加密會話信息，用“New Session Ticket”消息發給客戶端，讓客戶端保存。重連的時候，客戶端使用擴展“session_ticket”發送“Ticket”而不是“Session ID”，服務器解密后驗證有效期，就可以恢復會話，開始加密通信。不過“Session Ticket”方案需要使用一個固定的密鑰文件（ticket_key）來加密 Ticket，為了防止密鑰被破解，保證“前向安全”，密鑰文件需要定期輪換，比如設置為一小時或者一天。
4、開啟OSCP Stapling（OSCP裝訂），提高TLS握手效率
客戶端的證書驗證其實是個很復雜的操作，除了要公鑰解密驗證多個證書簽名外，因為證書還有可能會被撤銷失效，客戶端有時還會再去訪問 CA，下載 CRL （Certificate revocation list，證書吊銷列表，用于確認證書是否有效，體積較大，現基本不用）或者 OCSP 數據，這又會產生 DNS 查詢、建立連接、收發數據等一系列網絡通信，增加好幾個 RTT。
采用OCSP Stapling ，提升 HTTPS 性能。服務端主動獲取 OCSP 查詢結果并隨著證書一起發送給客戶端，從而客戶端可直接通過 Web Server 驗證證書，提高 TLS 握手效率。
服務器模擬瀏覽器向 CA 發起請求，并將帶有 CA 機構簽名的 OCSP 響應保存到本地，然后在與客戶端握手階段，將 OCSP 響應下發給瀏覽器，省去瀏覽器的在線驗證過程。由于瀏覽器不需要直接向 CA 站點查詢證書狀態，這個功能對訪問速度的提升非常明顯。
5、完全前向加密PFS，保護用戶數據，預防私鑰泄漏
非對稱加密算法 RSA，包含了公鑰、私鑰，其中私鑰是保密不對外公開的，由于此算法既可以用于加密也可以用于簽名，所以用途甚廣，但是還是會遇到一些問題：
（1） 假如我是一名黑客，雖然現在我不知道私鑰，但是我可以先把客戶端與服務器之前的傳輸數據（已加密）全部保存下來
（2）如果某一天，服務器維護人員不小心把私鑰泄露了，或者服務器被我攻破獲取到了私鑰
（3）那我就可以利用這個私鑰，破解掉之前已被我保存的數據，從中獲取有用的信息，即所謂的“今日截獲，明日破解”。
所以為了防止上述現象發生，我們必須保護好自己的私鑰。
如果私鑰確實被泄漏了，那我們改如何補救呢？那就需要PFS（perfect forward secrecy）完全前向保密功能，此功能用于客戶端與服務器交換對稱密鑰，起到前向保密的作用，也即就算私鑰被泄漏，黑客也無法破解先前已加密的數據。維基解釋是：長期使用的主密鑰泄漏不會導致過去的會話密鑰泄漏
實現此功能需要服務器支持以下算法和簽名組合：
（1）ECDHE 密鑰交換、RSA 簽名；
（2）ECDHE 密鑰交換、ECDSA 簽名；
ECDHE 算法在每次握手時都會生成一對臨時的公鑰和私鑰，每次通信的密鑰對都是不同的，也就是“一次一密”，即使黑客花大力氣破解了這一次的會話密鑰，也只是這次通信被攻擊，之前的歷史消息不會受到影響，仍然是安全的。
使用ECDHE算法的TLS交換過程具有如下優點：運算速度快，安全性高，還支持“False Start”，能夠把握手的消息往返由 2-RTT 減少到 1-RTT
所以現在主流的服務器和瀏覽器在握手階段都已經不再使用 RSA，改用 ECDHE，而 TLS1.3 在協議里明確廢除 RSA 和 DH 則在標準層面保證了“前向安全”。
以上是“HTTP與HTTPS有哪些區別”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
