SSL&HTTPS簡單介紹

標籤：版本   rsa   center   合法性   應用程式   通過   http   現在   --   

這篇是最近看SSL和HTTPS的一個簡單性總結，其中內容大部分都是參考網路上的內容，自己歸納整理了下。

 

 

SSL介紹

HTTPS介紹HTTP請求資料工作流程：

 

l  使用者在瀏覽器中輸入網址，並告訴瀏覽器自己需要那些東西；

l  瀏覽器解析網址，並將使用者需要的東西記錄成一張清單；

l  瀏覽器發送資訊給伺服器，並附上清單，告訴伺服器自己需要那些資訊；

l  伺服器收到瀏覽器發送的資訊，將對應的資訊和清單返回回去；

l  伺服器發送資訊給瀏覽器；

l  瀏覽器拿到資訊，並根據清單核對資訊；

l  將資訊展現給使用者。

 

這其中就有個問題，瀏覽器和伺服器都沒有驗證清單資訊的有效性和對方的身份。萬一有人在中途將瀏覽器（伺服器）傳遞給伺服器（瀏覽器）的資訊截獲下來，然後將資訊清單給替換掉，或者直接偽造一個資訊請求代替原來的請求發送給服務端這種情況該怎麼辦。

HTTPS

正是因為HTTP請求有這些安全性的問題，所以HTTPS誕生了。

HTTPS（全稱：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全為目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL，而它的大體方式如下：

 

1.    用戶端向伺服器索要公匙，然後使用公匙加密資訊

2.    伺服器收到加密後的資訊，用自己的私匙解密

公開金鑰密碼和演算法都是公開的，而私密金鑰則是保密的。加密使用的公開金鑰和解碼使用的私密金鑰都是不相同的，因此這是一個 非對稱式加密 演算法。

對稱式加密和非對稱式加密對稱式加密

對稱式加密是最快速、最簡單的一種加密方式，加密（encryption）與解密（decryption）用的是同樣的密鑰（secret key）。對稱式加密有很多種演算法，由於它效率很高，所以被廣泛使用在很多加密協議的核心當中。

對稱式加密通常使用的是相對較小的密鑰，一般小於256 bit。因為密鑰越大，加密越強，但加密與解密的過程越慢。如果你只用1 bit來做這個密鑰，那駭客們可以先試著用0來解密，不行的話就再用1解；但如果你的密鑰有1 MB大，駭客們可能永遠也無法破解，但加密和解密的過程要花費很長的時間。

非對稱式加密

非對稱式加密為資料的加密與解密提供了一個非常安全的方法，它使用了一對密鑰，公開金鑰（public key）和私密金鑰（private key）。私密金鑰只能由一方安全保管，不能外泄，而公開金鑰則可以發給任何請求它的人。非對稱式加密使用這對密鑰中的一個進行加密，而解密則需要另一個密鑰。比如，你向銀行請求公開金鑰，銀行將公開金鑰發給你，你使用公開金鑰對訊息加密，那麼只有私密金鑰的持有人--銀行才能對你的訊息解密。與對稱式加密不同的是，銀行不需要將私密金鑰通過網路發送出去，因此安全性大大提高。

數位憑證

因為互連網不安全，公開金鑰也是資訊的一部分，也是會有被篡改的風險的。所以引入了互連網權威機構 - CA 機構，又稱為認證授權 (Certificate Authority) 機構，瀏覽器會內建這些"可信任的根憑證授權單位" (即 CA)。

服務端向權威的身份評鑑 CA 機構申請數位憑證，CA 機構驗證了網站之後，會把網站錄入到內部列表，採用 Hash 把服務端的一些相關資訊產生摘要，然後 CA 機構用自己的私匙，把服務端的公開金鑰和相關資訊一起加密，然後給申請認證的服務端頒發數位憑證，用於其他用戶端 (比如瀏覽器) 認證這個網站的公開金鑰。

用戶端通過服務端下發的認證，找到對應的 CA，然後向 CA 驗證這個認證是否有效，CA 驗證通過之後，下發服務端的公開金鑰。

因為 CA 是權威並且可信的，所以用戶端 (瀏覽器) 信任 CA，而 CA 又信任經過認證的服務端，所以用戶端 (瀏覽器) 也信任這個服務端，這就是信任鏈結 (Chain Of Trust)。

而 CA 頒發的數位憑證，一般包含這些資訊：

 

簡單來說：為了保證公開金鑰是安全的，所以通過數位憑證驗證公匙。

