Https握手協議以及認證認證

來源:互聯網
上載者:User

標籤:

1. 什麼是https

   Https = http + 加密 + 認證

  https是對http的安全強化,在http的基礎上引入了加密和認證過程。通過加密和認證構建一條安全的傳輸通道。所以https可以看成是:在安全通道內,對資料進行對稱式加密後傳輸。這樣即使駭客打破了安全通道,還有一層資料加密。極大的保障了資料通訊的安全性。

2. https的演化

    我們將從http的不安全方面著手,通過三個情境的闡述,來說明https是怎麼來的以及其基本原理

   Round 1:

    正常交流:

       “客戶”->“伺服器”:你好

       “伺服器”->“客戶”:你好,我是伺服器

    這是一次正常的用戶端和伺服器的交流。中間沒有任何安全校正,用戶端得知對方是伺服器後,就完全的相信了對方就是自己想要的伺服器。這種情況下,伺服器如果收到攻擊,有人偽造是伺服器,用戶端也是不知情的。既然知道了這種通訊的不安全,所以引入了RSA加密,說明下:用RSA私密金鑰進行加密,RSA公開金鑰進行解密的是簽名;公開金鑰加密,私密金鑰解密的是加密。於是有第二輪的通訊

    Round 2:     

       “客戶”->“伺服器”:你好

       “伺服器”->“客戶”:你好,我是伺服器

  “客戶”->“伺服器”:向我證明你就是伺服器

  “伺服器”->“客戶”:你好,我是伺服器 {***********}(對內容用私密金鑰進行簽名)

  “客戶”->“伺服器”:{我的帳號是aaa,密碼是123,把我的餘額的資訊發給我看看}{***********}(對內容用私密金鑰進行RSA加密)

  “伺服器”->“客戶”:{你的餘額是100元}{***********}(對內容用私密金鑰進行簽名)

     在第二輪通訊中,伺服器通過RSA私密金鑰進行簽名,用戶端用RSA公開金鑰進行驗證來達到 確定伺服器身份。雖然引入了RSA加密後,伺服器的身份是被唯一確認了,但是由於伺服器的後續所有的資訊都是通過RSA私密金鑰進行加密,而公開金鑰是對外公開的,這樣會導致伺服器的所有內容對其他人都是公開的。所以這次通訊同樣存在安全問題。

     Round 3:  

    “客戶”->“伺服器”:你好

  “伺服器”->“客戶”:你好,我是伺服器

  “客戶”->“伺服器”:向我證明你就是伺服器

  “伺服器”->“客戶”:你好,我是伺服器 {***********}(對內容用私密金鑰進行RSA加密)

  “客戶”->“伺服器”:{我們後面的通訊過程,用對稱式加密來進行,這裡是對稱式加密演算法和密鑰} {***********}(對內容用公開金鑰進行RSA加密)

   “伺服器”->“客戶”:{OK,收到!}{***********}(用雙方協商的密鑰進行加密-- 對稱式加密演算法)

   “客戶”->“伺服器”:{我的帳號是aaa,密碼是123,把我的餘額的資訊發給我看看} {***********}(用雙方協商的密鑰進行加密-- 對稱式加密演算法)

   “伺服器”->“客戶”:{你的餘額是100元}[密鑰|對稱式加密演算法]{***********}(用雙方協商的密鑰進行加密-- 對稱式加密演算法)

      在第三輪通訊包括了兩部分,第一部分是用非對稱式加密演算法來進行身份認證。第二部分,資訊通訊用了對稱式加密演算法進行加解密。這也就就是https構建安全通道的基本流程。

3.認證

    在第三輪通訊的第一部分,雖然用非對稱式加密演算法來進行身份認證可以很安全,但是隨之的問題是如何把RSA的公開金鑰給用戶端,如果用傳統方式:用網路發送或是在通訊過程中攜帶公開金鑰,都會存在公開金鑰被篡改的情況。為瞭解決這個問題,所以才有了數位憑證的出現。通過一個大家都認可的,並且是可信的第三方來頒發。

   數位憑證一般包括:

  • 認證的發布機構
  • 認證的有效期間
  • 公開金鑰
  • 認證所有者(Subject)
  • 簽名所使用的演算法
  • 指紋以及指紋演算法

   這樣,伺服器在身份認證階段就不需要把公開金鑰發給用戶端了,而是把伺服器端的認證發給用戶端,用戶端拿到伺服器憑證後,通過驗證認證來完成身份認證。一般認證認證包括:認證的有效期間,憑證鏈結的驗證。憑證鏈結的驗證是通過根憑證對認證進行一級一級的認證。憑證鏈結的認證過程如所示:

   

 

 認證認證成功後,接下來就可以使用伺服器憑證裡面的公開金鑰進行伺服器身份的驗證。

第一部分是用非對稱式加密演算法來進行身份認證。同時引入了數位憑證來達到保護密鑰的安全。

4. DH金鑰交換演算法

   在上面第三輪通訊中,第一部分身份認證是通過非對稱式加密演算法,可以保證其安全性,但是第二部分,由於用的是對稱式加密演算法,那麼如果保證密鑰不被截獲是整個通訊安全的重點。在https裡用的是DH金鑰交換演算法。它的安全性是依賴於離散對數的難解性得到保證。下面簡單介紹下DH金鑰交換演算法。在介紹前先看幾個數學上的名詞

  3.1 產生元

  對於一個素數q,如果數值 a mod q, a^2 mod q, a^3 mod q,... a ^q-1 mod q 是各不相同的整數,並且以某種相片順序組成從1到q-1,則整數a就為素數q的一個產生元,或稱元根。比如5就是23的一個產生元

  3.2 離散對數

   對於一個整數b和一個素數q的產生元a,可以找到一個唯一的指數i,使得:

      b = a^i mod q (0 <= i <= q-1)

   則指數i稱為b的以a為底數的模q的離散對數。

   對於給定的a,i,q可以很容易的計算出b,但是對於給出b,a,q卻是很難計算出i。這就是DH演算法和許多公開金鑰密碼演算法的基礎。

  3.3 DH金鑰交換過程

   使用者A和使用者B共用素數q以及其產生元a,現在A和B進行金鑰交換

   使用者A:產生隨機數Xa < q,計算Ya = a^Xa mod q ,同時把Ya發送給B

   使用者B:產生隨機數Xb < q,計算Yb= a^Xb mod q,同時把Yb發送給A

   A拿到Yb後:計算Ka = (Yb)^Xa mod q

   B拿到Ya後,計算Kb = (Ya)^Xb mod q

   最後的結果是:Ka = Kb

   證明過程這裡就省略了,用代入法很快就可以證明出Ka = Kb

  而這裡的K就是A和B雙方協商的密鑰

5. 握手協議

   通過上述,我們可以知道整個https的過程其實包括以下幾個過程:認證認證,身份認證,金鑰交換,傳輸資料的加解密,下面是一個完整的https握手協議的流程:

  

   

 

    

上述https演化一節參考了:http://www.cnblogs.com/JeffreySun/archive/2010/06/24/1627247.html  

Https握手協議以及認證認證

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.