SSL及其加密通信過程

SSL的目的

為了網絡通信的安全，具體講可分為：

1.防泄露：數據必須用密文傳輸（加密算法）；

2.防止篡改：數據必須加完整性校驗（數字簽名）；

3.防止抵賴：服務端使用自己私鑰加密的數字簽名（數字簽名）；

4.防身份偽造：服務端身份必須經過認證（數字證書）；

 

從HTTP說起

HTTP（Hyper TEXT Transfer Protocol超文本傳輸協議）是目前互聯網上應用最為廣泛的一種網絡協議，在網絡模型中位於應用層，用於在Web瀏覽器和網站服務器之間傳遞信息，但是HTTP協議以明文的方式發送內容，不提供任何數據加密，攻擊者能夠很輕易截獲傳輸的信息，造成的影響：1.你不希望被看到的信息被看到，2.如果傳輸的數據是可執行文件而被攻擊者修改，這樣可能對計算機的損害。

為了解決HTTP這一缺陷，HTTPS（Hyper TEXT Transfer Protocol over Secure Socket Layer）協議出現。HTTPS是在HTTP的基礎上加入SSL協議。傳輸以密文傳輸，保證數據傳輸的安全(文件是否被修改)以及確認網站的真實性（確定發送者的真實身份）。

HTTPS=HTTP+SSL

SSL協議在網絡模型中的位置

SSL和TLS的關系

我們在搜SSL的時候，一般是SSL和TLS一起出現的，其實本質上SSL和TLS是一個東西，SSL是1994年美國網景開發的協議，目的是為了解決web通信不安全的問題，1996年發布SSL3.0，1997年一個叫IETF的專門制定互聯網協議的任務組試圖將SSL進行標准化，並且在SSL3.0的基礎上發布TLS1.0，之后SSL就以TLS這個名字出現。最終在1999年被記錄到RFC（一系列編號排定的文件，意即“請求協議”，包含了關於Internet的幾乎所有重要的文字資料）。

SSL 協議的構成

上圖最左邊是標准的TCP/IP的四層模型，從上到下分別是應用層、傳輸層、網絡層、鏈路層，而新加入的SSL協議則位於傳輸層和應用層中間，它利用傳輸運輸層提供的端到端的通信服務為應用層提供加密傳輸服務。SSL又可以被細分為SSL記錄協議和SSL握手協議，這兩個協議也是有上下層的關系，SSL記錄協議主要是提供數據的封裝，壓縮，認證，加密等基本功能的支持，SSL握手協議則是利用SSL記錄協議提供的這些服務，在實際數據傳輸開始前雙方協商加密算法，交換密鑰等。詳細過程我們后面再說。

幾個密碼學相關概念

• 密鑰：在加密或者解密算法中的輸入參數
• 對稱加密：加密和解密用的是同一個密鑰
• 非對稱加密：加密和解密用的是不同密鑰，分別被稱為公鑰和私鑰
• 公鑰：可以被公開的密鑰
• 私鑰：不能被公開只能自己保存的密鑰

其中公鑰和私鑰的關系是：用公鑰加密的密文只能用對應的私鑰進行解密，用私鑰加密的密文只能用對應的公鑰進行解密。

SSL加密傳輸的過程

為什么不直接用對稱加密進行加密傳輸

其實對稱加密比非對稱加密出現的早，而且它還有相對非對稱加密來說更快的加密/解密速度，它管理自己的密鑰更加簡單，但是為什么沒有人用對稱加密直接用數據的加密傳輸呢？

主要原因還是對稱加密的密鑰分發困難，就比如說我要下載服務器上的一份文件，如果用對稱加密的話首先要做的就是密鑰分發，如果直接不附加任何東西的發給你，很可能被別人截獲，而密鑰被別人截獲的話是一間很危險的事情。所以一般不會直接用對稱加密進行傳輸，SSL的做法是通過非對稱加密的方式交換對稱加密的密鑰，再通過對稱加密的方式數據傳輸。

非對稱加密的傳輸方式

前面說了對稱加密不能直接用於數據加密傳輸，我們再來看看非對稱加密。

利用非對稱加密的方式有兩種，考慮B要向服務器A下載一份文件，一種做法是A用B的公鑰加密，發送過去后B用自己的私鑰解密，另一種做法是A用自己的私鑰加密，B用A的公鑰進行解密。

我們現在看一下第一種方式：A用B的公鑰加密，B用自己的私鑰解密，想一想這種做法有沒有什么問題？

問題就是A向B發送的數據可能被中間人C截獲，由於公鑰是公開的，C可以冒充A發送文件給B。B接受到文件后：第一它不知道文件是不是來自A，第二它不知道文件是否被人修改。

我們再看一下第二種方式：A用自己的私鑰進行加密，B用A的公鑰進行解密。這種方式解決了上面的問題了嗎？