SSL介紹

SSL(SecureSockets Layer ,安全套接層),及其繼任者傳輸安全層（Transport Layer Security，TLS）是為網路通訊提供安全及資料完完整性的一種安全性通訊協定。TLS與SSL在傳輸層對網路連接進行加密。

目前TLS的版本為1.2（也被標示為SSL3.3），被現在主流的瀏覽器所支援。

SSL協議的三個特性：

l  保密：在握手協議中定義了工作階段金鑰後，所有的訊息都被加密；

l  鑒別：可選的用戶端認證，和強制的伺服器端認證；

l  完整性：傳送的訊息包括訊息完整性檢查。

 

SSL工作原理：

握手協議（Handshake protocol）

記錄協議（Record protocol）

警報協議（Alert protocol）

握手協議

握手協議是客戶機和伺服器用SSL串連通訊時使用的第一個子協議，握手協議包括客戶機與伺服器之間的一系列訊息。SSL中最複雜的協議就是握手協議。該協議允許伺服器和客戶機相互驗證，協商加密和MAC演算法以及保密密鑰，用來保護在SSL記錄中發送的資料。握手協議是在應用程式的資料轉送之前使用的。

 

每個握手協議包含以下3個欄位
（1）Type：表示10種訊息類型之一
（2）Length：表示訊息長度位元組數
（3）Content：與訊息相關的參數

 

握手協議的4個階段

 

 

 

第一階段建立安全連結的能力

SSL握手的第一階段啟動邏輯串連，建立這個串連的安全能力。首先客戶機向伺服器發出client hello訊息並等待伺服器響應，隨後伺服器向客戶機返回serverhello訊息，對client hello訊息中的資訊進行確認。

 

ClientHello 客戶發送CilentHello資訊，包含如下內容：

（1）用戶端可以支援的SSL最高版本號碼

（2）一個用於產生主要金鑰的隨機數。

（3）一個確定會話的會話ID。

（4）一個用戶端可以支援的密碼套件列表。

（5）一個用戶端可以支援的壓縮演算法列表。

 ServerHello 伺服器用ServerHello資訊應答客戶，包括下列內容

（1）一個SSL版本號碼。取用戶端支援的最高版本號碼和服務端支援的最高版本號碼中的較低者。

（2）一個用於產生主要金鑰的隨機數。

（3）會話ID

（4）從用戶端的密碼套件列表中選擇的一個密碼套件

（5）從用戶端的壓縮方法的列表中選擇的壓縮方法

這個階段之後，用戶端服務端知道了下列內容：

（1）SSL版本

（2）金鑰交換、資訊驗證和密碼編譯演算法

（3）壓縮方法

（4）有關密鑰產生的兩個隨機數。

 

第二階段伺服器鑒別與金鑰交換

伺服器啟動SSL握手第2階段，是本階段所有訊息的唯一發送方，客戶機是所有訊息的唯一接收方。該階段分為4步：

（a）認證：伺服器將數位憑證和到根CA整個鏈發給用戶端，使用戶端能用伺服器憑證中的伺服器公開金鑰證明伺服器。
（b）伺服器金鑰交換（可選）：這裡視金鑰交換演算法而定
（c）認證請求：服務端可能會要求客戶自身進行驗證。
（d）伺服器握手完成：第二階段的結束，第三階段開始的訊號

 

這個階段的前面的（a）認證 和（b）伺服器金鑰交換是基於金鑰交換方法的。而在SSL中金鑰交換演算法有6種：無效（沒有金鑰交換）、RSA、匿名Diffie-Hellman、暫時Diffie-Hellman、固定Diffie-Hellman、Fortezza。

在階段1過程用戶端與服務端協商的過程中已經確定使哪種金鑰交換演算法。

如果協商過程中確定使用RSA交換密鑰，那麼過程如：

 

這個方法中，伺服器在它的第一個資訊中，發送了RSA加密/解密密鑰憑證。不過，因為預備主秘密是由用戶端在下一個階段產生並發送的，所以第二個資訊是空的。注意，密鑰憑證會進行從伺服器到用戶端的驗證。當伺服器收到預備主秘密時，它使用私密金鑰進行解密。服務端擁有私密金鑰是一個證據，可以證明伺服器是一個它在第一個資訊發送的密鑰憑證中要求的實體。

 

第三階段用戶端鑒別與金鑰交換

 

客戶機啟動SSL握手第3階段，是本階段所有訊息的唯一發送方，伺服器是所有訊息的唯一接收方。該階段分為3步：

