小明加密訪問

Ⅰ 加密、簽名、證書的作用及運用場景

本文主要是簡單介紹了常見的加密類型、各自的運用場景、為什麼需要數字簽名和數字證書、HTTPS涉及到的加密流程等。這里主要從使用者的角度出發，對演算法本身不做過多介紹。

對稱/非對稱加密均屬於 可逆加密，可以通過密鑰將密文還原為明文 。

有時候，我們希望明文一旦加密後，任何人（包括自己）都無法通過密文逆推回明文，不可逆加密就是為了滿足這種需求。
不可逆加密主要通過 hash演算法實現：即對目標數據生成一段特定長度hash值 ；無論你的數據是1KB、1MB、1GB，都是生成特定長度的一個Hash值（比如128bit）。這里大家應該能感受到一點 不可逆 的味道，加密後128bit的hash值顯然無法還原出1個G甚至更大的不規則數據的， hash可以看做是原來內容的一個摘要 。

常見演算法：

小明給小紅寫信：

經過九轉十八彎後，信的內容有可能：1. 被窺視 2. 被篡改（冒充小明發送假消息） ：

小紅先 生成對稱加密的密鑰key1 ，然後通過一個安全的渠道交予小明。
傳輸數據時，小明 使用key1加密 ，而小紅收到後再 使用key1解密 。
這時候 中間者既看不到原來的內容，也沒辦法篡改 （因為沒有密鑰）：

【對稱加密】實現簡單，性能優秀 ，演算法本身安全級別高。然而對 密鑰的管理 卻是個很頭疼的問題：一旦密鑰交到對方手裡，對方對密鑰的保管能力 我方是沒辦法控制 的，一旦對方泄露的話，加密就形同虛設了。
相對而言，【非對稱加密】的公鑰就沒有這個憂慮，因為 公鑰 的設計就是為了 可以公開的 ，盡管對方泄露，我方也不會有任何損失。

小紅生成一對公私鑰，自己持有私鑰（pri_key1），將公鑰（pub_key1）交予小明。
傳輸數據時，小明使用 公鑰加密 ，小紅使用 私鑰解密 。
因為 中間者沒有私鑰，公鑰加密的內容是無法獲取的 。此時達到了 防窺視 的效果：

然而因為 公鑰是可以公開的 ，如果 中間者知曉公鑰 的話，盡管沒有辦法看到原來的內容，卻 可以冒充小明發送假消息 ：

這時小紅在想，如果小明發送消息時，能帶上 只有他自己才能生成 的數據（字元串），我就能 驗證是不是小明發的真實消息 了。
通常這個 能證實身份的數據（字元串） 被稱之為 數字簽名（Signature）

小明再生成一對公私鑰 ，自己持有私鑰（pri_key2），將公鑰交予小紅（pub_key2）。

當小明傳輸數據時（可能很大），除了公鑰加密明文之外，還要帶上簽名：(1) 對明文做一個hash摘要 (2)對摘要進行私鑰加密，加密結果即簽名（傳輸內容=內容密文+簽名）

小紅收到後：(1) 解密簽名獲取hash (2)解密內容密文，對解密後的明文進行hash；如果兩個hash一致，說明驗簽通過。

盡管中間者修改了傳輸內容，但因為簽名無法冒認（沒有私鑰），小紅驗簽失敗，自然不會認可這份數據：

通常 非對稱加密要做到防窺視和防篡改，需要有兩對公私鑰 ：對方的公鑰用於內容加密，自己的私鑰用於簽名（讓對方驗證身份）。

因為HTTP協議明文通信的安全問題，引入了HTTPS：通過建立一個安全通道（連接），來保證數據傳輸的安全。

伺服器是 沒辦法直接將密鑰傳輸到瀏覽器的 ，因為在 安全連接建立之前，所有通信內容都是明文的 ，中間者可窺視到密鑰信息。
或許這時你想到了非對稱加密，因為公鑰是不怕公開的：

然而在第2步， 中間者可以截取伺服器公鑰，並替換成了自己的公鑰 ，此時加密就沒意義了：

為了 防止公鑰被假冒，數字證書（digital certificate ）便誕生了 。

