SSL協議、HTTP和HTTPS和區別

標籤：ret   ssl協議   預設   演算法   加密   建立串連   伺服器   解密   自己   

SSL協議

SLL協議的握手過程

開始加密通訊之前，用戶端和伺服器首先必須建立串連和交換參數，這個過程叫做握手（handshake）。

第一步，用戶端給出協議版本號碼、一個用戶端產生的隨機數（Client random），以及用戶端支援的加密方法。

 

第二步，伺服器確認雙方使用的加密方法，並給出數位憑證、以及一個伺服器產生的隨機數（Server random）。

 

第三步，用戶端確認數位憑證有效，然後產生一個新的隨機數（Premaster secret），並使用數位憑證中的公開金鑰，加密這個隨機數，發給伺服器。

 

第四步，伺服器使用自己的私密金鑰，擷取用戶端絲髮來的隨機數（即Premaster secret）。

 

第五步，用戶端和伺服器根據約定的加密方法，使用前面的三個隨機數，產生"對話密鑰"（session key），用來加密接下來的整個對話過程。

私密金鑰的作用

 

1）產生對話密鑰一共需要三個隨機數。

 

（2）握手之後的對話使用"對話密鑰"加密（對稱式加密），伺服器的公開金鑰和私密金鑰只用於加密和解密"對話密鑰"（非對稱式加密），無其他作用。

 

（3）伺服器公開金鑰放在伺服器的數位憑證之中。

DH演算法的握手階段

 

整個握手階段都不加密（也沒法加密），都是明文的。因此，如果有人竊聽通訊，他可以知道雙方選擇的加密方法，以及三個隨機數中的兩個。整個通話的安全，只取決於第三個隨機數（Premaster secret）能不能被破解。

 

雖然理論上，只要伺服器的公開金鑰足夠長（比如2048位），那麼Premaster secret可以保證不被破解。但是為了足夠安全，我們可以考慮把握手階段的演算法從預設的RSA演算法，改為 Diffie-Hellman演算法（簡稱DH演算法）。

 

採用DH演算法後，Premaster secret不需要傳遞，雙方只要交換各自的參數，就可以算出這個隨機數。

session的恢複

握手階段用來建立SSL串連。如果出於某種原因，對話中斷，就需要重新握手。

這時有兩種方法可以恢複原來的session：一種叫做session ID，另一種叫做session ticket。

session ID的思想很簡單，就是每一次對話都有一個編號（session ID）。如果對話中斷，下次重連的時候，只要用戶端給出這個編號，且伺服器有這個編號的記錄，雙方就可以重新使用已有的"對話密鑰"，而不必重建一把。

session ID是目前所有瀏覽器都支援的方法，但是它的缺點在於session ID往往只保留在一台伺服器上。所以，如果用戶端的請求發到另一台伺服器，就無法恢複對話。session ticket就是為瞭解決這個問題而誕生的，目前只有Firefox和Chrome瀏覽器支援。

HTTPS和HTTP的區別超文字傳輸通訊協定 (HTTP)HTTP協議被用於在Web瀏覽器和網站伺服器之間傳遞資訊。HTTP協議以明文方式發送內容，不提供任何方式的資料加密，如果攻擊者截取了Web瀏覽器和網站伺服器之間的傳輸報文，就可以直接讀懂其中的資訊，因此HTTP協議不適合傳輸一些敏感資訊，比如信用卡號、密碼等。為瞭解決HTTP協議的這一缺陷，需要使用另一種協議：安全通訊端層超文字傳輸通訊協定 (HTTP)HTTPS。為了資料轉送的安全， HTTPS在HTTP的基礎上加入了SSL協議，SSL依靠認證來驗證伺服器的身份，並為瀏覽器和伺服器之間的通訊加密。HTTPS和HTTP的區別主要為以下四點：一、https協議需要到ca申請認證，一般免費認證很少，需要交費。二、http是超文字傳輸通訊協定 (HTTP)，資訊是明文傳輸，https 則是具有安全性的ssl加密傳輸協議。三、http和https使用的是完全不同的串連方式，用的連接埠也不一樣，前者是80，後者是443。四、http的串連很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路通訊協定，比http協議安全。

　　

 

SSL協議、HTTP和HTTPS和區別