（a）認證（可選）：為了對伺服器證明自身，客戶要發送一個認證資訊，這是可選的，在IIS中可以配置強制用戶端認證認證。

（b）客戶機金鑰交換（Pre-master-secret）：這裡用戶端將預備主要金鑰發送給服務端，注意這裡會使用服務端的公開金鑰進行加密。

（c）認證驗證（可選），對預備秘密和隨機數進行簽名，證明擁有（a）認證的公開金鑰。

下面也重點介紹一下RSA方式的用戶端驗證和金鑰交換。

 

這種情況，除非伺服器在階段II明確請求，否則沒有認證資訊。用戶端金鑰交換方法包括階段II收到的由RSA公開金鑰加密的預備主要金鑰。

階段III之後，客戶要有伺服器進行驗證，客戶和伺服器都知道預備主要金鑰。

 

第四階段完成

到了這一階段，用戶端和服務端都有了三個資料——用戶端隨機數、服務端隨機數、預備主要金鑰。

然後用戶端和服務端按照之前已經約定好的加密方式，產生了“同一把”工作階段金鑰，接下來用戶端和服務端的資訊傳遞還是通過HTTP協議來傳輸，只不過資訊的內容都是通過工作階段金鑰的加密處理，只有用同一把密鑰來解密，才能夠獲得其中的內容。

到此，用戶端和服務端的握手協議就完成了，雙方也建立起了安全的資訊傳遞通道。

 

 

記錄協議

 

記錄協議在客戶機和伺服器握手成功後使用，即客戶機和伺服器鑒別對方和確定安全資訊交換使用的演算法後，進入SSL記錄協議，記錄協議向SSL串連提供兩個服務：

（1）保密性：使用握手協議定義的秘密密鑰實現

（2）完整性：握手協議定義了MAC，用於保證訊息完整性

記錄協議的過程：

 

 

第一個步驟是分區

每一個使用者想要通過SSL傳送的訊息都會被切割成最多214B(或者是16364B)大小的分區，接著，可以選擇是否執行壓縮的步驟。

壓縮的過程中，必須是無損失壓縮，也就是說解壓縮後能夠得到原本完整的訊息。除此之外，經過壓縮後的內容長度不能超過原有長度1024位元組以上(當然，我們希望壓縮後的資料能夠更小，而不是增多。但對於有些長度非常小的分區來說，可能因為壓縮演算法格式上的要求，壓縮過後的結果會比原來資料還長)。在SSLv3(以及TLS的現有版本)，並沒有指定壓縮演算法，所以預設的加演算法是null。

第二個步驟是添加MAC（Message Authentication Cores）

訊息認證碼（帶密鑰的Hash函數）:密碼學中，通訊實體雙方使用的一種驗證機制，保證訊息資料完整性的一種工具。構造方法由M.Bellare提出，安全性依賴於Hash函數，故也稱帶密鑰的Hash函數。訊息認證碼是基於密鑰和訊息摘要所獲得的一個值，可用於資料來源發認證和完整性校正。

在發送資料之前，發送方首先使用通訊雙方協商好的散列Function Compute其摘要值。在雙方共用的工作階段金鑰作用下，由摘要值獲得訊息驗證碼。之後，它和資料一起被發送。接收方收到報文後，首先利用工作階段金鑰還原摘要值，同時利用握手協議裡面商量好的散列函數在本地計算所收到的資料上，再產生摘要值，並將這兩個資料進行比對。若兩者相等，則報文通過認證。

第三步為添加SSL記錄前序

這個記錄頭包含以下的欄位。

(1)資料類型(Contenttype)，8位：用來處理這個分區的上層協議。

(2)主要版本號碼(MajorVersion)，8位：所使用的SSI。協議的主要版本，對於SSI。v3協議來說，這個欄位值為3。

(3)次要版本號碼(MinorVersion)，8位：表示使用的次要版本，對於SSLv3協議來說，這個欄位值為0。

(4)壓縮後資料長度(Compressedlength)，16位：這個明文分區的長度(假如此分區已經過壓縮，則為壓縮後的長度)。最大值為(214+2048)B。

 

警告協議

SSL警告協議亦稱SSL警示協議、SSL警示協議，是用來為對等實體傳遞SSL的相關警告。如果在通訊過程中某一方發現任何異常，就需要給對方發送一條警示訊息通告。

　SSL警示協議報文由嚴重層級和警告代碼兩部分組成，。

 