當伺服器需要告訴瀏覽器公鑰時，並不是簡單地返回公鑰，而是響應 包含公鑰信息在內的數字證書 。

證書主要包含以下內容：

瀏覽器通過 【頒發機構的公鑰】進行解密驗簽 ，驗簽通過即說明證書的真實性，可以放心取 證書擁有者的公鑰 了。（ 常用CA機構的公鑰都已經植入到瀏覽器裡面 ）

數字證書只做一件事： 保證 伺服器響應的 公鑰是真實的 。

以上保證了 [瀏覽器⇒伺服器] 是加密的，然而 [伺服器⇒瀏覽器] 卻沒有（上圖第4步）；另外一個是 性能問題 ，如果所有數據都使用非對稱加密的話，會消耗較多的伺服器資源，通信速度也會受到較大影響。
HTTPS巧妙地結合了非對稱加密和對稱加密，在保證雙方通信安全的前提下，盡量提升性能。

HTTPS（SSL/TLS）期望 建立安全連接後，通信均使用【對稱加密】 。
建立安全連接的任務就是讓 瀏覽器-伺服器協商出本次連接使用的【對稱加密的演算法和密鑰】 ；協商過程中會使用到【非對稱加密】和數字證書。

特別注意的是：協商的密鑰必須是不容易猜到（足夠隨機的）：

其中比較核心的是隨機數r3（pre-master secret），因為之前的r1、r2都是明文傳輸的， 只有r3是加密傳輸 的。至於為什麼需要三個隨機數，可以參考：

以上是一個比較簡單的HTTPS流程，詳細的可以參考文末的引用。

參考資料：
[1] 數字證書應用綜合揭秘
[2] SSL/TLS協議運行機制的概述
[3] 圖解SSL/TLS協議
[4] 《圖解HTTP》

Ⅱ 數字簽名/數字證書/對稱/非對稱加密/CA 等概念明晰

此次不深入源碼、不分析原理、只釐清一些易混淆概念及其關聯。
本次將從通信演變歷史的角度出發，一步步闡述概念及其作用。
通過本篇文章，你將了解到：

大部分時候，咱們交流都是靠嘴對嘴，信息完全暴露在他人的耳朵里。

拉拉家常無關緊要，但要是涉及重要、私密的信息就不能這樣子了。
此時可能想到，那我們就說悄悄話吧。

悄悄話只能是倆人近距離才能實現，若是天各一方怎麼才能將信息安全送給對方呢？
大家或多或少地看過諜戰片，那會兒卧底如何將信息傳給組織呢？答案是通過密碼本。

雙方約定好用一個密碼本，密碼本其實是個映射關系：

此時雙方通信是經過加密的，我們稱為密文通信。第三者想要破解信息，就需要拿到密碼本或是破譯出密碼本映射關系，從而將密文轉為明文。

隨著科學技術的發展，人們的交流由書信逐漸過渡為電子通信。

當我們在鍵盤上敲擊一段文字後，這段信息會通過網路發送給對方，怎麼保證這段信息不被別人輕易知道呢？
我們想到了加密，雙方在傳輸信息前商量好一個密鑰，發送方用密鑰將信息進行加密形成密文後再發送，接收方在收到密文後使用之前協商的密鑰進行解密。

舉個簡單例子：

小明現在將信息進行對稱加密：

那麼將明文hello，每個字元+1，得出如下結果：
hello--->ifmmp

小紅拿到密文ifmmp後，她知道密鑰X=1，因此她將密文每個字元-1，得出如下結果：
ifmmp--->hello

至此，小明和小紅成功進行了交流。

此時小剛想知道小明和小紅聊了啥，於是截獲了信息：

但是由於小剛拿到的是密文信息：ifmmp。因為不知道密鑰，因此無法反推出明文：hello。因此小明和小紅的信息交流安全得到了保證。

當然對稱加密演算法沒那麼簡單，常見的對稱加密演算法有如下幾種：

似乎使用對稱加密就可以解決咱們通信安全問題，但引入了另一個問題：

是否有種方式可以光明正大地傳遞信息呢？
答案是：非對稱加密。

