SSL&HTTPS簡單介紹
這篇是最近看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函數。消息認證碼是基於密鑰和消息摘要所獲得的一個值，可用於數據源發認證和完整性校驗。
在發送數據之前，發送方首先使用通信雙方協商好的散列函數計算其摘要值。在雙方共享的會話密鑰作用下，由摘要值獲得消息驗證碼。之後，它和數據一起被發送。接收方收到報文後，首先利用會話密鑰還原摘要值，同時利用握手協議裏面商量好的散列函數在本地計算所收到的數據上，再生成摘要值，並將這兩個數據進行比對。若兩者相等，則報文通過認證。
第三步為添加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簡單介紹