https基礎流程

標籤：密碼編譯演算法   UI   申請   準備工作   images   到期   流程圖   訪問   校正   

一、HTTPS請求流程圖

1、https在真正請求資料前，會先與伺服器有幾次握手驗證，以證明相互的身份，如：

二、驗證流程

https通訊進行的準備工作。最主要的是用戶端預置認證機構的根憑證、伺服器端產生認證。

　　1、用戶端

　　　　在目前主流瀏覽器，會內建一些常用機構頒發的根憑證（憑證授權單位的公開金鑰）

　　2、服務端

　　　　1、某伺服器要申請認證，必須先自行產生一對公私密金鑰，；

　　　　2、伺服器將公開金鑰交給第三方認證機構買認證；

　　　　3、認證機構用自己的私密金鑰對服務端的公開金鑰進行簽名（即用認證機構的公開金鑰+此簽名， 可以校正服務端的公開金鑰的正確性）；

　　　　4、頒發認證，實際就是將伺服器的公開金鑰返回，並附加上機構用私密金鑰做的簽名；

　　　　5、伺服器端部署此認證；

 

1、用戶端發起一個https的請求，把自身支援的一系列Cipher Suite（密鑰演算法套件，簡稱Cipher）發送給服務端。

2、服務端接收到用戶端所有的Cipher後與自身支援的對比，如果不支援則串連斷開，反之則會從中選出一種密碼編譯演算法和HASH演算法以認證的形式返回給用戶端 認證中還包含了公開金鑰

頒證機構 網址 失效日期等等（此為明文。明文的含義是，本認證被截獲、篡改均可被用戶端識別）。

3、用戶端收到服務端響應後會做以下幾件事：

　　3.1 驗證認證的合法性 

　　　　頒發認證的機構是否合法與是否到期，認證中包含的網站地址是否與正在訪問的地址一致等。

　　　　按認證裡頒布機構的資訊，到本地取出對應機構的認證（機構公開金鑰），對伺服器的公開金鑰簽名驗證。如簽名驗證正確，說明此伺服器公開金鑰是經此機構保證的。

　　　　如果本地沒有找到對應的機構認證、或簽名認證不正確，則驗證認證失敗。

　　　　認證驗證通過後，在瀏覽器的地址欄會加上一把小鎖(每家瀏覽器驗證通過後的提示不一樣 不做討論)。

　　3.2 產生隨機密碼

　　　　如果認證驗證通過，或者使用者接受了不授信的認證，此時瀏覽器會產生一串隨機數，然後用認證中的公開金鑰加密。

　　3.3 HASH握手資訊

　　　　用最開始約定好的HASH方式，把握手訊息取HASH值，  然後用 隨機數加密 “握手訊息+握手訊息HASH值(簽名)”  並一起發送給服務端。

　　　　在這裡之所以要取握手訊息的HASH值，主要是把握手訊息做一個簽名，用於驗證握手訊息在傳輸過程中沒有被篡改過。

4、服務端拿到用戶端傳來的密文，用自己的私密金鑰來解密，得到隨機數密碼；再用隨機數密碼解密握手訊息與HASH值，並與傳過來的HASH值做對比確認是否一致。然後用隨機密

碼加密一段握手訊息(握手訊息+握手訊息的HASH值 )給用戶端。

5、用戶端用隨機數解密並計算握手訊息的HASH，如果與服務端發來的HASH一致，此時握手過程結束，之後所有的通訊資料將由之前瀏覽器產生的隨機密碼並利用對稱式加密演算法

進行加密， 因為這串密鑰只有用戶端和服務端知道，所以即使中間請求被攔截也是沒法解密資料的，以此保證了通訊的安全

 

演算法

非對稱式加密演算法：RSA，DSA/DSS     在用戶端與服務端相互驗證的過程中用的是對稱式加密 

對稱式加密演算法：AES，RC4，3DES     用戶端與服務端相互驗證通過後，以隨機數作為密鑰時，就是對稱式加密

HASH演算法：MD5，SHA1，SHA256  在確認握手訊息沒有被篡改時 

 

 

參考自：

http://www.cnblogs.com/zery/p/5164795.html　　https原理解析

http://www.cnblogs.com/qqmomery/p/6107432.html　　https基礎流程

 

https基礎流程