接著來看看小明和小紅如何使用非對稱加密來實現安全通信。
小明和小紅分別生成自己的公私鑰：

由上可知，用小紅的公鑰加密的信息只能由小紅的私鑰解開，只要小紅的私鑰沒有泄漏，那麼小明和小紅的通信是安全的。
當然了，真正非對稱加密演算法並沒有那麼簡單，常見的幾種非對稱加密演算法：

小明和小紅的通信真是安全的嗎？
此時小剛又來搞事情了：

以上信息表明：

小明和小紅一合計，想出來了一個辦法：

消息摘要(Message Digest)特點：

常見的消息摘要演算法：MD5、SHA1。

雖然採用了消息摘要，但是小剛依然能夠自己偽造信息，並生成對應的消息摘要，小紅收到後驗證摘要是正確的，便認為是小明發的，這種做法還是有漏洞。
在前邊用到了小紅的公鑰、私鑰，而沒用到小明的公鑰、私鑰。
在消息摘要的基礎上，想辦法讓小明的公私鑰也參與到通信過程中來：

與消息摘要過程對比，此時多了一個步驟：

用私鑰加密的信息的過程我們稱之為：數字簽名
數字簽名具有不可抵賴性的特點。根據前面的描述，用私鑰加密的信息，只有對應的公鑰才能解開。
因此，若是小紅使用了小明的公鑰解開了密文，那麼說明該消息肯定是小明發過來的。反之，小明使用私鑰加密後發出去，代表這信息是確認是自己發的，這就是他的簽名。

常見的數字簽名演算法：RSA、DSA、ECDSA。
老規矩，用圖來看看小明與小紅如何使用數字簽名的。

小明發送信息過程：

小紅處理信息過程：

由上可知：
數字簽名有兩個作用：

整個流程小明的公私鑰、小紅的公私鑰都參與了。
因為小剛沒有小明的私鑰，所以他無法生成小明的數字簽名，最終無法通過小紅對數字簽名的驗證。

這么看來小剛是無能無能為力了？非也！
回顧一下之前說的對稱加密的痛點：如何傳遞對稱密鑰？
實際上非對稱加密也存在問題：如何傳遞公鑰？
可見，無論是對稱加密還是非對稱加密都需要解決密鑰傳遞問題。

若是小剛偽造了小紅的公鑰，情況如下：

因為公鑰被偽造了，所以小剛可以為所欲為。
小明如何才能知道自己收到的公鑰是小紅的呢？
這時候就需要引入權威機構：CA(Certificate Authority) 證書授權中心

有了CA，小紅發布公鑰的流程變了：

用圖表示如下：

圖上5個步驟，有些同學對第4步不太理解：

似乎又回到了原點：如何安全傳遞公鑰的問題。
其實，信任是有起點的。
CA 不僅為他人生成證書，也生成自己的證書，CA 為自己生成的證書里包含了CA的公鑰。
CA 的證書在電腦、手機等設備出場的時候就會預置在系統里、瀏覽器里。

因此，當小明驗證小紅的證書時，會在系統里尋找能夠解開小紅證書的CA 公鑰，若是找到則說明小明證書的頒發機構是可信任的，既然信任了該證書，那麼從證書里取出的公鑰，小明也認可是小紅的。
至此，小紅的公鑰就安全地傳給了小明，後面就可以愉快地通信了。

系統里找不到對應的證書會有什麼影響？大家還記得12306網站剛開始運行的時候，用瀏覽器訪問時瀏覽器會提醒說該網站不受信任，12306提示用戶安裝自己的根證書。
這也從側面說明了，咱們不要輕易更改系統里的證書。

對稱加密存在密鑰傳送被泄漏的風險，非對稱加密雖然不需要傳遞私鑰，但是需要傳遞公鑰，也存在被中間人攻擊的風險。
為此，引入了CA 生產證書解決了非對稱加密公鑰傳遞問題。

然後非對稱加密速度慢，適合加密數據量少的信息，對稱加密速度快，適合加密數據量大的信息。
如何將對稱加密與非對稱加密結合起來打造一個安全的通信鏈路，下篇我們將重點分析其中的典型：SSL/TLS 的原理與應用。