上面的問題確實解決了，如果B能夠用A的公鑰進行解密順利的解密，這份文件一定是來自A的，並且文件沒有被更改，否則無法順利解密。

我們再來想一想這種方式好嗎。非對稱加密是一個比較耗時的過程，如果文件比較大的話，就會產生非常嚴重的延時，對用戶體驗極度不好。其實用戶B的目的是能夠下載到A的並且沒有被修改的文件，並沒有必要對整個文件進行加密，那如何做到即快速又安全呢？就是數字簽名！

數字簽名

我們先來看一下數字簽名的工作流程

1. A先對這封Email執行哈希運算得到hash值簡稱“摘要”，取名h1
2. 然后用自己私鑰對摘要加密，生成的東西叫“數字簽名”
3. 把數字簽名加在Email正文后面，一起發送給B。
4. B收到郵件后用A的公鑰對數字簽名解密，成功則代表Email確實來自A，失敗說明有人冒充
5. B對郵件正文執行哈希運算得到hash值，取名h2
6. B 會對比第4步數字簽名的hash值h1和自己運算得到的h2，一致則說明郵件未被篡改。

數字簽名的簽名過程，就是發送者根據待發送的信息和用自身私鑰加密的數字摘要組合成數字簽名，用戶采用自己的私鑰對信息加以處理，由於密鑰僅為本人所有，這樣就產生了別人無法生成的文件，也就形成了數字簽名，采用數字簽名，能夠確認以下兩點：

1、保證信息是由簽名者自己簽名發送的，簽名者不能否認或難以否認；

2、接收方可以驗證信息自簽發后到收到為止未曾做過任何修改，簽發的文件是真實文件。

這樣一來是不是完美了？有沒有上面致命缺陷？答案是有的。缺陷就是B得到的A的公鑰不一定是A的公鑰，它也是可能被修改的，如果有人把你得到的A的公鑰改成自己的，別人就有可能冒充A。需要有其它東西證明A公鑰的正確性。那就是數字證書！

數字證書

數字證書是一個專門的頒發數字證書的機構ca頒發的，他將簽發者、A的加密算法、A的公鑰、證書到期時間等信息用簽發機構的私鑰進行加密得到一份數字證書。

我們再來看一下數字證書工作流程：

簽名的步驟和上面一樣，只是A發送的數據包括文件正文、數字簽名、數字證書，接收方B通過CA機構的公鑰將數字證書解密得到A公鑰等信息，用於后續文件驗證等操作。

這個過程還有問題嗎？——CA公鑰如何驗證真假。是不是可以和驗證A公鑰的方法一樣找給CA機構簽發證書的CA機構，那這個CA又怎么驗證，似乎進入惡性循環…

證書信任鏈

證書認證是一級一級的認證的，我們稱最頂部的證書為根證書。操作系統或者瀏覽器會內置一些根證書，我們對這些證書是據對信任的。

以百度服務器的數字證書為例說明證書信任鏈。

1. 當client端訪問baidu.com的時候，baidu的server會將baidu.com證書發送給client端。
2. client端的操作系統或者瀏覽器中內置了根證書，但是client端收到baidu.com這個證書后，發現這個證書不是根證書簽發，無法根據本地已有的根證書中的公鑰去驗證baidu.com證書是否可信。
3. 請求到證書后發現GlobalSign Organization Validation CA - SHA256 - G2證書是由根證書簽發，而本地剛好有根證書，於是可以利用根證書中的公鑰去驗證GlobalSign Organization Validation CA - SHA256 - G2證書，發現驗證通過，於是信任GlobalSign Organization Validation CA - SHA256 - G2證書。
4. GlobalSign Organization Validation CA - SHA256 - G2證書被信任后，可以使用GlobalSign Organization Validation CA - SHA256 - G2證書中的公鑰去驗證baidu.com證書的可信性。驗證通過，於是信任baidu.com證書。

windows可以通過certmgr.msc命令查看系統內置的證書

我們可以在瀏覽器上查看目標服務器的數字證書

SSL握手協議

上面介紹的知識客戶端單方向的從服務器獲取文件，如果服務器要和客戶端進行交互，上面的步驟效率就不是很高，一種做法就是通過上面介紹的方法建立鏈接生成一個對稱加密的密鑰，之后用對稱加密的方式進行交互，這就是SSL握手協議做的事情。具體步驟如下：

這整個握手過程都是不加密的，整個通話的安全性全在於第三個隨機數能不能被破解，雖然理論上這個隨機數不能被破解，但是為了足夠的安全，他們把這個握手階段默認的算法改成DH算法。雙方只要交換各自的參數就可以算出這個隨機數。

其具體過程如下：

 

 

通過抓包的方式也可以看到上述整個的握手過程：