SSL警示協議中嚴重層級分為Fatal和Warning為兩種。其中，Fatal級警示即致命級警示，它要求通訊雙方都要採取緊急措施，並終止會話，如在資料轉送過程中，若發現有錯誤的MAC，雙方就需要立即中斷會話，同時消除自己緩衝區相應的會話記錄；而對Warning級警示即警告級警示的處理，通常是通訊雙方都只進行日誌記錄，它對通訊過程不造成影響。

　　以下是一些警告資訊：

　　(1)unexpected_message：接收了不合適的報文。

　　(2)bad_record_mac：收到了不正確的MAC。

　　(3)decompression_failure：解壓縮函數收到不適當的輸入。

　　(4)illegal_parameter：握手報文中的一個欄位超出範圍或與其他欄位不相容。

　　(5)certificate_revoked：認證已經被廢棄。

　　(6)bad_certificate：收到的認證是錯誤的。

　　(7)certificate_expired：認證已經到期。

　　(8)handshake_failer：握手過程失敗。

單向認證

Https在建立Socket串連之前，需要進行握手，具體過程如下：

1.    用戶端向服務端發送SSL協議版本號碼、密碼編譯演算法種類、隨機數等資訊。

2.    服務端給用戶端返回SSL協議版本號碼、密碼編譯演算法種類、隨機數等資訊，同時也返回伺服器端的認證，即密鑰憑證

3.     用戶端使用服務端返回的資訊驗證伺服器的合法性，包括：

o 認證是否到期

o 髮型伺服器憑證的CA是否可靠

o 返回的公開金鑰是否能正確解開返回認證中的數位簽章

o 伺服器憑證上的網域名稱是否和伺服器的實際網域名稱相匹配

驗證通過後，將繼續進行通訊，否則，終止通訊

4.    用戶端向服務端發送自己所能支援的對稱式加密方案，供伺服器端進行選擇

5.    伺服器端在用戶端提供的加密方案中選擇加密程度最高的加密方式。

6.    伺服器將選擇好的加密方案通過明文方式返回給用戶端

7.    用戶端接收到服務端返回的加密方式後，使用該加密方式產生產生隨機碼，用作通訊過程中對稱式加密的密鑰，使用服務端返回的公開金鑰進行加密，將加密後的隨機碼發送至伺服器

8.    伺服器收到用戶端返回的加密資訊後，使用自己的私密金鑰進行解密，擷取對稱式加密密鑰。 
在接下來的會話中，伺服器和用戶端將會使用該密碼進行對稱式加密，保證通訊過程中資訊的安全。

雙向認證

雙向認證和單向認證原理基本差不多，只是除了用戶端需要認證服務端以外，增加了服務端對用戶端的認證，具體過程如下：

1.    用戶端向服務端發送SSL協議版本號碼、密碼編譯演算法種類、隨機數等資訊。

2.    服務端給用戶端返回SSL協議版本號碼、密碼編譯演算法種類、隨機數等資訊，同時也返回伺服器端的認證，即密鑰憑證

3.     用戶端使用服務端返回的資訊驗證伺服器的合法性，包括：

o 認證是否到期

o 髮型伺服器憑證的CA是否可靠

o 返回的公開金鑰是否能正確解開返回認證中的數位簽章

o 伺服器憑證上的網域名稱是否和伺服器的實際網域名稱相匹配

驗證通過後，將繼續進行通訊，否則，終止通訊

4.    服務端要求用戶端發送用戶端的認證，用戶端會將自己的認證發送至服務端

5.    驗證用戶端的認證，通過驗證後，會獲得用戶端的公開金鑰

6.    用戶端向服務端發送自己所能支援的對稱式加密方案，供伺服器端進行選擇

7.    伺服器端在用戶端提供的加密方案中選擇加密程度最高的加密方式

8.    將加密方案通過使用之前擷取到的公開金鑰進行加密，返回給用戶端

9.    用戶端收到服務端返回的加密方案密文後，使用自己的私密金鑰進行解密，擷取具體加密方式，而後，產生該加密方式的隨機碼，用作加密過程中的密鑰，使用之前從服務端認證中擷取到的公開金鑰進行加密後，發送給服務端

10.  服務端收到用戶端發送的訊息後，使用自己的私密金鑰進行解密，擷取對稱式加密的密鑰，在接下來的會話中，伺服器和用戶端將會使用該密碼進行對稱式加密，保證通訊過程中資訊的安全。

SSL&HTTPS簡單介紹